XSS en CSRF, de Bonnie en Clyde van de webapplicaties?

XSS en CSRF, de Bonnie en Clyde van de webapplicaties?

Indien u niet weet waarvoor de afkortingen XSS en CSRF staan, laat staan weet wat deze inhouden, is het hoog tijd om dit artikel te lezen. Webapplicaties zijn overal, de bijhorende dreigingen zijn dat ook.

Michael Boeynaems

Een ontwikkelaar van webapplicaties is niet enkel verantwoordelijk voor de veiligheid van de data van eigen klanten, maar draagt ook de bredere, maatschappelijke verantwoordelijkheid om het internet veilig te houden.

Meer en meer leggen professionele hackers zich toe op het gericht aanvallen van één zwakke entiteit. Het aantal van deze gerichte aanvallen steeg in 2012 met 42 procent (Symantec, 2013). Een van de oorzaken van deze trend is dat aan­vallers steeds vaker gebruikmaken van de ‘wate­ring hole’-techniek om sterk beveiligde entiteiten aan te vallen (Figuur 1). Hackers analyseren het netwerkverkeer van een slachtoffer die een gepri­vilegieerde relatie heeft met de sterk beveiligde entiteit. Dit slachtoffer zal gericht worden aan­gevallen: eerst wordt onderzocht welke websites het slachtoffer bezoekt, waar, wanneer, et cetera. Uit dit geheel van sites kiezen de hackers er een­tje uit waarvan de beveiliging te wensen overlaat. De hackers lanceren een aanval en injecteren er dan code op, die tot gevolg heeft dat de gebruiker automatisch doorverwezen wordt naar een aparte website met malware. De aanvallers wachten dan eenvoudigweg totdat de gebruiker de onveilige website opnieuw bezoekt. De malware wordt gedownload en de hackers hebben toegang tot het volledige systeem van het slachtoffer. Vanaf dan gebruiken ze het systeem van het slachtoffer om een stap dichter bij het uiteindelijke, sterk beveiligde doelwit te komen. Dit goed beveilig­de systeem raakt aldus gecompromitteerd door een combinatie van slecht beveiligde systemen en webapplicaties, die niet noodzakelijk iets te maken hebben met het beter beveiligde systeem.

Figuur 1. Anatomie van de 'Wateringhole techniek

Dit is een reëel probleem en toont aan dat het geheel van beveiliging maar zo sterk is als de zwakste schakel in de gehele keten. In theorie zouden we onveilige websites moeten afscher­men van gebruikers, maar in de praktijk is dit enkel haalbaar in extreme omgevingen (zoals een kerncentrale). Net daarom draagt elke ontwik­kelaar een maatschappelijke verantwoordelijk­heid. Ook ontwikkelaars van webapplicaties die bestemd zijn voor het mkb/kmo (Midden- en Kleinbedrijf / Kleine of Middelgrote Onderne­ming) dus. Het Symantec-rapport maakt melding van het feit dat 50 procent van doelgerichte aanvallen gericht zijn op organisaties met minder dan 2500 werknemers. 31 procent van de aan­vallen is zelfs gericht op kleine bedrijven, met minder dan 250 werknemers. Hackers verkrijgen zo toegang tot waardevolle informatie van deze kleine bedrijven, maar zijn zo ook in staat om een ‘waterhole attack’ uit te voeren. De ‘Elder­wood Gang’, een hackersgroep die blijkbaar over een onuitputtelijke bron aan ‘zero-day exploits’ beschikt, is een hackersgroep die binnenbreekt in de infrastructuur van mkb’s/kmo’s om zo infor­matie te verzamelen omtrent grotere doelwitten.

Meer dan webapplicatiebeveiliging

Hoe kan je er als mkb/kmo voor zorgen dat de beveiliging van de webapplicaties goed zit? Eerst en vooral: er is meer dan enkel webapplicatie­beveiliging. Ook het netwerk moet veilig zijn, de fysieke infrastructuur mag niet zomaar voor ieder­een toegankelijk zijn en de werknemers moeten voldoende bewustzijn hebben omtrent security, zodat ze bijvoorbeeld geen verdachte e-mails openen en sterke wachtwoorden gebruiken.

