Whitepaper Raamwerk Beveiliging Webapplicaties

Whitepaper Raamwerk Beveiliging Webapplicaties Auteur GOVCERT.NL Versie Versie 2.0 Status Definitief Den Haag, 4 mei 2010. Publieke uitgave 4 november 2010

GOVCERT.NL is het Computer Emergency Response Team van en voor de Nederlandse overheid. Zij ondersteunt overheidsorganisaties in het Voorkomen en afhandelen van ICT-gerelateerde veiligheidsincidenten, 24 uur per dag, 7 dagen per week. Advies en preventie, waarschuwing, incidentafhandeling en kennisdeling zijn hierbij sleutelwoorden. Logius (voorheen GBO.Overheid) is de dienst digitale overheid van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties waar GOVCERT.NL sinds 1 januari 2006 deel van uit maakt. Zij is verantwoordelijk voor beheer en verdere ontwikkeling van een aantal overheidsbrede ICT-voorzieningen. Gebruik: Dit werk is gepubliceerd onder de voorwaarden beschreven in de Creative Commons Naamsvermelding-Niet-commercieel-Gelijk delen 3.0 Nederland licentie. Kijk voor meer informatie op http://creativecommons.org/licenses/by-nc-sa/3.0/nl/

Inhoud 1. INLEIDING...9 1.1. LEESWIJZER... 10 2. RAAMWERK BEVEILIGING WEBAPPLICATIES... 12 2.1. WEBAPPLICATIES... 12 2.2. HET HTTP-PROTOCOL... 14 2.3. MOGELIJKE KWETSBAARHEDEN EN BEDREIGINGEN... 17 2.4. HET RAAMWERK... 19 2.5. DOELEN... 21 2.6. REIKWIJDTE... 21 2.7. INCIDENTEN BINNEN HET.NL-DOMEIN... 22 2.8. ALGEMENE AANBEVELINGEN... 25 3. NETWERKBEVEILIGING... 28 3.1. INLEIDING... 28 3.2. MOGELIJKE KWETSBAARHEDEN EN DREIGINGEN... 29 3.3. AANBEVELINGEN... 33 4. PLATFORMBEVEILIGING... 47 4.1. INLEIDING... 47 4.2. MOGELIJKE KWETSBAARHEDEN EN DREIGINGEN... 47 4.3. AANBEVELINGEN... 51 5. APPLICATIEBEVEILIGING - KWETSBAARHEDEN... 61 5.1. INLEIDING... 61 5.2. KWETSBAARHEDEN... 62 5.3. OORZAKEN... 86 6. APPLICATIEBEVEILIGING - MAATREGELEN... 91 6.1. INLEIDING... 91 6.2. MAATREGELEN OP HET GEBIED VAN SOFTWARE-ONTWIKKELING... 92 6.3. CONFIGURATIEMAATREGELEN... 102 6.4. PROCEDURELE MAATREGELEN... 108 6.5. OVERIGE AANDACHTSPUNTEN... 110 7. APPLICATIEBEVEILIGING WEB APPLICATION FIREWALLS... 112 7.1. INLEIDING... 112 7.2. TECHNIEK... 112 7.3. FUNCTIONALITEITEN... 116 7.4. EEN WAF IN DE INFRASTRUCTUUR... 122 1

7.5. VOORBEELDEN VAN WAF OPLOSSINGEN... 123 7.6. AANDACHTSPUNTEN... 124 8. IDENTITEIT- EN TOEGANGSBEHEER... 127 8.1. INLEIDING... 127 8.2. MOGELIJKE KWETSBAARHEDEN EN BEDREIGINGEN... 129 8.3. AANBEVELINGEN... 137 9. VERTROUWELIJKHEID EN ONWEERLEGBAARHEID... 144 9.1. INLEIDING... 144 9.2. MOGELIJKE KWETSBAARHEDEN EN BEDREIGINGEN... 144 9.3. AANBEVELINGEN... 146 10. BEVEILIGINGSINTEGRATIE... 154 10.1. INLEIDING... 154 10.2. MECHANISMEN... 155 10.3. AANBEVELINGEN... 158 11. MONITORING, AUDITING EN ALERTING... 159 11.1. MOGELIJKE KWETSBAARHEDEN EN BEDREIGINGEN... 160 11.2. AANBEVELINGEN... 161 A. BEVEILIGINGSADVIES GOVCERT.NL-2006-133... 171 B. AFKORTINGEN... 174 C. HOOFDPUNTEN BEVEILIGING... 177 D. REFERENTIES... 184 2

