Browserbeveiliging in een web 2.0-omgeving

Browserbeveiliging in een web 2.0-omgeving
Omdat steeds meer toepassingen gebruikmaken van browsers en browsers een aantal kenmerken hebben die hen extra kwetsbaar maken, zijn ze een geliefd doelwit van allerlei aanvallen. Deze aanvallen worden vaak volledig geautomatiseerd uitgevoerd door goed georganiseerde criminele organisaties die zo snel geld hopen te verdienen. De auteur onderzoekt de architectuur van de moderne browser, bespreekt enkele veel uitgevoerde browseraanvallen en stelt beveiligingsmaatregelen voor.

Matthias Hutsebaut-Buysse
‘Verzegeld in een koffer voor gebruikt uranium op de bodem van de oceaan.’ Dit is een vaak gebruikte beschrijving van wat er nodig is om een computer voldoende te beveiligen (Wadlow & Gorelik, 2009). Deze computer zou wel voldoende beveiligd zijn tegen aanvallers van buitenaf, maar in het huidige internettijdperk zou deze computer vrijwel nutteloos zijn.
Met de opkomst van web 2.0 en cloud computing bieden steeds meer softwareontwikkelaars hun software enkel nog aan als een dienst via internet (Software as a Service). In juni 2011 heeft Microsoft Office 365 gelanceerd, de eerste versie van het Microsoft Office-pakket dat volledig werkt via de browser van de gebruiker. Internetgigant Google ging nog een stap verder: met Google Chrome OS biedt Google een besturingssysteem aan dat alleen maar uit een browser bestaat.
Aangezien steeds meer toepassingen gebruikmaken van browsers, zijn browsers een geliefd doelwit geworden van allerlei aanvallen. Aanvallers werden vroeger vooral gedreven door nieuwsgierigheid en eergevoel (Wadlow & Gorelik, 2009). Maar door het toegenomen gebruik van browsers worden browseraanvallen vaak volledig geautomatiseerd uitgevoerd door goed georganiseerde criminele organisaties die zo op illegale wijze snel geld hopen te verdienen.
Niet alleen het toegenomen gebruik van browsers heeft deze evolutie veroorzaakt. Moderne browsers bezitten namelijk ook een aantal kenmerken die hen van nature extra kwetsbaar maken. Deze kwetsbaarheden kunnen het beste aan het licht gebracht worden door allereerst de architectuur van de moderne browser te onderzoeken. Daarna worden enkele veel uitgevoerde browseraanvallen besproken. Per aanval worden tevens enkele beveiligingsmaatregelen voorgesteld.
Browserarchitectuur
Een browser is een computerprogramma dat code van een webserver haalt en vervolgens uitvoert op het systeem van de gebruiker. Het downloaden en uitvoeren van code brengt heel wat veiligheidsrisico’s met zich mee (De Paoli, Dos Santos & R.A. Kemmerer, 1997).
In de begindagen van het internet was deze gedownloade programmacode vaak beperkt tot statische HTML-code die geen toegang had tot de rest van het computersysteem. De gedownloade code had enkel invloed op de browseromgeving. Met de opkomst van web 2.0 werden webapplicaties steeds dynamischer. Om tegemoet te komen aan deze dynamiek bieden browsers steeds meer ondersteuning aan voor technologieën zoals Java(Script), Adobe Flash, en Microsoft Silverlight. Deze technologieën bieden vaak wel mogelijkheden aan webontwikkelaars om te communiceren met andere delen van het computersysteem buiten de browseromgeving. De meeste beveiligingsproblemen die optreden bij het gebruik van een browser zijn het gevolg van twee oorzaken (De Paoli, Dos Santos & R.A. Kemmerer, 1997):
• De browsercode bevat fouten (bugs) of is slecht uitgevoerd. Moderne browsers bevatten ongeveer allemaal gelijkaardige functies, maar er is zeer weinig standaardisatie en consensus als het gaat over implementatie (Zalewski, 2009).
• De omgeving (systeemconfiguratie) waarin de browser werkt is onvoldoende beveiligd.
Dit artikel gaat vooral over het beveiligen van de browseromgeving. De gebruiker kan doorgaans weinig invloed uitoefenen op de browsercode. Om aanpassingen te kunnen doorvoeren in de broncode moet hij vertrouwen op de leverancier van de browser of de open-source community wanneer de code van de browsersoftware vrijgegeven is.
De leverancier zal wanneer een veiligheidslek vastgesteld wordt, vaak een nieuwe versie uitbrengen. De gebruiker kan om optimaal beveiligd te zijn dus het best gebruikmaken van de nieuwste versie van de browsersoftware. Dit updateproces is vaak geautomatiseerd in de browsersoftware en is daardoor zeer eenvoudig uit te voeren. Uit een studie uitgevoerd in 2008 bleek echter dat een groot aantal browsergebruikers toch nog met een oudere browserversie werkte (Frei, Duebendorfer & Plattner, 2008). Deze oudere browsers bevatten vaak veiligheidslekken die bekend zijn en dus eenvoudig kunnen worden misbruikt.
Vergelijking van leveranciers
Het is helaas erg moeilijk om op eenvoudige wijze browsers te vergelijken wat veiligheid betreft. Elke browser beschikt namelijk over andere functionaliteiten. Ook het type gebruiker (en bijgevolg aanvaller) is verschillend. Zo zijn er bronnen die meer kwetsbaarheden vaststellen in Microsoft Internet Explorer. Dit wil echter niet zeggen dat andere browsers minder kwetsbaarheden bezitten. Door het grote marktaandeel is Internet Explorer een geliefd doelwit en zal deze browser daarom waarschijnlijk ook meer onder vuur genomen worden dan een browser met een beperkter marktaandeel (en dus minder potentiele slachtoffers).
Veel voorkomende browseraanvallen
In wat volgt worden enkele veel uitgevoerde aanvallen besproken en per aanval worden voorstellen gedaan om de browser te beveiligen.
Cookieaanvallen
Cookies zijn kleine stukken data die maximaal uit 255 tekens bestaan en meestal worden opgeslagen als tekstbestand. Een website kan zonder tussenkomst van de gebruiker deze cookies aanmaken op het systeem van de gebruiker. De data opgeslagen in deze cookies worden iedere keer meegestuurd wanneer de gebruiker de website opnieuw bezoekt (Perkins, 2000).
Cookies zijn niet meer weg te denken uit moderne browsers. Zonder cookies zouden bij het sluiten van de browser alle gegevens die de gebruiker aan de website toevertrouwde, verloren gaan (stateless connection). Bij een volgende sessie zou de gebruiker telkens weer opnieuw zijn voorkeuren en gegevens moeten opgeven. ( figuur 1 )
 