Toch is een groot deel van de focus van bevei­ligingsexperts gericht naar webapplicaties dezer dagen. Het cloud-gebeuren is hier niet vreemd aan: alle gegevens moeten altijd en overal beschikbaar zijn. Dé manier om dit te verwezenlijken is door de ontwikkeling van een webapplicatie. De term ‘webapplicatie’ heeft de term ‘website’ stilaan vervangen, maar beide zijn conceptueel gelijk aan elkaar. De term ‘website’ wordt wel vaker gebruikt om puur statische webpagina’s aan te duiden, zonder al te veel interactiviteit. Het is deze interactiviteit die vaak kopzorgen teweegbrengen bij de mensen die verantwoordelijk zijn voor de beveiliging van de webapplicatie.

Dit artikel haalt twee imminente dreigingen aan: ‘cross-site scripting’ (XSS) en ‘cross-site request forgery’ (CSRF). De reden hiervoor is enerzijds dat aanvallers deze technieken momenteel zeer vaak gebruiken in de praktijk en anderzijds dat deze technieken veel minder bekend zijn dan bijvoorbeeld SQL-injectie of het aanvallen van zwakke authenticatielogica. Ook OWASP (het Open Web Application Security Project), een non-profitorganisatie die erop gericht is om andere organisaties te helpen in het ontwikkelen van veilige webapplicaties, zet XSS en CSRF op plaats 3 en 8 in hun top-10 van meest kritieke risico’s ( figuur 2) . Volgens een rapport van Whi­teHat Security, bedraagt de kans dat er minstens één XSS-kwetsbaarheid te vinden is op een web­site, 53 procent. Voor CSRF bedraagt die kans 26 procent (White Hat Security, 2013).

Figuur 2. Top 10 dreigingen ( OWASP, 2013)

Cross-site scripting (XSS)

Bij cross-site scripting probeert een hacker Javascript te injecteren op een vertrouwde website, zodat deze code uitgevoerd wordt wanneer een normale gebruiker de website opent. Er worden vaak drie vormen van XSS onderscheiden: opgeslagen (stored); gereflecteerde (reflected);  DOM-gebaseerd (DOM-based).

Opgeslagen

Cross-site scripting komt het vaakste voor (en is ook het meest gevaarlijk) in de opgeslagen vorm. Aanvallers proberen code in te geven in invul­velden van bijvoorbeeld een eenvoudig website­formulier, met als doel dat deze code opgeslagen wordt op de servers van de website. Deze code zal dan uitgevoerd worden op het moment dat een slachtoffer de website opent. Een voorbeeld kan dit verduidelijken. Stel dat we een eenvou­dige webapplicatie bekijken, waar gebruikers producten kunnen aanbieden aan andere gebrui­kers (een veiling). Dit is een typisch voorbeeld van een interactieve website, waar content van de ene gebruiker ook getoond wordt aan andere gebruikers. Dit is ook een typisch voorbeeld waar men zeer omzichtig moet omspringen met een gevaar als cross-site scripting. Indien een hacker het volgende invult in een inputveld (bijvoor­beeld in het productnaam-veld), wordt duidelijk waar het gevaar om gaat: <script>alert(‘Kwetsbaar voor XSS’);</script>. Indien deze input niet mooi gefilterd wordt, dan zal de browser deze input niet louter als tekst bekijken, maar zal deze effectief geïnterpreteerd worden wanneer een bezoeker die bepaalde pagina opent: er verschijnt onverwachts een pop-up met het woord ‘Kwets­baar voor XSS’ (figuur 3 en 4).

           

Figuur 3. Voorbeeld van een mogelijke aanvalssector ( XSS)                         figuur 4. Voorbeeld resultaat bij onvoldoende filtering tegen XSS