Samenvatting Het beveiligen van webapplicaties is meer dan het versleutelen van verkeer of het gebruik van firewalls. Een webapplicatie is pas optimaal beveiligd wanneer organisaties op meerdere niveaus maatregelen treffen tegen misbruik ervan. Dit Raamwerk Beveiliging Webapplicaties, kortweg RBW, beschrijft alle lagen waaraan ontwikkelaars, beheerders en architecten bij het beveiligen van een webapplicatie aandacht moeten schenken. Deze lagen, die in deze whitepaper achtereenvolgens worden behandeld, zijn: netwerkbeveiliging, platformbeveiliging, applicatiebeveiliging, identiteit- en toegangsbeheer, vertrouwelijkheid en onweerlegbaarheid, beveiligingsintegratie en monitoring. Deze samenvatting gaat kort in op deze onderwerpen. Netwerkbeveiliging - Bij netwerkbeveiliging ligt de focus op het beveiligen van de infrastructuur via firewalls, routers en switches. Belangrijk is een solide DMZ-ontwerp en architectuur waarbij de organisatie aandacht besteedt aan zaken als compartimentering (waarbij de DMZ wordt opgedeeld in compartimenten met daarin diensten met gelijke functionaliteit en beveiligingsniveau), verplichte routepaden door de DMZ en scheiding van regulier verkeer en beheerverkeer. Om te voorkomen dat kwaadwillenden een webapplicatie via de infrastructuur aanvallen, moeten organisaties voldoende maatregelen treffen tegen Distributed Denial-of-Service aanvallen en moeten zij tevens hardening op infrastructuurniveau doorvoeren. Denk hierbij aan het uitschakelen van onnodige services en het gebruik van veilige protocollen bij het uitvoeren van beheerwerkzaamheden. Platformbeveiliging Platformbeveiliging richt zich op het beveiligen van de besturingssystemen waarop webservers, databaseservers, etcetera draaien. Om te voorkomen dat kwaadwillenden misbruik maken van bekende en nieuwe kwetsbaarheden is het belangrijk een solide updatemechanisme te implementeren. Naast een technische inrichting,moet een organisatie ook aandacht besteden aan procedures hiervoor. Het inperken van rechten op het systeem, het hardenen van essentiële systeemonderdelen zoals de TCP- en IPstacks en het gebruik van beveiligingstemplates, verlagen de kans dat kwaadwillenden misbruik van de server maken. Door auditing op OS-niveau in te richten, zorgen organisaties ervoor dat eventueel misbruik toch gedetecteerd kan worden. 3

Applicatiebeveiliging De nadruk in deze whitepaper ligt voor een groot deel op applicatiebeveiliging. Veel problemen met webapplicaties vinden hun oorsprong in fouten die ontwikkelaars maken bij het ontwikkelen van een webapplicatie. Denk hierbij aan kwetsbaarheden als Cross-Site-Scripting (XSS), SQL-injectie en commandinjectie. Veel van deze problemen ontstaan doordat ontwikkelaars in- en uitvoer onvoldoende valideren. Het valideren van alle mogelijke invoer, het coderen van gevaarlijke karakters in de uitvoer en het gebruik van geparameteriseerde queries voor communicatie met de database, kunnen deze kwetsbaarheden helpen voorkomen. Andere belangrijke zaken zijn het gebruik van accounts met beperkte rechten voor het verbinden met databases en andere systemen en het opleiden van ontwikkelaars in het veilig programmeren van webapplicaties. Een Web Application Firewall (WAF) is een applicatie die de beveiliging van een webapplicatie kan verhogen. Een WAF fungeert als reverse proxy of als plug-in op de webserver en is gespecialiseerd in het uitvoeren van invoervalidatie, protocolvalidatie, uitvoervalidatie en het normaliseren en loggen van alle webverzoeken. Hoewel een WAF een waardevolle toevoeging voor de beveiliging van een webomgeving kan zijn, staat het zeker niet los van andere beveiligingsmaatregelen op applicatieniveau. Identiteit- en toegangsbeheer Op het gebied van identiteit- en toegangsbeheer blijken veel webapplicaties problemen te hebben met het implementeren van een veilig mechanisme voor sessiemanagement. De vraag is of elke webapplicatie het wiel op dit gebied telkens opnieuw moet uitvinden of dat je hiervoor een gespecialiseerde Identity & Access Management (I&AM)-component kan inzetten. Belangrijk is in ieder geval om de inzet van gespecialiseerde tooling te overwegen en om vervolgens te bepalen welke authenticatie- en autorisatiefuncties op welke plek in de webomgeving worden uitgevoerd. Tot slot is het niet alleen van belang om te kijken naar de inlogfunctionaliteit, maar ook naar de mogelijkheid om de sessie te beëindigen (uitloggen). 4