Figuur 1. Voorbeeldcode van cookieaanval (Vigna, 2009)
 
Privacyrisico
Door het aanmaken van een cookie kan een website eenvoudig haar bezoekers identificeren en allerlei gegevens bijhouden over deze bezoeker. Het gebruik van cookies is de meest gebruikte methode om browsers te volgen (Krishnamurthy & Wills, 2006). Zo houdt de webshop Amazon.com bij welke zoekopdrachten zijn gebruikers uitvoeren. Door deze zoekopdrachten bij te houden kan Amazon.com gepersonaliseerde aanbiedingen weergeven. Zonder cookies zou Amazon.com slechts in staat zijn de zoekopdrachten van één sessie bij te houden.
Eenzelfde techniek wordt vaak toegepast door online adverteerders. Een online advertentie wordt vaak weergegeven op meerdere webpagina’s; door een cookie in te stellen kan de adverteerder te weten komen welke webpagina’s de gebruiker bezoekt. Deze gegevens kunnen ook weer opnieuw gebruikt worden om gerichte advertenties weer te geven.
Door www.google.com/ads/preferences te bezoeken kan een gebruiker te weten komen welke gegevens Google over hem bijhoudt (zie figuur 2). Deze resultaten geven een verrassend goed beeld van interesses en recente zoekopdrachten.
 