Het mag duidelijk zijn dat de ingegeven code bij dit soort aanvallen opgeslagen wordt door de webapplicatie (bijvoorbeeld in de databank in het veld ‘productnaam’), vandaar de typering ‘opgeslagen XSS’. Een belangrijke voorwaarde die voldaan moet zijn vooraleer een aanvaller deze aanvalstechniek kan gebruiken, is dat gebruikers op een of andere manier eigen inhoud kunnen toevoegen. Sinds de Web 2.0-revolutie is er ech­ter zeer vaak voldaan aan deze voorwaarde.

Een andere voorwaarde is dat andere gebrui­kers deze inhoud kunnen bekijken. Dit kunnen normale gebruikers zijn, maar belangrijker nog, het kan ook gaan om beheerders. Deze beheer­ders bekijken vaak inhoud om te controleren of deze overeenkomt met de algemene regels (zoals bij een forum). Aangezien deze beheerders vaak meer rechten hebben dan normale gebruikers, zijn deze een geliefd doelwit van cross-site scrip­ting. Aanvallers zullen immers steeds proberen om authenticatiegegevens te stelen met behulp van XSS, of zullen proberen om een CSRF-aan­val uit te voeren met behulp van XSS. De impact zal uiteraard groter zijn wanneer een persoon met beheerdersrechten gecompromitteerd kan worden. Een XSS-kwetsbaarheid kan door een aanvaller gebruikt worden om het volledige uitzicht en de functionaliteit van de website te wijzigen. Ook (authenticatie)cookies kunnen in sommige gevallen gekopieerd worden. Hoewel het gemeengoed is om te testen op XSS door te trachten een eenvoudige pop-up te laten ver­schijnen (zoals in het voorbeeld hierboven), is dit louter een snelle test en zal de aanval zelf veel meer schade kunnen aanrichten. De ana­tomie van deze aanval wordt gevisualiseerd in figuur 5.

Figuur 5. Opgeslagen XSS

injec­ producten

Gereflecteerde

Gereflecteerde cross-site scripting-aanvallen hebben hetzelfde doel als opgeslagen cross-site scripting-aanvallen: uitvoeren van Javascript-co­de die de aanvaller zelf heeft samengesteld. De uitvoering van de aanval verschilt echter. Waar de opgeslagen vorm tot doel heeft om opgesla­gen te worden (bijvoorbeeld in de databank), gaat de gereflecteerde vorm enkel proberen om parameters in de URL zo aan te passen dat deze gezien worden als uitvoerbaar script. Zodoende dient een aanvaller geen code te injecteren in de databank van de webapplicatie, maar is het voldoende om een link te sturen naar het slacht­offer, met speciale parameters. Zulke parameters worden soms rechtstreeks gebruikt in de pagina, waardoor deze vatbaar zijn voor een cross-site scripting-aanval.

Stel dat een website de gebruiker doorstuurt naar een foutpagina telkens als er iets fout gaat. Om er geen nietszeggende foutmelding van te maken, wordt er ook een URL-parameter meegegeven met meer uitleg: http://<site>/erroroccurred. aspx/?status=500&error=Er is iets misgelopen. De server interpreteert dit als een instructie om de errorpagina in te laden met het bericht ‘Er is iets misgelopen’. Stel nu dat een aanvaller boven­staande link aanpast naar http://<site>/erroroccurred.aspx/?status=500&error=<script> alert(‘Hello’)</script>, en deze doorstuurt naar de gebruiker. Indien de gebruiker deze link opent, wordt het script uitgevoerd. De anatomie van deze aanval is gevisualiseerd in figuur 6.

Figuur 6. Gereflecteerde XSS

Uiteraard is ook hier een voorwaarde voor het welslagen van deze aanval dat er geen adequate filtering gebeurt op de server. Bovendien worden ontwikkelaars hier ook geholpen door de brow­serontwikkelaars, omwille van het feit dat vele browsers standaard scripts weren uit de URL.