Vertrouwelijkheid en onweerlegbaarheid In de laag Vertrouwelijkheid en onweerlegbaarheid ligt de focus op het beschermen van data en het bewijzen dat bepaalde transacties daadwerkelijk hebben plaatsgevonden. Om data voldoende te beschermen is het van belang versleuteling op transportniveau toe te passen door het gebruik van SSL of TLS. Versleuteling op transportniveau is echter niet voldoende. Zo moet gevoelige informatie ook versleuteld worden opgeslagen in databases om te voorkomen dat kwaadwillenden via aanvallen als SQL-injectie alsnog inzicht krijgen in deze informatie. Tot slot is het advies om gebruik te maken van digitale handtekeningen om de onweerlegbaarheid van transacties te kunnen bereiken. Beveiligingsintegratie Binnen de diverse lagen van het RBW zijn verschillende mechanismen ingericht voor het beveiligen van de webapplicatie. Om samenwerking tussen deze tools te kunnen bewerkstelligen, is het belangrijk aandacht te besteden aan de samenhang tussen deze tools. Deze samenwerking maakt onderdeel uit van de laag Beveiligingsintegratie. Bij elke beveiligingscomponent uit het RBW is het dan ook van belang te bekijken welke diensten deze component van andere componenten moet kunnen afnemen en welke diensten de component moet kunnen aanbieden aan andere componenten. Monitoring, auditing en alerting Monitoring, auditing en alerting zijn van toepassing op elke laag van het RBW en hebben als doel inzicht te behouden in het functioneren van de webomgeving en aanvallen hierop. Het is belangrijk om causale verbanden te leggen tussen gebeurtenissen op verschillende lagen, verzamelde logginggegevens actief te bekijken en samenwerking tussen verschillende afdelingen van een organisatie te bevorderen om op die manier multidisciplinair problemen te verhelpen en te detecteren. 5

Summary Securing web applications entails more than encrypting traffic or implementing firewalls. Technical and procedural measures at different layers are required for optimal protection of the web application. The Web Application Security Framework (WASF), the main subject of this whitepaper, describes all the (technical) layers that developers, system administrators and architects should focus on when securing web applications. These layers are network security, platform security, application security, identity and access management, confidentiality and non-repudiation, security integration and monitoring. This summary briefly describes each of these layers. Network security Network security focuses on the protection of the web environment at the network-level through the use of firewalls, routers and switches. An important topic is a solid DMZ design that focuses on compartmentalization in different network segments, forced route paths through the DMZ and separation of production and management traffic. To prevent miscreants from attacking web applications at the network layer, organizations should harden systems on the network level and implement measures against Distributed Denial-of-Service (DDoS) attacks. Hardening involves the removal of unneeded services and the use of safe system management mechanisms. Platform security Platform security focuses on securing the operating systems on which web applications run. To prevent attackers from misusing known and new vulnerabilities, it is important to implement a solid update mechanism. Not only the technical organization of this is important, also the procedures around updating need attention. Restricting user rights, hardening essential protocols such as TCP and IP and using security templates all decrease the chances that attackers are able to successfully comprise a system. As a last resort, auditing on the OS-level provides a way to detect possible misuse of a system. Application security This whitepaper has a strong focus on application security. Many of the vulnerabilities found in web applications nowadays, originate from errors made by web developers during the development of a web application. Examples of this kind of vulnerability are Cross- Site Scripting (XSS), SQL injection and command injection. Many of these problems are caused by the fact that developers insufficiently validate user input and application output. Validating all user input, encoding unsafe characters Application security Safe input data handling Output encoding Use of parameterized queries Use of restricted accounts Developer education Use of a Web Application Firewall 6

in the output and using parameterized queries when communicating with the database are the most important measures to prevent these problems. Other important measures are the use of restricted database accounts and the education of safe coding practices to developers. A Web Application Firewall (WAF) is a specialized component that can increase the security of web applications. A WAF functions as a reverse proxy or as a plug-in on a webserver and is specifically built to filter user input, validate protocols, filter output and normalize and log all requests to web servers. Although a WAF can be a valuable addition to a web security infrastructure, it cannot be detached from other security measures on the application level. Identity and Access Management Implementing a solid session management mechanism turns out to be a problematic issue for a lot of web applications. Instead of reinventing the wheel, using a specialized tool for Identity and Access Management (I&AM) can be useful for this matter. Considering the use of such a tool and determining the place of identity and access management functionality within the web environment is essential. In conclusion it s also important to not only implement a login mechanism but also a logout mechanism allowing a user to terminate his session. Confidentiality and non-repudiation The focus in the layer Confidentiality and non-repudiation is on the protection of data and proving that a certain transaction took place. To be able to protect data it is essential to implement encryption on the transport level by using SSL or TLS. However, encryption on the transport level is not enough. One should also encrypt data that is stored in databases to prevent miscreants from retrieving sensitive data through e.g. SQL injection, once this data is saved to a database. In conclusion the advice is to also make use of digital signatures to achieve non-repudiation of transactions, when needed. Security integration Within the different layers of the WASF, different tools cooperate in securing the web application. In order to achieve tight cooperation between these different tools, it is important to focus on the integration of these tools. This integration is part of the Security Integration layer of the WASF. With each and every component in the WASF it is important to consider the security services this component can offer to other components and the security services this component needs from other components. 7

