INFORMATIEBEVEILIGING

Transcriptie

1 k S o DO s en u i in tw itt fa c e b oo ERs I S t o br r aja x go o februari 2009 nummer 1 rs e ws er sa fa Multifunctionele printers, uitvalsbasis voor hackers? Forensische softwarepakketten onder de loep Boekentip: Identity Crisis van Jim Harper INFORMATIEBEVEILIGING Dossier: Browsers, de ins en outs hrome ec l g IB indd :53:58

2 ajax google chrome browsers DOSSIER ins en outs twitter facebook safari (in)security 2.0? Auteur: Rob Hofker > Rob Hofker is senior consultant bij Senet Zwolle en eigenaar van Roho Products, web development en advies. Hij heeft ruim vijftien jaar ervaring in het ontwikkelen van applicaties in bedrijfsmatige omgevingen. Informatiebeveiligingservaring heeft hij opgedaan bij Bouwfonds Property Finance en Senet Zwolle. Ook is hij betrokken geweest bij de ontwikkeling van onder meer de Univé website en meerdere projecten bij grote opdrachtgevers zoals de Belastingdienst. Hij is te bereiken via: rob. Met dank aan: Ard Broos, senior software architect, Senet Zwolle, voor advies en aanvullingen. Er zijn op dit moment veel ontwikkelingen gaande op het internet. Bijna te veel om bij te houden. Een aantal jaren geleden was er de Nieuwe Economie die oneindig groot leek tot de Dot Com Bubble uit elkaar spatte. Daarna echter waren er kleine bedrijfjes en individuen die met allerlei slimme toepassingen nieuwe ideeën en nieuwe hoop brachten bij webontwikkelaars en -ondernemers. Die periode en ook de toepassingen die daarin ontstonden, wordt aangeduid met Web 2.0. Web 2.0 geeft de tweede fase aan van de ontwikkeling van het World Wide Web. Losse websites veranderen langzaam maar zeker naar een coherent platform voor interactieve webtoepassingen. Het web wordt daarmee eigenlijk pas echt een samenhangend web. Uiteindelijk komen de toepassingen zo dicht bij de desktop dat een standaard gebruiker inmiddels zijn mail en kantoortoepassingen geheel online kan doen. Lokaal geïnstalleerde software raakt daardoor langzaam maar zeker overbodig. Andere technologieën en toepassingen die Web 2.0 aspecten hebben, zijn blogs, wiki s, newsfeeds (RSS) en webservices die toegankelijk zijn met APIs. In het bijzonder deze Application Programming Interfaces geven ontwikkelaars de mogelijkheid om allerlei diensten aan elkaar te knopen en bijzondere toepassingen te maken. Een website die door het aan elkaar koppelen van verschillende services weer een nieuwe bron van informatie vormt, wordt ook wel een mashup genoemd. Actievere rol voor de browser Een ander aspect van Web 2.0 toepassingen is dat veel van de dataverwerking plaatsvindt in de browser en minder op de server. Traditionele webpagina s zijn in grote mate statisch en er zit slechts in beperkte mate code in die op de computer van de bezoeker wordt uitgevoerd. De server levert de content en de browser toont deze. In Web 2.0 toepassingen communiceert de browser min of meer zelfstandig met de webserver en verwerkt invoer en keuzes van de gebruiker. De server levert nu veel meer de data die door de browser verwerkt wordt tot informatie. Op de server draait een applicatie geschreven in bijvoorbeeld PHP, ColdFusion of ASP.NET. In de browser is dat veelal JavaScript. Andere voorbeelden van code in de browser zijn: Java, Flash, SilverLight en Adobe Air. Voor deze technologieën is echter steeds een browser plugin nodig, een stukje software dat het mogelijk maakt gebruik te maken van de specifieke technologie om gedurende de levensduur van een webpagina te zorgen dat er dynamisch wat verandert aan de statische inhoud van de pagina. In feite draait hier een applicatie binnen de browser (via de plugin) die vaak geen directe invloed heeft op de pagina waarin de applicatie is ingevoegd. Op dit moment is AJAX sterk in opkomst. AJAX is duidelijk anders dan de hiervoor genoemde mogelijkheden omdat in de browser geen aparte plugin nodig is. Enkel JavaScript is noodzakelijk om de toepassing te laten werken. AJAX AJAX is veelal het drijvende idee achter de Web 2.0 websites, zeker voor wat betreft de voorkant van de website, de pagina s zoals die verschijnen in de browser van de bezoeker. Stukje geschiedenis AJAX is een term die in februari 2005 voor het eerst werd gebruikt in een artikel van Jesse James Garrett van Adaptive Path. ( essays/archives/ php). AJAX is een afkorting van Asynchronous Javascript And XML. Het is een ontwerp voor interactieve webpagina s waarin met behulp van JavaScript op asynchrone wijze gegevens worden opgehaald van een webserver. De communicatie met de server verloopt door gebruik te maken van het XMLHttpRequest commando, dat door Microsoft aan JavaScript in Internet Explorer 5 werd toegevoegd. Ook de invoering van het Document Object Model (DOM) om met JavaScript de onderdelen van de webpagina te benaderen (W3C-aanbeveling van 1998) maakt het gebruik van AJAX mogelijk. Het resultaat is dat webpagina s niet meer in zijn geheel ververst hoeven te worden, maar dat dat in kleine stukjes gebeurt. Een mooi voorbeeld is de Google Suggest functionaliteit, waarbij na elke toetsaanslag een nieuwe reeks zoektermen in een lijstje wordt getoond zonder dat de pagina wordt ververst. Dit gebeurt ook nog eens zo snel dat het voor de meeste gebruikers niet duidelijk is dat er hier telkens gegevens worden opgevraagd van een webserver. Daarmee is de applicatie onderdeel van de browser geworden. Om te begrijpen wat AJAX inhoudt, is het van belang te begrijpen wat het verschil is tussen synchrone en asynchrone communicatie. Synchrone communicatie Bij synchrone communicatie verstuurt de client een vraag en deze wacht vervolgens op een antwoord. Na ontvangst van het antwoord wordt de uitkomst getoond in de browser. Het betreft hier het veelal compleet opnieuw laden van een pagina. Het versturen van de vraag gaat door middel van een complete postback, waarbij in het geval van een formulier alle ingevulde velden in één keer naar de server worden verstuurd. Zie het volgende figuur (figuur 1). 14 Informatiebeveiliging februari 2009 IB indd :09:23