DOM-gebaseerd

De laatste vorm van XSS is de DOM-gebaseer­de. DOM staat voor Document Object Model, wat een taalonafhankelijke standaard is voor het interpreteren, weergeven en interageren met objecten in een webpagina. Zo specifieert het bij­voorbeeld de hiërarchie van deze objecten. Javas­cript kan deze standaard gebruiken om objecten van een webpagina gericht aan te spreken.

Een DOM-gebaseerde aanval verloopt nage­noeg gelijk aan een gereflecteerde aanval. Het enige verschil tussen deze twee types is dat een DOM-gebaseerde aanval nooit in de logs van de webapplicatie zal verschijnen, omdat de te injec­ teren code nooit langs de server zal passeren. We nemen opnieuw hetzelfde voorbeeld als bij de gereflecteerde aanval: http://<site>/erroroccurred. aspx/?status=500&error=<script>alert(‘Hello’) </script>. Vaak zullen de parameters op de server geïnterpreteerd worden om te beslissen welke pagina er weergegeven moet worden. De ‘500’ statuscode kan zo tot een andere pagina leiden dan een andere foutcode. Indien dit gebeurt, gaat het om een gereflecteerde aanval. Soms is het echter zo dat de server enkel de pagina zal aan­leveren (erroroccurred.aspx), en dat er via Javas­cript voor wordt gezorgd dat de pagina verschilt naargelang de foutcode. In dat geval worden de parameters niet geïnterpreteerd door de server, maar wel door de browser en gaat het om een DOM-gebaseerde cross-site scripting-aanval. De anatomie van deze aanval wordt gevisualiseerd in figuur 7.

Figuur 7. DOM-gebaseerde XSS

 

Request forgery

Een cross-site scripting-aanval gaat zeer vaak samen met een request forgery (RF)-aanval. Toch is er een duidelijk onderscheid tussen deze twee aanvallen. Terwijl XSS als focus het injecteren van Javascript heeft, tracht een aanvaller er via RF voor te zorgen dat een gebruiker een actie (request) uitvoert zonder dat deze gebruiker dit zo bedoelde (forgery). Hoewel bijna iedereen de term cross-site request forgery gebruikt, zijn er twee vormen van request forgery: on-site request forgery (OSRF) en cross-site request forgery (CSRF).

On-site request forgery

On-site request forgery vindt plaats wanneer een aanvaller erin slaagt om de gebruiker een actie te laten uitvoeren zonder dat deze gebruiker dit bedoeld had. Daarenboven moet de actie ver­trekken van het oorspronkelijke domein, anders spreken we van CSRF. Een typisch voorbeeld van zuivere OSRF kan plaatsvinden wanneer gebruikers zelf een profielfoto kunnen kiezen. In html kan dit er als volgt uitzien: <img src= "/images/MichaelBPicture.png" >, waarbij ‘MichaelBPicture’ de naam is van de foto die upgeload is als profielfoto. Deze naam kan zelf gekozen worden. Bij het inladen van de profielpagina gebeurt er een GET-verzoek naar deze foto: “GET /images/MichaelBPicture.png”. Stel nu dat we de naam van onze foto wijzigen naar: “../admin/newUser?username=hacker&­password=hacked&role=admin#”. In essentie zal er dan een GET gebeuren naar “/images/../ admin/newUser?username=hacker&pass­word=hacked&role=admin#”. De twee puntjes zorgen ervoor dat er een folder omhooggegaan wordt. We springen dus uit de ‘images’-folder, rechstreeks naar de ‘admin’-folder. Indien we dan veronderstellen dat er gebruikersaccounts aangemaakt kunnen worden via een eenvoudig GET-verzoek naar de ‘newUser’-pagina, wordt er een nieuwe gebruiker met beheerdersrechten aangemaakt met gebruikersnaam ‘hacker’ en wachtwoord ‘hacked’.