Monitoring, auditing and alerting Monitoring, auditing and alerting apply to every layer of the WASF and aim to gain a clear insight into the functioning of the web environment and attacks on this environment. It is important to focus on causal connections between the events on different layers and to actively monitor these events. Cooperation between the different departments of an organization is essential in order to effectively detect and resolve problems in a multidisciplinary manner. 8

1. Inleiding Steeds meer organisaties bieden diensten aan klanten aan via internet. Dit gebeurt bijvoorbeeld via websites, extranetten en webservices. De mogelijkheden die dit soort applicaties bieden nemen steeds verder toe, evenals de informatie die bedrijven en overheden aanbieden via dergelijke toepassingen. Voldoende aandacht voor de beveiliging van deze applicaties is essentieel om informatie afdoende te beschermen en het vertrouwen van eindgebruikers in zulke internet enabled applicaties niet te schaden. Onderzoek van Cenzic 1, leverancier van producten op het gebied van webapplicatiebeveiliging, naar de beveiliging van webapplicaties levert een zorgwekkend beeld op: Slechts 49% van de geënquêteerden voelt zich gemakkelijk bij de beveiliging van de websites van de organisatie. 28% heeft geen idee of er zich ooit een veiligheidsincident heeft voorgedaan op de website(s) onder beheer. 49% voert tijdens de ontwikkeling van webapplicaties geen (beveiligings)tests uit. Tegelijkertijd concludeert SANS Institute dat webapplicaties het belangrijkste doelwit van kwaadwillenden zijn 2 : ongeveer 60% van alle aanvallen vanaf het internet is gericht op webapplicaties. Ook alarmerend is dat van alle nieuw ontdekte en bekend gemaakte kwetsbaarheden, ongeveer 80% kwetsbaarheden in webapplicaties betreft. Aangezien een webapplicatie vaak onderdeel uitmaakt van een keten van ict-services, is het belangrijk dat de aandacht bij de beveiliging van een webapplicatie niet alleen uitgaat naar alleen de webapplicatie. Ook alle omliggende componenten (databases, logging servers, proxies, etcetera), waarvan de webapplicatie afhankelijk is, vervullen een belangrijke rol in het functioneren van de webapplicatie. Deze componenten moeten daarom ook worden betrokken in het geheel aan beveiligingsmaatregelen. Deze whitepaper beschrijft een raamwerk (het Raamwerk Beveiliging Webapplicaties, kortweg RBW) dat aandacht besteedt aan alle lagen van beveiliging van webapplicaties en omliggende componenten. Deze whitepaper is bedoeld voor architecten, systeemontwikkelaars, beheerders en security officers die betrokken zijn bij de beveiliging en ontwikkeling van webapplicaties. Het whitepaper is technisch georiënteerd en gaat ervan uit dat de lezer 1 http://www.cenzic.com/downloads/downloads/cenzic_survey_emedia-200910.pdf 2 http://www.sans.org/top-cyber-security-risks/ 9