3 Figuur 1: Klassieke websites werken met synchrone communicatie Na elke actie van de gebruiker wordt er een compleet nieuwe pagina opgehaald van de server. Zelfs bij een kleine pagina en een snelle verbinding is dit voor de gebruiker altijd duidelijk waarneembaar. Asynchrone communicatie Bij asynchrone communicatie is er in de browser een proces actief, soms wel aangeduid als de AJAX engine die de gebeuren of enige tijd later of helemaal niet. In het onderstaande voorbeeld is er input van de gebruiker die doorgegeven wordt aan de server. Voor het antwoord terugkomt, is er nog een input van de gebruiker die binnen de browser wordt afgehandeld. Pas daarna (asynchroon!) komt het antwoord van de server terug die zorgt voor het bijwerken van het scherm. Het gehele proces speelt zich af zonder dat er een compleet nieuwe pagina geladen wordt. 3. XML en XSLT voor de opslag, aanpassing en transport van gegevens. In sommige gevallen wordt dit vervangen door JSON (JavaScript Object Notation). 4. Het XMLHttpRequest object voor asynchrone communicatie met de backend server. 5. JavaScript om alles aan elkaar te binden. De asynchrone requests worden veelal op de webserver door een webservice afgehandeld. Een webservice is te zien als een speciaal soort website die requests niet beantwoord met een webpagina, maar met een in XML gestructureerd antwoord. Een webservice heeft een of meerdere zogeheten webmethodes die op basis van een aantal vastgestelde argumenten een vastgesteld antwoord teruggeven. Dit antwoord kan komen in de vorm van data die dan in de browser weer verder wordt verwerkt, maar het kan ook een compleet blok HTML code zijn die in het HTML document wordt ingevoegd. Verschil tussen Web 1.0 en Web 2.0 Kort samengevat is het verschil tussen traditioneel web 1.0 verkeer en web 2.0 verkeer met AJAX: traditioneel webverkeer webpage laadt in één keer, elke interactie (link of knop) zorgt voor een call naar de server en levert een compleet nieuwe pagina op, een complete PostBack. webverkeer met AJAX webpage laadt in één keer, maar elke interactie zorgt voor een call naar de server en levert een nieuw stukje van de pagina op, de interactie kan ook niet direct door de gebruiker worden getriggerd, maar door een timer of als reactie op het resultaat van een andere call, gedeeltelijke PostBacks. feitelijke communicatie verzorgt met de webserver. De aanduiding AJAX engine is niet volledig juist, want het zijn JavaScript functies die worden aangeroepen en het is niet een zelfstandig draaiend proces. In de figuur hierboven (figuur 2) is aangegeven hoe gebruikersacties worden verwerkt met JavaScript. De JavaScript engine in de browser stuurt de vraag door naar de server of handelt deze zelf af. Het verwerken van een antwoord kan direct Figuur 2: Asynchrone communicatie AJAX = Combinatie van technologieën Met AJAX kunnen interactieve web applicaties worden ontwikkeld. Het is in feite een combinatie van de volgende vijf technologieën: 1. XHTML en CSS voor de presentatie volgens de standaarden van het W3C. 2. Het Document Object Model (DOM) voor het dynamisch tonen van informatie en voor interactie. Het is duidelijk dat het toepassen van AJAX de snelheid zoals die door de gebruiker wordt ervaren aanmerkelijk verhoogt, de pagina s verversen niet compleet, maar steeds kleine stukjes van de pagina. Een webpagina is daarmee veranderd van een in wezen statische pagina naar een applicatie die draait binnen de browser. Om van AJAX gebruik te kunnen maken hoeft de browser enkel JavaScript te ondersteunen en dit moet uiteraard niet uitgeschakeld zijn. Informatiebeveiliging februari IB indd :09:26