In bovenstaand voorbeeld zou iedereen die mijn profielpagina bezoekt slachtoffer zijn. Iedereen die mijn pagina bezoekt, stuurt immers onbe­wust het valse verzoek uit (op het moment dat mijn profielfoto ingeladen wordt). De meeste verzoeken zullen echter geblokkeerd worden, aangezien enkel beheerders nieuwe gebruikers kunnen aanmaken. Als aanvaller zijn we geduldig en vanaf het moment dat iemand met beheer­dersrechten mijn pagina bezoekt, zal de nieuwe account aangemaakt worden. De server zal wel een authenticatie uitvoeren, maar aangezien het verzoek vertrekt van de machine van de beheer­der, wordt het verzoek geaccepteerd. De anato­mie is gevisualiseerd in figuur 8.

Figuur 8. On-site request forgeryCross-site request forgery

Een cross-site request forgery aanval is zeer gelijkaardig aan on-site request forgery. Het verschil is dat het verzoek bij CSRF zal vertrek­ken van een andere website, typisch een website die gecontroleerd wordt door de aanvaller. Deze aanval is in essentie eenvoudiger uit te voeren dan OSRF, aangezien de controle over de web­pagina in handen ligt van de aanvaller. De hacker moet er dan enkel voor zorgen dat zijn website automatisch een verzoek initieert naar de legi­tieme website vanaf het moment dat iemand zijn website bezoekt. Het moeilijkste deel van de aanval bestaat er dan in om het slachtoffer naar de website van de aanvaller te lokken. Stel dat een aanvaller volgende link mailt naar een slacht­offer: http://www.biglottery.com

Deze code zal een POST-verzoek uitsturen naar http://www.target.com/createAdminmet twee parameters: ‘username’ en ‘password’. Het is per­fect toegestaan om een verzoek te initiëren naar een ander domein, dit is een van de essentiële kenmerken van het internet. Indien we er dan vanuit gaan dat de hacker weet dat enkel de para­meters ‘username’ en ‘password’ nodig zijn om een (valse) gebruiker aan te maken, wordt er een gel­dig verzoek uitgestuurd in naam van het slachtof­fer. Dit verzoek zal automatisch verstuurd worden na 200 milliseconden, waarna het browservenster automatisch zal sluiten. Indien het slachtoffer goed oplet ziet deze een pop-up openen, die meteen weer sluit. Dit doet bij gebruikers mis­schien een wenkbrauw fronsen, maar meer niet. Belangrijk (net zoals bij OSRF) is uiteraard dat het verzoek enkel succesvol uitgevoerd zal wor­den indien de gebruiker die het verzoek initieert voldoende rechten heeft. De aanvaller zal deze link dus versturen naar een beheerder. Indien die de ‘biglottery’-site bezoekt, en indien hij op dat moment ook aangemeld is, zal de aanval lukken. Authenticatiecookies worden immers meege­stuurd met elk verzoek naar het domein waaraan de cookie gelinkt is. Daarbij is er vaak aan de vereiste van aangemeld zijn voldaan, omwille van de ‘onthoud me’ functionaliteit (figuur 10).

Figuur 10. Cross-site request forgery

XSS in combinatie met RF

