Is al duidelijk wat een gebruiker kan ondernemen om
problemen te voorkomen?

ik vermoed dat die virtuele browser met sandboxie een
oplossing biedt!!

ten minste als die webstek intussen nog niet geïnfecteerd is...

expert.be en twice it zitten er ook bij lol....

Gebruikers: NoScript plugin gebruiken.
Ontwikkelaars: inputvalidatie.

Om te beginnen zorgen dat je besturingssysteem, browser en alle plugins gepatched zijn. Vooral exploits voor de RealPlayer plugin zijn de laatste tijd populair, maar exploits voor niet-up-to-date Flash, QuickTime en Acrobat reader plugins komen vermoedelijk ook voor.

Verder richten veel exploits zich op MSIE (gebruiken bijv. VBscript en/of ActiveX plugins welke Firefox standaard geheel niet ondersteunt).

Als je Firefox uitbreidt met [url=http://noscript.net/]NoScript[/url] ben je goed gewapend tegen het huidige type exploits, zelfs als je Firefox (middels NoScript) toestemming geeft om scripts van een gehackte site uit te voeren. De reden is dat bij de huidige golf van exploits steeds javascript vanaf een andere server (met daarop meestal meerdere exploits) wordt opgehaald; zolang je javascripts vanaf die server geen toestemming geeft ben je safe. Bij toekomstige eploits valt echter niet uit te sluiten dat malware-houdende scripts in gekraakte servers worden ge-inject.

Trouwens, als ik in de Google cache van [color=blue]www_procase_nl[/color] kijk (retrieved on 9 May 2008 23:58:27 GMT) zie ik nog javascript vanaf [color=blue]www_kisswow_com_cn[/color] komen, maar in de actuele page is dat momenteel [color=blue]www_wow112_cn[/color]; die URL's zijn kennelijk net vervangen, want Googlen naar www_wow112_cn (underscores door punten vervangen) geeft nog nauwelijks hits.

Voor de fanatieke block-listers onder ons: die laatste site wordt al wel op [url=http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20080514]ShadowServer[/url] genoemd. Op die lijst heb ik nog enkele aanvullingen (met relatief lage Google hitrates): [color=blue]c11_8866_org[/color], [color=blue]w11_6600_org[/color] en [color=blue]d39_6600_org[/color].

... bevindt zich al op 149.000 sites.

Hier wordt waarschijnlijk bedoeld dat er 149.000 infecties
hebben plaats gevonden. 1 hit op Google komt niet persee
overeen met 1 site.

Dat is slechts een deel van de oplossing. Het kan namelijk
heel valide zijn dat een string bijvoorbeeld een enkele
quote bevat. De oplossing is dan NIET om deze bij het
valideren van de invoer gelijk al te vervangen door twee
enkele quotes (zoals helaas door vele programmeurs wordt
gedaan). Dat moet je pas doen bij het samenstellen van je
SQL statement. Of nog beter, gebruikt prepared SQL
statements / parameter binding en/of stored procedures.

Daarnaast is het alleen het vervangen van enkele of dubbele
quotes lang niet voldoende. Er zijn nog veel meer tekens
waaraan SQL Server speciale betekenis geeft. Ook die moeten
worden ge'escaped. En nogmaals, met prepared SQL statements
/ parameter binding en/of stored procedures speelt dat
probleem helemaal niet want dan lost de database laag het
voor je op.

Bravo. Dat heet ook gewoon, heel ordinair
wellicht, inputvalidatie.

Google is sowieso erg slordig met die schatting. Ze hebben
een of ander efficiënt algoritme om aan dat getal te komen
zodat ze processortijd besparen, met als excuus dat kleine
afwijkingen wel te tolereren zijn. Ik heb echter met mijn
eigen ogen meerdere gevallen geobserveerd waarbij ik
uiteindelijk maar 5% van het totaal aantal resultaten had
gezien toen de laatste pagina was bereikt.

Het kunnen dus net zo goed "slechts" 7000 infecties zijn.
Evengoed nog indrukwekkend, maar het gebruik van het aantal
hits dat Google geeft is absoluut geen betrouwbare maatstaf.

Het grootste probleem met input validatie is dat het heel vaak niet gebeurd. Het tweede probleem is wat je hier eigenlijk schrijft. Men filtert op zaken die men NIET wil (quotes bijv.) waardoor er regelmatig dingen vergeten worden (denk ook aan Unicode en/of andere charactersets waarbij hetzelfde karakter verschillende voorstellingen hebben). Correcter is om te filteren op wat je WEL accepteert en de rest te verwijderen.

Overzichtelijker en logischer
bovendien. Mocht de invoer toch niet voldoen, dan heb je
opvolgend de stap van de foutafhandeling.