4 (in)security 2.0? Het is aan de website eigenaar om te beslissen of er ook een oplossing wordt geïmplementeerd voor gebruikers zonder JavaScript of zij die dit hebben uitgeschakeld. Maar het is wel zo correct om dat te doen. De functionaliteit zou dan ook geïmplementeerd moeten worden met normale volledige PostBacks. Risico s van Web 2.0 en AJAX Veel van de risico s van Web 2.0 en AJAX gelden ook voor technologieën als Java en Silverlight. De focus in dit artikel ligt op AJAX. Onvoldoende bewustwording van de ontwikkelaar Een ontwikkelaar moet zich ervan bewust zijn dat, ondanks dat veel werk gedaan wordt in de browser, niet alles aan clientzijde kan worden afgehandeld. Input validatie, uitvoer versleuteling en toegangscontrole kunnen niet uitsluitend aan clientzijde worden uitgevoerd. De browser kan helpen bij deze processen, maar de controles moeten op de server nog een keer in zijn geheel worden gedaan. Een ontwikkelaar dient hiervan doordrongen te zijn en niet gemakshalve de controles slechts één keer uit te voeren. Dit is op zich niets nieuws voor webontwikkeling, maar doordat bij AJAX veel meer code in de browser draait, is vergaande bewustwording van de ontwikkelaar noodzakelijk. Uitgebreidere communicatie met webserver In plaats van de enkele pagina die wordt opgevraagd, zijn er nu meerdere requests richting de server voor de levensduur van een pagina. Deze requests vinden niet allemaal gelijktijdig plaats, maar in wezen zijn het nog steeds dezelfde soort requests en ze brengen dus dezelfde soort risico s met zich mee. Request spoofing Zoals gezegd wordt de serverzijde van een AJAX applicatie veelal uitgevoerd met webservices. De vragen aan die webservices worden in JavaScript samengesteld en vervolgens verstuurd vanuit de browser. Deze AJAX requests zijn eenvoudige webcalls via het http protocol en kunnen dus ook nagemaakt worden. Met een debug tool (zoals de Firefox extensie FireBug) kan eenvoudig worden gezien welke asynchrone requests er verstuurd worden naar de server. Deze requests kunnen vervolgens eenvoudig nagemaakt worden en naar believen aangepast. Dit namaken wordt request spoofing genoemd. Een login scherm dat gebruikmaakt van AJAX heeft daarmee dus een mogelijk risico. Indien hier een openbaar toegankelijke webservice mee wordt aangeroepen, is het vrij eenvoudig een tool te schrijven die meerdere combinaties van gebruikersnaam en wachtwoord kan uitproberen. Dit houdt in dat elke asynchrone aanroep naar de webserver per definitie niet vertrouwd mag worden, want het is nauwelijks te achterhalen of de pagina vanaf de webpagina komt of nagemaakt is. Er zal te allen tijde validatie op moeten plaatsvinden. Legale request spoofing Veel Web 2.0 sites moedigen juist request spoofing aan doordat ze hun services aanbieden in de vorm van een API. Volledig gedocumenteerd geven ze zichzelf vrij zodat de hele wereld er gebruik van kan maken. Indien een API wordt aangeboden dan worden in feite de sleutels van het fort buiten de deur aan een spijkertje gehangen. Het is dan wel zaak dat de bezoekers alleen in het openbare gedeelte mogen komen en dat de rest van het fort nog steeds goed afgesloten blijft. DOS mogelijkheid De hiervoor geschetste request spoofing biedt ook weer een eenvoudige mogelijkheid om een Denial-of-service (DOS) aanval uit te voeren. Het is een kleine moeite om een programma te schrijven dat in korte tijd een groot aantal aanroepen uitvoert en zo een server bijvoorbeeld uitgebreide database queries laat uitvoeren. Om dit soort misbruik te voorkomen is het zaak een uitgebreide logging toe te passen waarbij gekeken wordt of vanaf een bepaald ip adres in een korte tijd niet buitensporig veel requests komen. AJAX encryptie biedt geen soelaas Request spoofing en problemen rond autorisatie lijken misschien op te lossen door de te versturen gegevens versleuteld te versturen. Versleutelde gegevens zijn nu eenmaal veel lastiger na te maken. Maar dat werkt bij AJAX dus helemaal niet, want de code die dat verzorgt, wordt met de pagina meegezonden in de vorm van JavaScript routines. Iemand die misbruik wil maken heeft de originele code die gebruikt wordt voor de encryptie en hoeft geen enkele moeite te doen die te doorbreken. Verwarring rond validatie Het kan niet vaak genoeg herhaald worden dat net als bij traditionele webtoepassingen ook bij AJAX validaties altijd aansluitend ook aan de serverzijde plaats moeten vinden. Extra validaties aan de clientzijde zijn een extra service aan de bezoeker, maar de uiteindelijke verantwoording van de controles ligt op de server. Clientvalidatie is altijd op eenvoudige wijze te omzeilen en dus moet een ontwikkelaar er altijd vanuit gaan dat de inkomende data nog niet gevalideerd zijn. Dit blijft een stuk verwarring voor ontwikkelaars die zo gedegen hun validaties in JavaScript hebben uitgewerkt en getest. Bovendien geeft de JavaScript code vaak inzicht in de gebruikte validatiemethodieken en is het aannemelijk dat validatiefouten aan de clientzijde op gelijke wijze aan de serverzijde voorkomen. Minder signalen voor gebruiker Doordat veel van AJAX onzichtbaar gebeurt, heeft de gebruiker nauwelijks in de gaten dat er requests naar een webserver plaatsvinden. Het balkje in de browser wordt niet of nauwelijks meer geactiveerd, want de requests gaan over het algemeen zo snel dat dit niet waarneembaar is. AJAX werkt op de achtergrond en haalt onzichtbaar informatie op en voegt die toe aan de DOM (Document Object Model). Gebruik waar mogelijk en nodig visuele signalen (een zandloper, animated gif) 16 Informatiebeveiliging februari 2009 IB indd :09:30