Vaak gebruiken aanvallers XSS in combinatie met RF. Hét voorbeeld hiervan is de ‘Samy-worm’, die zich richtte op de MySpace-website. Gebrui­kers van MySpace konden een eigen pagina aanmaken, waarbij ze een afgeslankte versie van html-code mochten gebruiken. Dit gaf gebrui­kers de mogelijkheid om hun openbare pagina zelf vorm te geven. De cross-site scripting-tech­niek was toen echter ook al bekend, vandaar dat niet alle html-tags beschikbaar waren. Zo werden script-tags, doorverwijzingen en andere typische gevaarlijke tags geweerd. Eén gebruiker, Samy genaamd, kon deze anti-XSS filters echter omzeilen en dus eigen Javascript injecteren op zijn publieke profielpagina. Deze code werd dan ook uitgevoerd telkens als er iemand deze pagina bezocht. Samy had geen slechte bedoelingen, hij wilde enkel meer ‘vrienden’. Daarom zorgde hij ervoor dat de geïnjecteerde code automatisch een vriendschapsverzoek uitstuurde naar Samy. Iedereen die een geïnfecteerde profielpagina bezocht, zou dus ongemerkt een vriendschaps­verzoek sturen naar Samy. Samy zorgde er verder ook voor dat dezelfde code geïnjecteerd werd op de profielpagina van de bezoeker. Zodoende zou de impact exponentieel groeien. Samy zette de code half één ’s middags online. Hij had op dat moment 73 vrienden. Een uur later had hij slechts één nieuw vriendschapsver­zoek en begon hij zich af te vragen of zijn code wel werkte. Twintig uur later had Samy meer dan 1 miljoen vriendschapsverzoeken en wordt de website offline gehaald voor ‘onderhoudswerken’.

Samengevat kon Samy Javascript injecteren op zijn publieke profielpagina (XSS), waarmee hij automatisch een verzoek initialiseerde in naam van elke gebruiker die zijn pagina bezocht (OSRF). De combinatie XSS-OSRF wordt dan ook zeer vaak gebruikt, omwille van de enorme kracht van zo’n aanval. De andere variant, CSRF, zal in combinatie met XSS vaak gebruikt worden om vanuit slecht beveiligde websites verzoeken uit te sturen naar andere websites. Stel immers dat een aanvaller weet dat jij als slachtoffer bepaalde websites bezoekt, kan de aanvaller er de minst beveiligde website uitkiezen om daar een XSS-aanval op uit te voeren. Het geïnjecteer­de script zal dan een request uitsturen naar een andere, beter beveiligde website (CSRF). Vanuit het oogpunt van de hacker geniet dit de voor­keur, aangezien het dan niet meer nodig is om de gebruiker eerst naar een malicieuze website te lokken, om van daaruit een verzoek te initiëren. De gebruiker dient simpelweg de slecht beveilig­de website te bezoeken.

Waarom beveiligen tegen XSS en RF?

De vraag blijft natuurlijk wat een aanvaller kan doen wanneer een webapplicatie niet beveiligd is tegen XSS- en RF-aanvallen. Zeer veel, zo blijkt. De impact van request forgery is heel eenvoudig: een hacker kan elke actie vervalsen. De drie voorwaarden die voldaan moeten zijn voor het welslagen van een RF-aanval, zijn de volgende:

legitieme gebruiker is geauthenticeerd

legitieme gebruiker bezoekt website die gecon­troleerd wordt door de aanvaller (bijvoorbeeld via social engineering of ‘watering hole’-techniek)

de website die wordt aangevallen heeft geen beveiliging tegen CSRF geïmplementeerd

 

XSS aan de andere kant, kan voor andere doel­einden worden gebruikt. Een aanvaller kan bijvoorbeeld de lay-out en functionaliteit van de gehele pagina wijzigen. Stel dat een aanvaller een XSS-aanval uitvoert op de site van LinkedIn. Wanneer je deze aanvaller zijn profiel bezoekt, komt er een officieel lijkende mededeling dat de sessie verlopen is en dat je opnieuw dient in te loggen. Dit is het resultaat van de XSS-aanval: de aanvaller heeft via een XSS-kwetsbaarheid de volledige DOM kunnen hervormen. Je zit echter nog steeds op het domein van LinkedIn (via HTTPS), en gaat er dus vanuit dat de mede­deling legitiem is. Achterliggend echter wordt je gebruikersnaam en wachtwoord in een privé­bericht naar de aanvaller gestuurd via Javascript (OSRF). Om niet opgemerkt te worden, laat de aanvaller daarna gewoon zijn profiel zien en wordt het bericht automatisch verwijderd uit je verzonden berichten. Al deze acties kunnen geïnitieerd worden door Javascript, waardoor dit een aanval is met een grote potentiële impact.