Figuur 2. Google-advertentiecategorieën op basis van bezochte webpagina’s
 
Cookie hijacking
Cookies worden ook vaak gebruikt voor authenticatie. Wanneer een website de mogelijkheid biedt om ingelogd te blijven, gebeurt dit meestal aan de hand van een cookie. Aan de hand van de data die in het cookie opgeslagen zijn, kan een website een gebruiker automatisch opnieuw inloggen zonder dat deze gebruiker een gebruikersnaam en wachtwoord moet opgeven.
Deze manier van werken zorgt er helaas ook voor dat iedereen die toegang heeft tot het bestandssysteem, de inhoud van een cookie kan kopiëren en zichzelf kan authenticeren als de gebruiker.
Beveiligingsmaatregelen
• Om te voorkomen dat adverteerders cookies aanmaken bieden heel wat browsers de mogelijkheid om alleen cookies toe te staan die afkomstig zijn van de webpagina’s die de gebruiker bezoekt en alle ‘vreemde’ cookies te blokkeren.
• Sommige browsers bieden ook de mogelijkheid om de gebruiker eerst te verwittigen alvorens een webapplicatie een cookie aanmaakt. Het volledig uitschakelen van cookies is vaak ook mogelijk, maar dit kan ervoor zorgen dat heel wat webapplicaties niet meer correct kunnen functioneren.
• Cookies kunnen ook het beste geëncrypteerd opgeslagen worden zodat alleen de browser deze kan uitlezen.
Browser fingerprinting
Privacyrisico
Cookies zijn echter niet het enige privacyrisico dat browsers met zich meebrengen. Harvardonderzoekster Latanya Sweeney heeft aangetoond dat 87 procent van de bevolking van de Verenigde Staten kan worden geïdentificeerd met enkel en alleen een combinatie van postcode, geslacht en geboortedatum.
Moderne browsers sturen heel wat informatie over zichzelf en de gebruiker mee om web 2.0-applicaties te laten functioneren. Uit een studie naar 470.161 browsers bleek dat 83,6 procent van alle onderzochte browsers een unieke configuratie bezat. Browsers die Adobe Flash of Java Virtual Machine geïnstalleerd hadden, konden zelfs voor 94,2 procent uniek verklaard worden.
De volgende lijst bevat de browsereigenschappen die door elke webpagina eenvoudig opvraagbaar zijn; door deze eigenschappen te combineren kunnen gebruikers geïdentificeerd worden:
• de user agent bevat onder andere de gedetailleerde browserversie, de versie van het besturingssysteem en de taal van de gebruiker;
• browserplug-ins die geïnstalleerd zijn;
• tijdzone van de gebruiker;
• schermresolutie;
• lettertypen die de webapplicatie kan gebruiken;
• of cookies toegestaan zijn of niet.
Een aanvaller kan ook misbruik maken van de verstrekte versie-informatie. Wanneer een aanvaller te weten komt dat de gebruiker een browser of een browserplug-in heeft die bekende kwetsbaarheden bevat, kan de aanvaller deze kwetsbaarheden mogelijk verder uitbuiten.
Beveiligingsmaatregelen
• Fingerprinting werkt enkel op korte termijn. De gebruiker zal de browser constant aanpassen aan zijn voorkeuren.
• Sommige maatregelen, zoals het niet toestaan van Adobe Flash of het veranderen van de user agent, lijken op het eerste gezicht aan te raden, maar door deze aanpassingen door te voeren maakt men de browser vaak unieker.
• Het gebruik van een niet-zeldzame browser zonder plug-ins op het Microsoft Windows-besturingssysteem is de meest eenvoudige manier om fingerprinting te voorkomen.
• Door het uitschakelen van JavaScript kan het onmogelijk gemaakt worden voor webpagina’s om de geïnstalleerde plug-ins en lettertypen op te vragen. Plug-ins zoals NoScript bieden een tussenoplossing door enkel JavaScript toe te staan voor sommige als betrouwbaar gemarkeerde webapplicaties.
Cross-site scripting (XSS)
Een cross-site scripting (XSS)-aanval maakt gebruik van een onschuldige webapplicatie als tussenplatform (Braganza, 2006). Bij een XSS-aanval infecteert de aanvaller een niet-betrokken webapplicatie met geïnfecteerde code. Wanneer een nietsvermoedende gebruiker de webapplicatie opent, wordt niet alleen de code van de webapplicatieontwikkelaar uitgevoerd, maar ook de code van de aanvaller.
XSS-aanvallen zijn vaak het gevolg van slecht ontworpen invoermethoden van webapplicaties. Een webapplicatie kan namelijk slechts geïnfecteerd worden wanneer de invoer van gebruikers niet gecontroleerd wordt op het bevatten van code. Zo zou een kwaadwillende gebruiker bijvoorbeeld in plaats van een vriendelijke tekst in het gastenboek van een website te schrijven, dit gastenboek kunnen infecteren door de tekst aan te vullen met code. Gebruikers die het gastenboek lezen krijgen de tekst te zien, maar als de website onvoldoende beveiligd is, wordt de geïnfecteerde code ook mee uitgevoerd. ( figuur 3 )
Figuur 3. Google heeft maatregelen genomen om reflected XSS-aanvallen te voorkomen. Zo wordt de geïnjecteerde JavaScript-code niet uitgevoerd maar enkel als tekst weergegeven
 