technische basiskennis heeft van de meest gebruikte protocollen en technieken op het gebied van webapplicaties. 1.1. Leeswijzer Hoofdstuk 2 van dit document introduceert het Raamwerk Beveiliging Webapplicaties (RBW). Het raamwerk bestaat uit verschillende lagen die elk een onderdeel van de beveiliging van webapplicaties behandelen. De daaropvolgende hoofdstukken gaan dieper in op de verschillende lagen van dit raamwerk. Elk hoofdstuk start met een beschrijving van de specifieke laag uit het raamwerk, waarna de bedreigingen, kwetsbaarheden en mogelijke maatregelen aan bod komen. Mocht u geïnteresseerd zijn in één specifiek onderdeel van de beveiliging van webapplicaties, dan kunt u het beste eerst hoofdstuk 2 doorlezen om vervolgens één van de deelonderwerpen in meer detail te bestuderen. Eén van de belangrijkste onderwerpen in deze whitepaper is de applicatiebeveiliging. Vandaar dat dit onderwerp is beschreven in verschillende hoofdstukken waarbij eerst de kwetsbaarheden op applicatieniveau worden beschreven (hoofdstuk 5) en vervolgens de maatregelen voor dat niveau (hoofdstuk 6). Daarnaast is een apart hoofdstuk gewijd aan Web Application Firewalls (WAF), systemen die een belangrijke rol kunnen spelen in het beveiligen van een webapplicatie op applicatieniveau. De lagen van het raamwerk zijn als volgt verdeeld over de hoofdstukken: Hoofdstuk 3: Netwerkbeveiliging. Hoofdstuk 4: Beveiliging van het platform/besturingssysteem. Hoofdstuk 5: Kwetsbaarheden in webapplicaties. Hoofdstuk 6: Maatregelen op applicatieniveau. Hoofdstuk 7: Gebruik van Web Application Firewalls (WAF) voor het beveiligen van een webapplicatie op applicatieniveau. Hoofdstuk 8: Afscherming van webapplicaties via authenticatie- en autorisatiemechanismen. Hoofdstuk 9: Implementatie van vertrouwelijkheid en onweerlegbaarheid in webapplicaties. Hoofdstuk 10: Integratie van de webapplicatie met de verschillende beveiligingscomponenten. Hoofdstuk 11: Inrichting van monitoring, auditing en alerting. 10

OPMERKING De rode draad in dit document, is dat beveiling vanuit ketenperspectief benaderd wordt. Dan alleen ontstaat een optimaal beveiligde omgeving. Een dergelijk resultaat volgt niet als beveiliging per losstaande component wordt ingericht.. Daarom is het voor een juiste perceptie op de beveiliging van webapplicaties, aan te raden om het hele document door te lezen. Dit document gebruikt veel afkortingen. Een overzicht van alle gebruikte afkortingen kunt u terugvinden in bijlage B. Een puntsgewijze opsomming van alle kwetsbaarheden, bedreigingen en aanbevelingen uit dit document vindt u terug in bijlage C. Tot slot gebruikt dit document ook voetnoten om bepaalde termen of begrippen te verduidelijken. Deze voetnoten herkent u aan een cijfer in superscript (bijvoorbeeld: 3 ). NOOT Indien in dit document de naam van een product, dienst, fabrikant of leverancier wordt genoemd, betekent dit niet dat GOVCERT.NL deze op enige wijze goedkeurt, afkeurt, aanraadt, afraadt of anderszins hiermee verbonden is. 11

2. Raamwerk Beveiliging Webapplicaties Dit hoofdstuk introduceert het Raamwerk Beveiliging Webapplicaties, kortweg RBW. Dit raamwerk beschrijft de verschillende aspecten die aan bod moeten komen bij het beveiligen van een webapplicatie. Het hoofdstuk start met een beschrijving van het begrip webapplicatie en mogelijke generieke kwetsbaarheden in webapplicaties. Dan volgen het RBW en de doelen en reikwijdte van het raamwerk in hoofdlijnen. Daarnaast illustreert dit hoofdstuk kwetsbaarheden in webapplicaties aan de hand van een aantal incidenten dat zich op dit gebied heeft voorgedaan in Nederland. Het hoofdstuk eindigt met een aantal generieke aanbevelingen. 2.1. Webapplicaties Wanneer dit document spreekt over een webapplicatie dan gaat het om een applicatie die bereikbaar is via een webbrowser of via een andere client die ondersteuning biedt voor het Hypertext Transfer Protocol (HTTP). Een dergelijke client noemt men een HTTP user agent. Kern van deze definitie is dat een webapplicatie altijd bereikbaar is op basis van HTTP of de versleutelde vorm hiervan: HTTPS (HTTP Secure). De functionaliteit die een webapplicatie kan bieden is onbeperkt, de techniek is echter altijd gebaseerd op de http-protocolstandaard zoals gedefinieerd in Request for Comments (RFC) 1945 3, 2068 4, 2616 5, 2617 6 en 2965 7. Enkele voorbeelden van applicaties die volgens deze definitie onder de noemer webapplicatie vallen: Internetsites. Internetsites zijn websites die voor iedereen toegankelijk zijn. Door met een browser naar een website te surfen (bijvoorbeeld www.govcert.nl) kan iemand informatie over een organisatie opvragen, formulieren downloaden en vragen aan een organisatie stellen. Extranetten. Extranetten maken gebruik van dezelfde technieken als internetsites met dit verschil, dat vaak enige vorm van authenticatie en autorisatie plaatsvindt. Extranetten zijn in de regel bedoeld voor klanten van een organisatie. Via een extranet kan een klant bijvoorbeeld opdrachten geven, statussen bekijken en documenten inzien. De kennisbank van GOVCERT.NL (kennisbank.govcert.nl) is een voorbeeld van een extranet. 3 RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0: http://www.ietf.org/rfc/rfc1945.txt 4 RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1: http://www.ietf.org/rfc/rfc2068.txt 5 RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1: http://www.ietf.org/rfc/rfc2616.txt 6 RFC 2617: HTTP Authentication (Basic and Digest): http://www.ietf.org/rfc/rfc2617.txt 7 RFC 2965: HTTP State Management Mechanism: http://www.ietf.org/rfc/rfc2965.txt 12

Intranetten. Ook intranetten maken gebruik van dezelfde technieken als internetsites. Intranetten zijn echter alleen bedoeld voor interne medewerkers van een organisatie en bieden bijvoorbeeld de mogelijkheid om interne berichten te verspreiden. Intranetten zijn veelal alleen vanuit de infrastructuur van de eigen organisatie te bereiken. Software-as-a-Service (SaaS)-webapplicaties. Veel hedendaagse webapplicaties zijn niet meer te vangen onder één van de eerdere noemers. Het gaat hierbij om webapplicaties die functionaliteiten aanbieden aan geregistreerde gebruikers, zonder dat daarbij de doelgroep gelimiteerd is tot klanten (extranetten) of werknemers (intranetten). Voorbeelden van dit soort webapplicaties zijn webmail toepassingen (Gmail, Hotmail) en sociale platformen (Twitter, Facebook, Hyves) die men vaak aanduidt als Software-as-a-Service (SaaS) toepassingen. Webservices en Web API s. De voorgaande typen webapplicaties maken allen gebruik van Hypertext Markup Language (HTML) om te communiceren met de gebruiker. HTML maakt het mogelijk om webpagina s op te maken en weer te geven in een webbrowser. Webservices maken geen gebruik van HTML maar van extensible Markup Language (XML) of een variatie hierop. Net als bij HTML, gebruikt een webservice HTTP(S) als middel voor het uitwisselen van berichten. SOAP is één van de meest gebruikte standaarden om invulling te geven aan een webservice. XML bevat geen lay-out informatie zoals bij HTML, maar bevat informatie in een gestructureerde, vooraf gedefinieerde, vorm. Webservices verbinden in de regel applicaties met elkaar en baseren informatie-uitwisseling tussen deze applicaties op het gebruik van XML-berichten. Ook bij veel Web 2.0 -applicaties vindt op XML-gebaseerde informatie-uitwisseling plaats waarbij een speciaal object in de browser (het zogenoemde XMLHTTPobject) een webapplicatie benadert voor het dynamisch vullen van (onderdelen van) een webpagina. We spreken in dit geval niet van een webservice maar van een Web API. Een Web API kan, in plaats van XML, ook een ander gestandaardiseerd formaat zoals JavaScript Object Notation (JSON) gebruiken voor het uitwisselen van informatie. De RSS-feed van Waarschuwingsdienst.nl (http://www.waarschuwingsdienst.nl/rss.xml) is een voorbeeld van een webservice. Hoewel webapplicaties normaal gesproken gebruik maken van twee standaard TCPpoorten (80/tcp voor HTTP, 443/tcp voor HTTPS), kan een webapplicatie ook gebruik maken van een andere poort (bijvoorbeeld 8080/tcp). In dat geval spreken we nog steeds van een webapplicatie aangezien de applicatie te benaderen is op basis van standaard HTTP-berichten. 13

2.2. Het HTTP-protocol Om de verschillende dreigingen, kwetsbaarheden en voorgestelde maatregelen in dit document goed te kunnen begrijpen, is het van belang kennis te hebben van basisbegrippen rondom het HTTP-protocol. Deze paragraaf behandelt daarom enkele basiseigenschappen van HTTP, het gebruik van vraag- en antwoordkoppels binnen HTTP, het via HTTP versturen van informatie vanaf een client richting een webserver en het versleutelen van deze informatie. 2.2.1. Basiseigenschappen van HTTP Hieronder volgen de belangrijkste eigenschappen van HTTP: HTTP werkt met vraag- (HTTP-request) en antwoordberichten (HTTP-response). In de meeste gevallen is communicatie via HTTP synchroon van aard: de client stuurt een vraag en ontvangt, in dezelfde sessie, onmiddellijk een antwoord van de webserver. In sommige gevallen is de actie die de webserver moet uitvoeren zo complex dat deze niet binnen een bepaalde time-out kan reageren. Dan is het mogelijk om over te schakelen op asynchrone communicatie. Hierbij ontvangt de client het antwoord van de webserver via een aparte sessie. Een overeenkomstig kenmerk in het vraag- en antwoordbericht is in deze gevallen nodig om vraag en antwoord aan elkaar te kunnen koppelen. Sommige webservices maken gebruik van asynchrone communicatie. Elk HTTP-bericht bestaat uit een kop en een bericht (HTTP-payload). De kop bevat onder andere de zogenoemde HTTP-headers. HTTP-headers bevatten metainformatie over het bericht zoals het type payload (bijvoorbeeld tekst, HTML of XML), het gebruikte type webserver, de naam van de webserver en de inhoud van een cookie. De volgende HTTP-headers in een verzoek zijn voor deze whitepaper relevant, omdat ze een belangrijke rol spelen bij sommige beveiligingsmaatregelen: - Authorization: base64 gecodeerde gebruikersnaam en wachtwoord; - Cookie: inhoud van eventuele cookies waarover de gebruiker beschikt; - Host: naam van de website die men wil bevragen (bijvoorbeeld www.govcert.nl); - Referer 8 : URL waarvandaan de gebruiker de pagina benadert. HTTP is stateless. Dit betekent dat elk vraag-antwoordkoppel los van elkaar staat. De webserver beantwoordt elk vraagbericht daarom onafhankelijk van het vorige bericht. Omdat statusbehoud wel van belang is (bijvoorbeeld het onthouden van 8 De naam van deze header is foutief gespeld in de specificatie van HTTP terecht gekomen. Eigenlijk zou deze header daarom referrer in plaats van referer moeten heten. 14

authenticatie-informatie), hebben ontwikkelaars dit via speciale mechanismen ingebouwd in HTTP. Cookies vormen één van de mogelijkheden om deze status te behouden. Het bijhouden van statusinformatie valt vaak onder de noemer sessiemanagement. 2.2.2. HTTP vragen en antwoorden Zoals paragraaf 2.2.1 al beschreef, werkt HTTP met vraag- en antwoordberichten. Een typisch vraag-antwoordkoppel is weergegeven in figuur 2-1. Zowel het vraag- als het antwoordbericht bevat een verzameling headers die meta-informatie over het bericht geven. Daarnaast bevat een bericht in veel gevallen een http-payload, de eigenlijke inhoud van het bericht. HTTP-request HTTP-response GET / HTTP/1.1 HTTP/1.1 401 Authorization Required HTTP-headers Accept: image/gif, image/x-bitmap Accept-Encoding: gzip, deflate Accept-Language: nl Connection: Keep-Alive Cookie: CFID=15014; CFTOKEN=622 Host: www.website.nl User-Agent: Mozilla/4.0 Connection: close Content-Type: text/html Date: Mon, 2 July 2006 13:00:00 GMT Server: Apache/1.3.29 (Linux/SUSE) Transfer-encoding: chunked WWW-authenticatie: Basic realm= X <HTML> <HEAD> <TITLE> Please authenticate yourself! </TITLE> </HEAD> <BODY> </BODY> </HTML> HTTP-headers HTTP-payload Figuur 2-1: HTTP vraag- en antwoordbericht 2.2.3. Informatieoverdracht van client naar server Veel webapplicaties maken gebruik van invoer van gebruikers. Er bestaan grofweg twee manieren om invoer van een gebruiker naar een webapplicatie te sturen: Via query parameters in de URL. Een webapplicatie maakt gebruik van queryparameters wanneer een ontwikkelaar heeft aangegeven dat een ingevuld formulier via de GET-methode moet worden aangeboden aan de webapplicatie. Via variabelen in de body van het bericht. Een browser biedt variabelen aan in de payload van het bericht wanneer een ontwikkelaar heeft aangegeven dat een 15

ingevuld formulier via de POST-methode moet worden aangeboden aan de webapplicatie. Stel bijvoorbeeld dat een webapplicatie een inlogscherm heeft waarop een gebruiker zijn gebruikersnaam en wachtwoord moet invullen. Als dit formulier gebruik maakt van de GET-methode zal de browser de opgegeven combinatie van gebruikersnaam en wachtwoord achter de URL plakken. Bij de POST-methode plaatst de browser deze gegevens in de HTTP-body. Figuur 2-2 illustreert dit. Figuur 2-2: GET en POST Om te voorkomen dat gebruikersinvoer ervoor zorgt dat verzoeken syntactisch incorrect worden (de vereiste opbouw van het bericht verstoren), kan een browser bepaalde karakters uit de invoer coderen, ofwel in een andere vorm opnemen in het verzoek. Zo is het vraagteken een speciaal karakter in een URL omdat het de scheiding vormt tussen de geraadpleegde resource en de parameters die de gebruiker aanbiedt. Plaatst een gebruiker een vraagteken in zijn invoer, dan zal de browser dit vraagteken coderen als %3f, het hexadecimale equivalent van het vraagteken. Ook spaties zijn in een URL niet mogelijk. Een browser zal spaties automatisch omzetten naar + -tekens. Gebruikersinvoer als a / b? zal de browser daarom coderen als a+%2f+b%3f. 2.2.4. Versleutelen van informatie Om HTTP-berichten versleuteld over internet te sturen, kun je gebruik maken van Secure Sockets Layers (SSL) of Transport Layer Security (TLS). Naast versleuteling maken SSL en TLS ook authenticatie mogelijk: de webserver authenticeert zich (bewijst zijn identiteit) via een servercertificaat, de gebruiker via een clientcertificaat. In veel gevallen past men bij SSL/TLS-authenticatie alleen authenticatie van de 16

webserver toe. Gebruikers kunnen toepassing van SSL/TLS herkennen doordat de URL start met https:// in plaats van http://. 2.3. Mogelijke kwetsbaarheden en bedreigingen Een webapplicatie heeft te maken met een groot aantal mogelijke kwetsbaarheden en bedreigingen. Deze kwetsbaarheden en bedreigingen bevinden zich op verschillende niveaus; denk hierbij aan kwetsbaarheden en bedreigingen op netwerkniveau (bijvoorbeeld Denial of Service), op authenticatieniveau (bijvoorbeeld het omzeilen van authenticatiemechanismen) of op applicatieniveau (bijvoorbeeld Cross-Site Scripting). Veel publicaties op het gebied van beveiliging van webapplicaties richten zich vooral op het applicatieniveau. Figuur 2-3 toont de resultaten van onderzoeken van het Web Application Security Consortium (WASC) 9 en Whitehat Security 10 naar veel voorkomende lekken in webapplicaties. Hieruit blijkt bijvoorbeeld dat Cross-Site Scripting en Information Leakage de belangrijkste kwetsbaarheden zijn op applicatieniveau. Figuur 2-3: overzicht webapplicatie kwetsbaarheden op applicatieniveau 9 http://www.webappsec.org/projects/statistics/ 10 http://www.whitehatsec.com/home/assets/wpstatsreport_100107.pdf 17

Alle soorten kwetsbaarheden en bedreigingen, dus niet alleen die op applicatieniveau, krijgen een plek in het RBW en komen aan de orde bij de beschrijving van de afzonderlijke onderdelen uit het raamwerk (hoofdstuk 3 t/m 11). Drie generieke kwetsbaarheden en bedreigingen noemen we hier alvast, omdat ze aanwezig kunnen zijn op alle afzonderlijke lagen van het raamwerk en niet gebonden zijn aan één van deze lagen: Configuratiefouten. Wanneer je niet nadenkt over de configuratie van software en deze software out-of-the-box uitrolt, dan kan dit tot beveiligingsproblemen leiden. In andere gevallen gebeurt dat wel, maar doen zich fouten voor bij het daadwerkelijk effectueren van de configuratie. Ook in het laatste geval kunnen beveiligingsproblemen het resultaat zijn. Aanwezigheid van bekende kwetsbaarheden. Dagelijks verschijnen op internet beveiligingsadviezen van verschillende leveranciers waarin de leverancier een kwetsbaarheid in één van zijn softwareproducten beschrijft. Zodra de leverancier (of de ontdekker) details over een dergelijke kwetsbaarheid bekend maakt, is het vaak een kwestie van tijd voordat publieke code verschijnt waarmee kwaadwillenden deze kwetsbaarheid op eenvoudige manier kunnen misbruiken. Het is belangrijk geleverde updates snel te installeren om de kwetsbaarheid te verhelpen. Aanwezigheid van nieuwe (0-day-) kwetsbaarheden. Wanneer niet de leverancier maar een derde (bijvoorbeeld een hacker) een kwetsbaarheid bekend maakt, en de leverancier niet in staat is gesteld om updates voor zijn software uit te brengen, dan spreek je van een 0-day kwetsbaarheid. Aangezien organisaties zo n kwetsbaarheid niet meteen kunnen verhelpen door updates te installeren, ben je afhankelijk van eventuele workarounds. Deze kwetsbaarheden kunnen zich in alle verschillende lagen van de webomgeving bevinden: van een kwetsbaarheid in het OS van een router tot aan een kwetsbaarheid in de code van een 3rd party Content Management Systeem (CMS). Kwaadwillenden maken dankbaar misbruik van 0-day-kwetsbaarheden om aanvallen op webapplicaties uit te voeren. Bedenk dat kwaadwillenden op basis van specifieke eigenschappen, eenvoudig op internet kunnen zoeken naar kwetsbare webapplicaties. Dit kan bijvoorbeeld via zoekmachines als Google ( Google Hacking ), waardoor de drempel voor het aanvallen van webapplicaties heel laag is. 18