Andere doeleinden van XSS kunnen zijn om onbeschermde authenticatiecookies te stelen of simpelweg om gebruikers door te verwijzen naar een malicieuze website waar malware wacht.

Verdediging

Gelukkig bestaan er verdedigingsmechanismen die een webapplicatie kan implementeren om zich te beschermen tegen XSS en RF.

Voor XSS is de theorie eenvoudig: valideer en filter alle gebruikersinput en alle output die getoond wordt. Alle inhoud van gebruikers zou een zeer streng filterproces moeten ondergaan, zodat het zeker is dat er geen verborgen Javas­cript opgeroepen wordt. Hoewel het aan te raden is om de inhoud reeds te filteren voordat deze opgeslagen wordt (bij opgeslagen XSS), is het steeds noodzakelijk om de filtering uit te voeren in het laatste stadium, dat wil zeggen net voordat de inhoud aan de gebruiker getoond zal worden. Een eenvoudige filter zou de ‘<script>’- tag kunnen weren. Dit is echter niet voldoende. Bekijk bijvoorbeeld de volgende XSS-aanvallen (OWASP, 2014):

<IMG SRC= onmouseover="alert('xxs')">

<STYLE type="text/css">BODY{background:url ("javascript:alert('XSS')")}</STYLE>

<IFRAME SRC="javascript:alert('XSS');"> </IFRAME>

<EMBED SRC="data:image/svg+xml;base64,PHN2ZyB 4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwM DAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd 3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaW dodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5c­GU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg=="type="image/ svg+xml" AllowScriptAccess="always"></EMBED>

Deze zijn alle potentieel gevaarlijk, omdat er methodes worden uitgevoerd die niet oorspron­kelijk zo bedoeld waren door de ontwikkelaar. Het is niet onoverkomelijk om alle input zelf te filteren, maar het wiel hoeft uiteraard niet opnieuw uitgevonden te worden. OWASP (het Open Web Application Security Project) is een goede en up-to-date bron van informatie omtrent allerhande webapplicatiedreigingen. Zij hebben een bruikbare tool ontwikkeld om input op een goede manier te filteren (www.owasp.org).

Ook tegen RF kan een applicatie beschermd worden. Het is van belang om in te zien dat OSRF andere maatregelen vereist dan CSRF. OSRF-maatregelen zijn sterk vergelijkbaar met de maatregelen die genomen moeten worden om te beschermen tegen XSS: valideren van gebrui­kersinput. In het voorbeeld waarbij de gebruiker een profielfoto kon uploaden, zou het onmogelijk gemaakt moeten worden dat de gebruiker zelf de bestandsnaam kan kiezen. De server dient idealiter zelf een naam toe te kennen die niets te maken heeft met de bestandsnaam die de gebrui­ker aan het bestand had gegeven. De vuistregel is steeds dat gebruikersinput nooit rechtstreeks in de html-pagina mag worden geïnjecteerd.

CSRF vereist een ander verdedigingsmecha­nisme. De aanvaller heeft immers volledige controle over de eigen html-pagina. De aanvaller tracht zo een verzoek te initiëren in naam van het slachtoffer die de website van de aanvaller bezoekt. De kennis omtrent dit verzoek heeft de aanvaller opgedaan door zelf de legitieme website te bezoeken. De hacker weet immers dat het verzoek er hetzelfde zal uitzien voor elke bezoe­ker. De kunst om CSRF tegen te gaan is dan ook om ervoor te zorgen dat elk verzoek uniek is per gebruiker. Hiervoor geven we een uniek geheim mee bij het inladen van elke pagina. Dit geheim kan bijvoorbeeld bestaan uit een code van tien karakters, welke gegenereerd wordt op de server en uniek gekoppeld wordt aan de actieve gebrui­ker. De aanvaller kan onmogelijk weten wat dit geheim is, aangezien deze geen manier heeft om de code uit de html van het slachtoffer te halen. Belangrijk is dat we veronderstellen dat de website ook beveiligd is tegen XSS, anders zou dit wel mogelijk zijn. Dit geheim moet bij het volgende verzoek worden teruggestuurd naar de server, anders wordt het verzoek geweigerd. De server vergelijkt beide geheimen en indien deze gelijk zijn én indien deze gekoppeld zijn aan de gebruiker die het verzoek initieerde, wordt het verzoek geaccepteerd. Figuur 11 visualiseert dit principe. Belangrijk is dat de anti-CSRF-token niet teruggestuurd mag worden naar de server in een cookie. Cookies worden immers automatisch meegestuurd bij elk verzoek en dus ook bij een verzoek dat geïnitieerd wordt van de website van de aanvaller. Mogelijke plaatsen om een CSRF-token te plaatsen zijn de html-code (als een verborgen veldje) of in een HTTP-header.