Integriteitsrisico
Indien een aanvaller erin slaagt om succesvol code te implementeren in de code van een webapplicatie, kan deze geïnfecteerde code de gedownloade webpagina volledig veranderen en overnemen. Er zijn drie soorten XSS-aanvallen (Vigna, 2009):
• Stored: de geïnfecteerde code wordt opgeslagen in een database.
• Document Object Model (DOM): de geïnfecteerde code wordt ingebracht langs de URL, wanneer de webapplicatie een URL-parameter opvraagt wordt de code geïnjecteerd.
• Reflected: dit soort aanval maakt gebruik van webapplicaties die invoer herhalen (reflecteren). Een dergelijke aanval kan bijvoorbeeld voorkomen wanneer de zoekquery die geïnjecteerde code bevat wordt afgedrukt op het scherm.
Een aanvaller kan het vertrouwen dat de gebruiker in de webapplicatie heeft op een aantal manieren misbruiken:
• Als een aanvaller tekst vervormt, kan de gebruiker de indruk krijgen dat hij iets anders aan het doen is dan wat er eigenlijk echt gebeurt. Zo zou een aanvaller bij een overschrijving het correcte bankrekeningnummer kunnen weergeven op het scherm terwijl in werkelijkheid de gebruiker een overschrijving aan het uitvoeren is naar een ander rekeningnummer (van de aanvaller).
• XSS-aanvallen kunnen er ook voor zorgen dat de gebruiker om extra gegevens wordt gevraagd door middel van een pop-upvenster. De gebruiker kan veronderstellen dat dit extra venster deel uitmaakt van de webapplicatie die hij aan het gebruiken is.
• Het is ook mogelijk gegevens van de gebruiker op te vragen en door te sturen naar de aanvaller. Deze gegevens kunnen onder andere de cookies van een gebruiker zijn. Op deze manier kan een aanvaller de sessie van de gebruiker overnemen (Braganza, 2006). • De geïnfecteerde code kan er ook simpelweg voor zorgen dat de browser crasht (Vigna, 2009). Dit soort aanval is een Denial of Service (DoS)aanval.
• Een XSS-aanval kan ook een toegangspoort bevatten tot het lokale netwerk. Een aanvaller kan proberen via de gebruiker lokale (intranet) pagina’s op te vragen en door te sturen. Ook kan een aanvaller op deze manier controle krijgen over netwerkapparaten zoals routers, printers en telefooncentrales die niet rechtstreeks met internet verbonden zijn en waarvoor geen of beperkte identiteitscontrole is opgelegd (Kamkar, 2010).
Beveiligingsmaatregelen
Cross-site scripting-aanvallen zijn eenvoudig uit te voeren maar zeer moeilijk te detecteren en te voorkomen (Vigna, 2009). Het is moeilijk voor webapplicatieontwikkelaars om code-injecties te weren. Dit is het gevolg van een zeer flexibele HTML-encodering. Voor de browser is het heel moeilijk uit te maken of het gaat om een correcte functionaliteit of een aanval.
• De eenvoudigste manier om cross-site scripting tegen te gaan is door webapplicaties zodanig te implementeren dat het onmogelijk wordt om code te injecteren. Helaas heeft de browser en dus de gebruiker hier geen controle over.
• Om cross-site scripting tegen te gaan implementeren browsers vaak een ‘same-origin policy’. Deze maatregel staat uitgevoerde code niet toe om te communiceren met andere code buiten de webapplicatie. Deze maatregel maakt het moeilijker voor een webapplicatie om gegevens van een andere webapplicatie te stelen. Door gebruik te maken van een same-origin policy kunnen browsers garanderen dat JavaScript-code en cookies van verschillende webapplicaties veilig naast elkaar kunnen bestaan (Balduzzi et al., 2010).
• Helaas kan wanneer een same-origin policy gebruikt wordt, geïnjecteerde code nog steeds informatie doorsturen naar de aanvaller. Het blijft ook nog steeds mogelijk om aanpassingen door te voeren die betrekking hebben op de webapplicatie die de gebruiker opent. De enige manier om dit probleem volledig op te lossen is door JavaScript uit te schakelen.
Clickjacking
Bij een clickjackingaanval probeert de aanvaller de gebruiker te laten klikken op een element van een voor de gebruiker onzichtbare webpagina. De aanvaller doet dit door boven op de webpagina met het element een laag te plaatsen met een ander aantrekkelijk element (Balduzzi et al., 2010). Door op dit element te klikken voert de gebruiker een ongewenste actie uit in het voordeel van de aanvaller. Vanuit het standpunt van de onderliggende website lijkt de actie van de gebruiker legitiem. In figuur 4 is een voorbeeld te zien van een clickjackingaanval waarbij de gebruiker een knop ‘PLAY!’ ziet in het browservenster. Wat de gebruiker echter niet ziet is dat onder deze pagina een Twitter-pagina geladen wordt waarop op dezelfde positie als de ‘PLAY!’-knop een knop staat die de Twitter-account verwijdert.
Clickjacking wordt ook vaak gebruikt om gebruikers op advertenties te laten klikken. Voor deze klik ontvangt de aanvaller dan een vergoeding van een adverteerder.
 
Figuur 4. Voorbeeld van clickjackingaanval (bron: Rydstedt et al., 2010)
 
Beveiligingsmaatregelen
• Clickjacking kan vrij eenvoudig opgelost worden door webontwikkelaars. Webapplicaties kunnen namelijk detecteren wanneer ze door een andere webpagina worden geladen. Wanneer een webapplicatie detecteert dat ze geladen wordt door een andere webpagina, kan ze ervoor kiezen om uit de webpagina te springen.
• Helaas zijn er geen eenvoudige beveiligingsmaatregelen die browsergebruikers kunnen invoeren. Voor Mozilla Firefox bestaat een plugin NoScript die voorkomt dat de gebruiker op onzichtbare elementen kan klikken.
Drive-by-download
Code die wordt gedownload en uitgevoerd in een browseromgeving heeft weinig toegangsrechten buiten de browseromgeving. Als een aanvaller meer controle wil krijgen over het systeem, moet deze vaak nog extra code installeren op het systeem buiten de browseromgeving.
Een drive-by-download is een aanval gericht op het verspreiden van malware via de browser (Cova, Kruegel & Vigna, 2010). Bij een aanval wordt geïnfecteerde software gedownload zodra de gebruiker een geïnfecteerde webpagina bezoekt.
Beveiligingsmaatregelen
Ook voor drive-by-downloadaanvallen geldt dat deze zeer moeilijk te detecteren zijn omdat de browser de bedoeling van de gebruiker maar zeer moeilijk kan inschatten. Browsers lossen dit probleem op door hun gebruiker een bevestiging te vragen wanneer gedownloade software zichzelf probeert te openen.
Spoofing en phishing
Spoofing is een techniek waarbij aanvallers zich als een andere partij voordoen om zo nietsvermoedende gebruikers te misleiden. Zo kunnen aanvallers gebruikers naar een valse website leiden die er vrijwel hetzelfde uitziet als de echte site. Gebruikers worden vaak naar valse websites gelokt door valse links en misleidende URL’s. ( figuur 5 )
• Valse links: de verdachte webapplicatie bevat een tekst ‘link naar website A’ terwijl dit eigenlijk een link is naar website B.
• Misleidende URL’s: de aanvaller heeft een internetdomein geregistreerd dat sterk lijkt op dat van de ‘gespoofde’ website. Zo lijken ‘bank.be’, ‘ba. nk.be’ en ‘mybank.be’ sterk op elkaar. Aanvallers registreren vaak domeinen die sterk op dat van de originele website lijken. Wanneer de aanvaller ook de lay-out van de originele website overneemt, kan een gebruiker die het valse domein bezoekt denken dat hij met de echte webapplicatie te maken heeft.
• Ook kunnen aanvallers de gebruiker misleiden door een IP-adres te gebruiken in plaats van een domeinnaam.
 
Figuur 5. BNP Paribas Fortis geeft op haar website een overzicht van een aantal elementen waaruit gebruikers kunnen afleiden dat ze met een gespoofde versie van de webapplicatie te maken hebben
 
Wanneer een aanvaller deze misleiding gebruikt om vertrouwelijke informatie van de gebruiker te achterhalen, gaat het om een vorm van phishing (Laudon & Laudon, 2010).
In 2007 schatten Moore en Clayton dat ongeveer 311.449 browsergebruikers jaarlijks het slachtoffer worden van phishingaanvallen. Gartner schatte in 2006 dat de gemiddelde kosten voor een slachtoffer ongeveer 1.244 dollar bedroegen.
Spoofing is geen aanval die eigen is aan browsergebruik, spoofingaanvallen worden namelijk ook veel uitgevoerd door gebruik te maken van e-mail. Aangezien deze vorm van spoofing erg arbeidsintensief is zijn aanvallers vaak overgegaan op veel geautomatiseerdere aanvallen die gebruikmaken van webformulieren die uitgevoerd worden in een browseromgeving.
Gelukkig beschikken hedendaagse browsers over een aantal mechanismen van serverauthenticatie die het mogelijk maken om webapplicaties te valideren.
 
TSL en SSL
Secure Socket Layer (SSL) en zijn opvolger Transport Layer Security (TLS) zijn technologieën in de transportlaag die het mogelijk maken om gevoelige data zoals creditcardnummers te beschermen wanneer deze verzonden worden (Herzberg & Jbara, 2006).
Secure Hypertext Transfer Protocol (SHTTP) is een protocol specifiek ontwikkeld voor het versleutelen van gegevens van webapplicaties. HTTPS maakt hiervoor gebruik van SSL en TLS (Laudon & Laudon, 2010). Deze extra laag kost extra rekenkracht, daarom wordt SHTTP niet standaard gebruikt, maar meestal enkel voor transacties waar confidentialiteit erg gewenst is.
Behalve om de confidentialiteit van verzonden en ontvangen gegevens te garanderen kunnen deze protocollen ook nog gebruikt worden om spoofing tegen te gaan. SSL bevat namelijk een handshakefunctie. In deze functie wordt getracht de identiteit van de webapplicatie te valideren.
Wanneer een gebruiker een webpagina van een door SSL beveiligde webapplicatie opvraagt, wordt er een certificaat meegestuurd (figuur 6) dat door de browser nagekeken wordt op drie verschillende punten:
1. Is het certificaat uitgereikt door een betrouw-bare certificate authority?
2. Is het certificaat nog geldig?
3. Mag de webapplicatie dit certificaat wel gebruiken?
 
Figuur 6. Browserweergave van het certificaat gebruiktdoor blackboard.ua.ac.be
 
Elk certificaat is gelinkt aan een bepaald bedrijf en webapplicatie. Door een betrouwbare certificate authority in te schakelen kan de gebruiker er vrij zeker van zijn dat de identiteit die in het certificaat opgeslagen zit voldoende gevalideerd is. Bovendien bevat elk certificaat een aantal geëncrypteerde gegevens van de server. Op deze manier kan een certificaat alleen gebruikt worden door de servers die de gevalideerde organisatie heeft doorgegeven aan de certificate authority.
Beveiligingsmaatregelen
Hedendaagse browsers bevatten een aantal functies om spoofing tegen te gaan. Zo geven de meeste browsers enkele duidelijke indicaties dat de identiteit van de webapplicatie gevalideerd is (zie figuur 7):
 
Figuur 7. SSL-indicatoren (Safari)

• De ‘https://’ aan het begin van de URL toont aan dat er SSL gebruikt wordt. Ook het slot in de rechterbovenhoek toont dit aan.
• Naast de URL staat ook de bedrijfsnaam van de gevalideerde organisatie. Wanneer deze niet aanwezig is of afwijkt van de inhoud van de webapplicatie, kan het mogelijk om een valse website gaan.
• Helaas is uit een studie gebleken dat deze passieve symbolen niet veel uithalen – omdat gebruikers ze vaak niet opmerken of gewoon niet weten wat ze betekenen (Egelman, Cranor & Hong, 2008). Een efficiëntere manier om spoofing tegen te gaan is door gebruik te maken van actieve waarschuwingen zoals in figuur 8. In dit geval moet de gebruiker expliciet zijn toestemming geven aan de browser om de webapplicatie uit te voeren wanneer de browser vermoedt dat het om een vervalste webapplicatie gaat.
 
Extensies
Web 2.0 is een platform dat altijd in beweging is. Het is voor browserontwikkelaars dan ook zeer moeilijk om steeds de nieuwste functionaliteiten aan te bieden. Om deze leegte op te vullen staan browsers vaak het gebruik van extensies toe.
Extensies zijn kleine stukjes software die in de browser kunnen worden ingeplugd. De extensies kunnen dan nieuwe functionaliteit toevoegen aan de browseromgeving. Bovendien maken extensies het ook mogelijk dat de browser technologieën ondersteunt die ontwikkeld zijn door een andere ontwikkelaar dan de browserleverancier.
Helaas besteden deze derde partijen vaak minder aandacht aan de beveiliging van hun extensies. Omdat extensies zorgen voor extra functionaliteit, krijgen ze vaak ook veel toegangsrechten tot het browserplatform (Bandhakavi, 2011). Wanneer een aanvaller een kwetsbaarheid kan vaststellen in een extensie, kan de aanvaller deze kwetsbaarheid gebruiken om de browser over te nemen en bijvoorbeeld de cookiebestanden te kopiëren.
Maar extensies kunnen zelf ook malware bevatten. Zo kunnen extensies vaak ook gebruikt worden voor spoofingaanvallen, clickjacking of cross-site scripting-aanvallen. Bij dergelijke aanvallen wordt er geen gebruik meer gemaakt van een extra webapplicatie als tussenplatform, maar bevat de browser rechtstreeks de code van de aanvaller.
Beveiligingsmaatregelen
Ook hier is het vaak onmogelijk voor een browser om uit te maken of het om een aanval gaat of om extra functionaliteit. Er kan bijvoorbeeld een extensie worden ontwikkeld die alle webapplicaties weergeeft in een zwartwitweergave. Het is voor de browser onduidelijk of de gebruiker om deze functionaliteit verzocht heeft of dat het hier om malware gaat. Om dit tegen te gaan bieden browserleveranciers vaak een platform aan waar browserplug-ins kunnen worden beoordeeld door de gebruikersgemeenschap.
Figuur 8. Een actieve phishingwaarschuwing
 
Conclusie
Door de populariteit en de architectuur zijn browsers een ideaal doelwit voor allerlei aanvallen. Helaas zijn de technieken die oorspronkelijk bedoeld waren om internet extra interactiviteit te verschaffen ook vaak zeer kwetsbaar. Dit maakt het beveiligen van een browser erg moeilijk. Het is namelijk niet eenvoudig om onderscheid te maken tussen nuttige functionaliteit en een aanval. Om een browser goed te kunnen beveiligen zou een inschatting moeten worden gemaakt van de bedoelingen van de gebruiker. Inschatten van de wens van de gebruiker is een taak die zeer moeilijk kan worden geautomatiseerd. Daarom is het aan te raden om browsergebruikers een korte training te geven zodat ze zich bewust worden van mogelijke aanvallen en daardoor zelf kunnen inschatten wanneer ze in een potentiële gevarenzone terechtkomen.
Het beveiligen van een browser komt vaak neer op het kiezen van een ontwikkelaar die voldoende veiligheidsmaatregelen heeft ingebouwd in zijn browsersysteem. Het uitschakelen van bepaalde functies zoals cookies en JavaScript maakt een aantal aanvallen onmogelijk, maar zorgt er ook vaak voor dat webapplicaties niet meer correct functioneren. Men moet vaak een keuze maken tussen veiligheid en gebruiksgemak.
Literatuur
Balduzzi, M. et al. (2010). A solution for the automated detection of clickjacking attacks. Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security .
Bandhakavi, S. et al. (2011). Vetting browser extensions for security vulnerabilities with vex. Commun. ACM 54, pp.
91-99.
Braganza, R. (2006). Cross-site scripting – an alternative view.
Network Security 2006(9), pp. 17-20.
Cova, M., C. Kruegel & G. Vigna (2010). Detection and analysis of drive-by-download attacks and malicious JavaScript code. Proceedings of the 19th International Conference on World Wide Web .
De Paoli, A., L. Dos Santos & R.A. Kemmerer (1997).
Vulnerability of ‘secure’web browsers.
Egelman, S., L.F. Cranor & J. Hong (2008). You’ve been warned: an empirical study of the effectiveness of web browser phishing warnings. Proceeding of the Twenty-sixth Annual SIGCHI Conference on Human Factors in Computing Systems, CHI ’08, pp. 1065-1074, New York, NY, ACM.
Frei, S., T. Duebendorfer & B. Plattner (2008). Firefox (in) security update dynamics exposed. SIGCOMM Comput. Commun. Rev . 39. pp. 16-22.
Gartner (2006). Gartner says number of phishing e-mails sent to U.S. adults nearly doubles in just two years. Persbericht, 9 november 2006, http://www.gartner.com/it/page. jsp?id=498245.
Herzberg, A. & A. Jbara (2006). Security and identification indicators for browsers against spoofing and phishing attacks. Kamkar, S. (2010). How I met your girlfriend. Defcon 18 Hacking Conference.
Krishnamurthy, B. & C. Wills (2006). Generating a privacy footprint on the internet. ACM SIGCOMM Internet Measurement Conference . Laudon, K.C. & J.P. Laudon (2010). Bedrijfsinformatiesystemen .
Pearson.
Moore, T. & R. Clayton (2007). An empirical analysis of the current state of phishing attack and defence.
Perkins, S. (2000). Internet cookies: Security implications,
http://citeseer.ist.psu.edu/perkins00internet.html.
Rydstedt, G. et al., (2010). Busting frame busting: a study of clickjacking vulnerabilities at popular sites.
Vigna, G. (2009). Client-side cross-site scripting protection. Computers & Security 28(7), pp. 592-604.
Wadlow, T. & V. Gorelik (2009). Security in the browser.
Commun. ACM 52, pp. 40-45. Zalewski, M. (2009). Browser Security Handbook . Google, http://code.google.com/p/ browsersec/wiki/Main.
Matthias Hutsebaut-Buysse is handelsingenieur in de beleidsinformatica.
Dit artikel is gebaseerd op zijn scriptie voor de masteropleiding Security Management aan de Universiteit van Antwerpen.
 

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