5 om gebruikers te informeren dat er zaken op de achtergrond gebeuren. Dit zal in de praktijk vaak niet mogelijk zijn. Een gebruiker zal daarom vaak niet zien dat er van alles gebeurt. AJAX geeft meerdere end points en verborgen calls Een end point is een overgang van server naar client en omgekeerd. Een traditionele webpagina simpel gesteld heeft slechts twee end points: het versturen van de pagina van server naar client en de PostBack van de client naar de server. Een pagina met AJAX heeft er vele. Deze end points kunnen bovendien ook meerdere keren worden gebruikt. Elk end point afzonderlijk moet van voldoende validatie en controles worden voorzien om er zeker van te zijn dat de communicatie veilig en vertrouwd verloopt. Gegevens van untrusted bronnen In Web 2.0 toepassingen worden vaak gegevens van meerdere bronnen bij elkaar genomen om tot een nieuw informatief geheel te komen. Denk daarbij aan geografische gegevens (bijvoorbeeld Google Maps) en diverse RSS feeds van andere bronnen. Hiermee zijn zogeheten mashups te maken. Deze bronnen zijn meestal niet allemaal onder eigen beheer. De inhoud van deze bronnen is nauwelijks te voorspellen en kan dus onverwachte resultaten opleveren. Hiermee introduceren we mogelijk een nieuwe zwakke schakel: een cross domain vulnerability. Goede validatie en foutafhandeling zijn ook hier noodzakelijk. Omdat we clientvalidatie zoals gezegd niet kunnen vertrouwen, is het ook hier aan te bevelen om de verwerking van de gegevensstromen zoveel mogelijk gecontroleerd te laten verlopen op de server. Data serialisatie Een browser die een AJAX call uitvoert, serialiseert data en stuurt deze naar de server. Serialiseren is het omzetten van waarden naar een tekstformaat. Alle communicatie over het web bestaat in feite uit tekstbestandjes die heen en weer gestuurd worden. Dit serialiseren kan naar bijvoorbeeld XML-formaat. Dit is een eenvoudig te lezen formaat. Ook zijn ze relatief eenvoudig te wijzigen. Met een browser debug tool als FireBug kan de inhoud van een dergelijk datapakketje gewijzigd worden en kunnen er foute of zelfs gevaarlijke gegevens verstuurd worden. Weer een reden waarom een AJAX call niet vertrouwd mag worden op de server, zelfs wanneer deze van de eigen webpagina afkomstig is. Dus: altijd alles controleren op de server. Is het allemaal zo onveilig? Dit lijkt wel een heel lange lijst met allemaal nieuwe risico s. Een snelle en veilige conclusie lijkt dan ook dat Web 2.0 en AJAX eigenlijk verboden zouden moeten worden. Maar nee, zo erg is het niet. Want voor de ontwikkelaar verandert er in wezen niet echt veel qua beveiliging. In elk geval niet qua filosofie. Het zijn nog steeds eenvoudige webrequests die moeten worden afgehandeld. Alle requests en bijbehorende gegevens moeten op de server nog een keer gecontroleerd worden om uitsluitend valide requests af te handelen. Validatie moet nog steeds altijd op de server gedaan worden. Behalve validatie moet ook op ongeldige of gevaarlijke data worden getest aan zowel de server- als de clientzijde. Een veilige ontwikkelaar is een alles wantrouwende ontwikkelaar. No trust policy Een ontwikkelaar van AJAX applicaties of Mashups moeten zich ervan bewust zijn dat er geen enkele garantie is dat de gegevens die binnenkomen netjes en aan alle verwachtingen voldoen. Beter nog de ontwikkelaar moet er vanuit gaan dat ze er niet aan voldoen en dat alle acties van buitenaf niet te vertrouwen zijn. Eerst alles tot op het bot controleren en dan pas doorlaten voor verdere verwerking. Beperk het risico voor de gebruiker Door de Web 2.0 manier van ontwikkelen is veel van de logica aan het verschuiven naar de browser. Dit levert serieuze risico s op. Het verlangen om data van meerdere bronnen te vermengen tot nieuwe vormen van informatie vergroot de totale risicofactor. Allerlei cross domain problemen kunnen hierdoor worden veroorzaakt. Deze kunnen geminimaliseerd worden door de data validatie en een deel van het verwerken op de server te laten plaatsvinden (preprocessing). Daardoor komt er nette en gecontroleerde data aan in de browser die vervolgens op een voorspelbare wijze kan worden verwerkt. Niets nieuws onder de zon Kort gezegd verandert er niet heel veel aan de soorten gevaren, maar er zijn alleen veel meer ingangen die moeten worden beveiligd. Elke deur moet voorzien zijn van een degelijk slot. Aan de andere kant bestaat er de mogelijkheid om heel soepele applicaties te maken met enorm gebruikersgemak en waarbij data van verschillende bronnen nieuwe informatie kan genereren. Maar een enkele onbeschermde functie of onbetrouwbare bron en de applicatie opent een achterdeur voor misbruik. Nieuwe mogelijkheden Het is echter niet alleen slecht nieuws. AJAX levert ook nieuwe mogelijkheden. Minder capaciteit nodig Het gebruik van AJAX levert niet alleen voor de gebruiker een snellere interface op. Ook de webserver hoeft niet steeds complete pagina s te verwerken en versturen. Er worden steeds maar kleine stukjes pagina verstuurd. Dit belast de server minder omdat er minder gegevens moeten worden samengesteld om naar de browser te sturen. Ook wordt de verbinding minder belast doordat minder data wordt verzonden. Hierbij zijn zowel de webserver als de browser gebaat. Validaties op client via de server In een traditionele webtoepassing zijn er vaak veel JavaScript routines geschreven om input validatie in de browser te laten plaatsvinden. Controles van postcodes, Burger Service Nummers en dergelijke. Ze zijn in principe niet heel ingewikkeld, maar het vergt telkens nauwkeurig programmeerwerk. Uiteraard worden de validaties op de server vervolgens nog een keer gedaan. Dus behalve validaties in JavaScript moeten deze ook in PHP, Java, C# of welke taal dan ook worden geprogrammeerd. Twee keer hetzelfde programmeren van vervolg onderaan volgende pagina>> Informatiebeveiliging februari IB indd :09:31

6 (in)security 2.0? routines, die behoorlijke nauwkeurigheid vergen, in twee verschillende talen geeft extra mogelijkheden tot fouten. Maar door nu AJAX calls te gebruiken om de validatiemethoden op de server aan te spreken, hoeft de programmeur een validatie slechts één keer te programmeren. Via een generieke aanroep is dit eenvoudigweg te implementeren. Door op te geven welk invoerveld op welke pagina getest moet worden en daarbij de waarde mee te geven, kan vervolgens op de server de bijbehorende routine worden opgezocht en uitgevoerd. Daar wordt dan bijvoorbeeld getest of een waarde inderdaad een datum is en of die in een toegestaan bereik valt. Het resultaat dat terug wordt gegeven, is een booleaanse waarde (Ja/Nee) en eventueel een toelichting met wat er fout is met de waarde. Uiteraard zal het gehele formulier opnieuw gevalideerd moeten worden aan de serverzijde om fouten te voorkomen. Conclusie Web 2.0 en dan vooral AJAX biedt veel leuke dingen voor de eindgebruiker, maar door het onzichtbare karakter geeft het ook een minder veilig gevoel. De gebruiker ziet niet elke keer een compleet nieuwe pagina laden en daardoor gebeuren er tal van geheimzinnige zaken. In plaats van één webrequest zijn er meerdere op de achtergrond. Doordat in de Web 2.0 wereld gegevens vaak van allerlei bronnen afkomstig zijn, zijn deze per definitie niet te vertrouwen. De eigenaar van de site is vaak niet de eigenaar van de gegevens. Dus moet er controle op de gegevens plaatsvinden in de browser. Dit klinkt allemaal beangstigend en knap onveilig, maar als een ontwikkelaar voor elke mogelijke webrequest dezelfde veiligheidsregels hanteert als bij traditioneel webverkeer, dan verandert er eigenlijk weinig. Bovenden biedt AJAX de ontwikkelaar ook de mogelijkheid om beveiligingsproblemen eenvoudiger op te lossen. Client side validaties kunnen met AJAX ook voor een deel aan de serverkant worden uitgevoerd, daardoor hoeft een validatie slechts één keer geprogrammeerd te worden. Web 2.0 brengt de desktopapplicaties en nog veel meer naar de browser en doet de grens vervagen tussen desktop en internet. Een spannende tijd met heel veel mogelijkheden waarbij we altijd het oog op security moeten houden. Op naar Web 3.0! 18 Informatiebeveiliging februari 2009 IB indd :09:32