Figuur 11. Anti-CSRF-token

Conclusie

XSS en RF zijn technieken die er beide op gericht zijn om acties uit te voeren in de browser van het slachtoffer. Ze worden vaak in combi­natie met elkaar gebruikt, maar beide aanvallen vereisen een andere bescherming. Een effectieve bescherming tegen cross-site scripting bestaat uit het filteren van gebruikersinput en het filteren van de weergegeven output.

Bescherming tegen cross-site request forgery wordt geboden door de introductie van een geheim dat onmogelijk gekend kan zijn door de aanvaller (een anti-CSRF token). Deze bescher­ming is echter waardeloos indien er nog cross-si­te scripting-kwetsbaarheden zijn. De aanvaller zou de waarde van de anti-CSRF token immers via cross-site scripting kunnen opvragen.

Michael Boeynaems

is Business Architect bij The Master Labs

E-mail: Michael.Boeynaems@themasterlabs.com

 

 

 
 
 
In oktober vieren we altijd de herfst, en kijken we zowel terug als vooruit. Over het World Computer Congres 2012 (WCC 2012) schreven we al eerder. In deze Informatie volgen nog meer impressies. Met meer dan vijfhonderd inschrijvingen voor het congres zijn we tevreden. WCC 2012: deelnemers uit 31 landen, praten over de issues van de IT op dit moment en vooruitkijken naar de rol van informatieprofessional van de toekomst. Een rijke inhoudelijke oogst uit het WCC 2012 en het Ngi Jaarcongres. Een oogst die het Ngi weer inspireert voor 2013. Met kennissessies van Rik Maes en natuurlijk met de diverse evenementen geven we verdere invulling aan de informatieprofessional 3.0. We hopen dan ook van harte dat de overleggen met het VRI leiden tot een samensmelting van onze beide organisaties voor het einde van dit jaar. In 2013 kunnen we dan het samengaan met NGN concretiseren. Het bestuur werkt samen met veel actieve leden aan diverse initiatieven, nieuwe afdelingen en onze bekendheid binnen het werkveld. Help ons daarbij en neem je collega’s uit je netwerk mee naar de events van het Ngi. Samen bouwen we zo aan ons netwerk en bouwen we aan een organisatie die de informatieprofessional 3.0 kan leveren! Het bestuur
Werkgroep over digitalisering Informatie
Sinds lange tijd krijgt u het blad Informatie in de bus, vol wetenswaardigheden over ontwikkelingen in de digitale wereld. Aan een belangrijke ontwikkeling in die digitale wereld heeft het blad zelf zich tot nu toe onttrokken. Diverse media verschijnen in toenemende mate in digitale vorm in plaats van op papier. Ngi, SAI en Sdu willen onderzoeken of en zo ja hoe dit voor het blad Informatie haar beslag kan krijgen. Er wordt een werkgroep gevormd die deze vraagstelling zal oppakken. Op basis van de rapportage en afstemming met de leden kan dan bepaald worden hoe verder. Wilt u een bijdrage leveren aan deze werkgroep of heeft u anderszins ideeën over dit onderwerp, laat het ons weten via:

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag