WWW.GOVCERT.

NL

RAAMWERK BEVEILIGING WEBAPPLICATIES

POSTADRES

Postbus 84011 2508 AA Den Haag
BEZOEKADRES

Wilhelmina van Pruisenweg 104 2595 AN Den Haag
TELEFOON

070 888 75 55
FAX

070 888 75 50
E-MAIL

info@govcert.nl

Auteur(s) Versie Den Haag

: GOVCERT.NL 1.3 : 27.10.2006 : Publieke uitgave: 30.07.2009

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. GBO.OVERHEID is de Gemeenschappelijke Beheer Organisatie 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-commercieelGelijk delen 3.0 Nederland licentie. Kijk voor meer informatie op http://creativecommons.org/licenses/by-nc-sa/3.0/nl/

INHOUD
English Summary .........................................................................................................1 1 1.1 2 2.1 2.2 2.3 2.4 2.5 2.6 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6 6.1 6.2 6.3 7 7.1 7.2 7.3 8 8.1 8.2 8.3 Inleiding..........................................................................................................2 Leeswijzer ....................................................................................................... 2 Raamwerk Beveiliging Webapplicaties ............................................................4 Webapplicaties ................................................................................................. 4 Mogelijke kwetsbaarheden en bedreigingen .......................................................... 6 Het Raamwerk ................................................................................................. 7 Doelen ............................................................................................................ 9 Scope ........................................................................................................... 10 Algemene aanbevelingen ................................................................................. 11 Netwerkbeveiliging .......................................................................................13 Inleiding........................................................................................................ 13 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 13 Aanbevelingen ............................................................................................... 17 Platformbeveiliging .......................................................................................30 Inleiding........................................................................................................ 30 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 30 Aanbevelingen ............................................................................................... 33 Applicatiebeveiliging .....................................................................................42 Inleiding........................................................................................................ 42 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 42 Aanbevelingen ............................................................................................... 52 Identiteit- en Toegangsbeheer ......................................................................73 Inleiding........................................................................................................ 73 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 75 Aanbevelingen ............................................................................................... 81 Vertrouwelijkheid en onweerlegbaarheid ......................................................88 Inleiding........................................................................................................ 88 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 88 Aanbevelingen ............................................................................................... 89 Beveiligingsintegratie....................................................................................94 Inleiding........................................................................................................ 94 Mechanismen ................................................................................................. 94 Aanbevelingen ............................................................................................... 98

9 9.1 9.2 9.3 A B C D

Monitoring, auditing en alerting ....................................................................99 Inleiding........................................................................................................ 99 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 99 Aanbevelingen ..............................................................................................101 Referenties .................................................................................................. 110 Beveiligingsadvies GOVCERT.NL-2006-133.................................................. 111 Afkortingen en definities ............................................................................. 113 Hoofdpunten Beveiliging ............................................................................. 115

ENGLISH SUMMARY
This Framework for Web Application Security provides an overview of security aspects at various layers of a web application environment; i.e. any application that can be reached over HTTP. The framework describes vulnerabilities, threats and recommendations in chapters about the following layers: The network. This is one of the most important layers when securing web applications and is the precondition for securing other layers. The components in this layer should only allow essential protocols, such as HTTP and HTTPS, and block all others. A DMZ, DNS and firewalls are all part of this layer. The operating system. The OS is the link between the network and the web application. Vulnerabilities in the operating system can have a direct impact on the security of the web application. The framework discusses, among other things, maintenance, hardening, access control and back-ups of the operating system. The application platform. Fortunately, focus on the security of web applications has increased in recent years. The framework discusses various common errors, such as insuficient input validation, cross site scripting and SQL injection vulnerabilities. It also discusses methods of protection, such as secure coding, application level firewalls, HTTPS and VPNs. Authentication and autorisation, including various types of access control (role based, rule based, mandatory etc), the use of two factor authentication and session management. Confidentiality and Integrity of information, using encryption and digital signatures. Integration of the web application with various security components. This chapter discusses ways in which a web application can retrieve information from other components for security purposes, such as the usernames of authenticated users. A well designed and coherent system of components will greatly increase the overall security. Monitoring, auditing and logging. The framework does not treat these layers as separate components, but rather as part of a chain of components that all need to be secured in order to provide for a secure environment.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

1/116

1

INLEIDING
Steeds meer organisaties bieden services aan klanten aan via internet. Men gebruikt hiervoor bijvoorbeeld websites, extranetten en webservices. Met de toename aan webapplicaties gaat ook een toename aan beveiligingsincidenten gepaard. Zo blijkt uit onderzoek van de FBI en het Computer Security Institute (CSI) uit 2005 (FBI/CSI, 2005) dat 95% van alle organisaties meer dan 10 beveiligingsincidenten per jaar met webapplicaties registreerden. Opvallend is dat een jaar eerder maar 5% van de respondenten aangaf meer dan 10 beveiligingsincidenten met webapplicaties te hebben meegemaakt. Verschillende oorzaken kunnen ten grondslag liggen aan deze dramatische toename van beveiligingsincidenten; enkele mogelijke oorzaken zijn: • • Het aantal webapplicaties is sterk toegenomen waardoor de kans op misbruik ook toeneemt; De monitoring van de beveiliging rondom webapplicaties is verbeterd waardoor beveiligingsincidenten eerst niet werden opgemerkt maar nu wel; Publieke exploits voor kwetsbaarheden verschijnen steeds sneller op internet waardoor de kans op uitbuiting van deze kwetsbaarheden toeneemt.

Ongeacht de exacte oorzaak van de toename aan incidenten is het bij het inrichten van webapplicaties van belang dat het aspect beveiliging voldoende aandacht krijgt. Aangezien een webapplicatie onderdeel uitmaakt van een keten van ict-services is het belangrijk dat de aandacht niet alleen uitgaat naar sec de webapplicatie. Ook alle omliggende componenten (databases, logging servers, procies, etc…), waarvan de webapplicatie afhankelijk is, vervullen een belangrijke rol in het functioneren van de webapplicatie. Deze componenten dient men daarom te betrekken in het geheel aan beveiligingsmaatregelen. Dit document beschrijft een raamwerk (het Raamwerk Beveiliging Webapplicaties, kortweg RBW) dat aandacht besteedt aan alle lagen van beveiliging rondom webapplicaties en omliggende componenten.

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 rondom webapplicaties behandelen. De daaropvolgende hoofdstukken gaan dieper in op de verschillende onderdelen van dit raamwerk. Elk hoofdstuk start met een beschrijving van het specifieke onderdeel uit het raamwerk waarna de bedreigingen, kwetsbaarheden en mogelijke maatregelen de revue passeren. Mocht u geïnteresseerd zijn in één specifiek onderdeel van beveiliging van webapplicaties dan kunt u het beste eerst

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

2/116

hoofdstuk 2 doorlezen om vervolgens één van de deelonderwerpen in meer detail te bestuderen. De onderwerpen zijn als volgt verdeeld over de hoofdstukken: • • • • • Hoofdstuk 3: netwerkbeveiliging; Hoofdstuk 4: beveiliging van het platform/besturingssysteem; Hoofdstuk 5: beveiliging van de webapplicatie en het applicatieplatform waarop de webapplicatie werkt; Hoofdstuk 6: afscherming van webapplicaties via authenticatie- en autorisatiemechanismen; Hoofdstuk 7: implementatie van vertrouwelijkheid en onweerlegbaarheid in webapplicaties. In dit hoofdstuk komen zaken als versleuteling en digitale handtekeningen aan de orde; Hoofdstuk 8: integratie van de webapplicatie met de verschillende beveiligingscomponenten. Dit hoofdstuk kijkt bijvoorbeeld naar de manier waarop een webapplicatie informatie over geauthenticeerde gebruikers kan opvragen bij een losstaand beveiligingscomponent. Hoofdstuk 9: inrichting van monitoring, auditing en alerting.

OPMERKING De rode draad die door dit document loopt, is dat beschouwing van beveiliging vanuit een ketenperspectief (tegenover beveiliging van losse componenten) van belang is. Door tijdens het inrichten van beveiliging van webapplicaties alleen beveiliging per losstaand component in te richten, ontstaat geen optimaal beveiligde omgeving. Daarom is het, voor een juiste perceptie op beveiliging van webapplicaties, aan te raden om het gehele document door te lezen. Dit document maakt veelvuldig gebruik van afkortingen en specifieke termen. Een overzicht van alle gebruikte afkortingen en termen kunt u terugvinden in bijlage C. Een puntsgewijze opsomming van alle kwetsbaarheden, bedreigingen en aanbevelingen uit dit document vindt u terug in bijlage D. 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.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

3/116

2

RAAMWERK BEVEILIGING WEBAPPLICATIES
Dit hoofdstuk introduceert het RBW. Dit raamwerk beschrijft de verschillende aandachtspunten die aan bod moeten komen bij het beveiligen van een webapplicatie. Het hoofdstuk start met een beschrijving van het begrip webapplicatie en mogelijke kwetsbaarheden en dreigingen m.b.t. webapplicaties, om vervolgens het RBW in hoofdlijnen te beschrijven.

2.1

Webapplicaties Wanneer dit document spreekt over een webapplicatie dan betekent dit in grote lijnen: 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 oneindig, de techniek is echter altijd gebaseerd op de HTTP protocolstandaard zoals gedefinieerd in RFC 26161. Enkele voorbeelden van applicaties die volgens deze definitie onder de noemer webapplicatie vallen: • Internetsites; internetsites zijn publieke websites die voor iedereen toegankelijk zijn. Door met een browser naar een website te surfen (bijvoorbeeld www.govcert.nl) kan men informatie over een organisatie opvragen, formulieren downloaden, vragen aan de organisatie stellen, etc…. Extranetten; extranetten maken gebruik van dezelfde technieken als internetsites met het 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, documenten inzien, etc… De kennisbank van GOVCERT.NL (kennisbank.govcert.nl) is een voorbeeld van een extranet. 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.

1

Zie: http://rfc.net/rfc2616.html 4/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

Webservices; 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). 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. De RSS2-feed van De Waarschuwingsdienst (http://www.waarschuwingsdienst.nl/rss.xml) is een voorbeeld van een webservice.

Hoewel webapplicaties normaal gesproken gebruik maken van de 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. ACHTERGROND Om de verschillende dreigingen, kwetsbaarheden en voorgestelde maatregelen in dit document goed te kunnen begrijpen, is het van belang enige basiseigenschappen van HTTP goed te begrijpen. Hieronder volgen de belangrijkste eigenschappen van HTTP: • • HTTP werkt met vraag- (HTTP-request) en antwoordberichten (HTTPresponse); In de meeste gevallen is communicatie via HTTP synchroon van aard: de client stuurt en vraag en ontvangt, in dezelfde sessie, onmiddellijk een antwoord van de server. In sommige gevallen is de actie die de server moet uitvoeren dusdanig complex dat deze niet binnen een bepaalde timeout kan reageren. In dit soort gevallen bestaat de mogelijkheid om over te schakelen op asynchrone communicatie. Hierbij ontvangt de client het antwoord van de server via een aparte sessie. Een overeenkomstig kenmerk in het vraag- en antwoordbericht is in deze gevallen benodigd 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 o.a. de zogenaamde HTTP-headers. HTTP-headers bevatten meta-informatie over het bericht zoals het type payload (bijvoorbeeld tekst, HTML, XML, etc…), het gebruikte type webserver, de naam van de te bevragen host, de inhoud van een cookie, etc… HTTP is stateless. Dit betekent dat elk vraag-antwoordkoppel los van elkaar staat. De webserver beantwoordt elk vraagbericht daarom onafhankelijk van het vorige bericht.

2

Really Simple Syndication (RSS 2.0); manier om informatie van de website in een vastgesteld formaat

beschikaar te stellen aan gebruikers en applicatie Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 5/116

Omdat statusbehoud wel van belang is (bijvoorbeeld het onthouden van authenticatieinformatie) hebben ontwikkelaars via speciale mechanismen statusinformatie ingebouwd in HTTP. Cookies vormen één van de mogelijkheden om deze status te behouden. Een typisch vraag-antwoordkoppel ziet er als volgt uit:

Om HTTP-berichten versleuteld over internet te sturen kan men gebruik maken van SSL (HTTPS). SSL kan tevens wederzijdse authenticatie verzorgen: de server authenticeert zich (bewijst zijn identiteit) middels een server certificaat, de gebruiker via een client certificaat. In veel gevallen past men bij SSL-authenticatie alleen authenticatie van de server toe.

2.2

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 niveau’s; hierbij kan men denken aan kwetsbaarheden en bedreigingen op netwerkniveau (bv. Denial-of-Service), op authenticatieniveau (bv. omzeilen van authenticatiemechanismen) of op applicatieniveau (bv. Cross-Site Scripting). Deze kwetsbaarheden en bedreigingen 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 9). Drie generieke kwetsbaarheden en bedreigingen noemen we hier alvast: • Configuratiefouten; wanneer men niet nadenkt over de configuratie van software en deze software out-of-the-box uitrolt, dan kan dit tot beveiligingsproblemen leiden. In andere gevallen denkt men wel na over de configuratie, maar doen zich fouten voor bij het daadwerkelijk
6/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

implementeren 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 ontdekker of de leverancier details over een dergelijke kwetsbaarheid bekend maakt, is het veelal een kwestie van tijd voordat publieke code verschijnt waarmee kwaadwillenden deze kwetsbaarheid op eenvoudige manier kunnen misbruiken. Het is dan zaak om tijdig de door de leverancier aangeleverde updates 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 spreekt men van een 0-day kwetsbaarheid. Aangezien organisaties een dergelijke kwetsbaarheid niet kunnen verhelpen door updates te installeren, is men afhankelijk van work-arounds en de effectiviteit en haalbaarheid van deze work-arounds. Kwaadwillenden maken dankbaar misbruik van 0-day kwetsbaarheden om aanvallen op webapplicaties uit te voeren.

Voor zowel bekende als 0-day kwetsbaarheden geldt dat kwaadwillenden vaak op basis van specifieke eigenschappen kunnen zoeken naar kwetsbare webapplicaties. Zoekmachines als Google kunnen de kwaadwillende hierbij van nut zijn (‘Google Hacking’). 2.3 Het Raamwerk In figuur 2-1 is het RBW weergegeven. Het raamwerk bevindt zich hierbij logisch gezien tussen een client en een webapplicatie.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

7/116

Figuur 2-1: Raamwerk Beveiliging Webapplicaties

Zoals uit het raamwerk van figuur 2-1 is op te maken bestaat de beveiliging van webapplicaties uit verschillende (beveiligings)lagen. Bekeken vanaf de client verschijnen achtereenvolgens de volgende lagen: • Netwerkbeveiliging; beveiliging die zich met name richt op het afschermen van informatiestromen op het transport-/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 applicatieplatform3. Applicatiebeveiliging hoeft geen geïntegreerd onderdeel van de applicatie zelf te zijn, maar kan ook als losstaand component functioneren binnen de infrastructuur van de webapplicatie. Een application-level firewall is een typisch losstaand component dat geen geïntegreerd onderdeel van de applicatie uitmaakt, maar wel beveiligingservices biedt voor deze applicatie. Identiteitbeheer; identiteitbeheer richt zich o.a. op het authenticeren van gebruikers van webapplicaties. Daarnaast is ook het beheren van deze identiteiten een belangrijke functie.

3

Een webapplicatie is bijvoorbeeld een Websphere toepassing, een applicatieplatform bijvoorbeeld de

Websphere server Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 8/116

Toegangsbeheer; binnen toegangsbeheer worden rechten toegekend op basis van de identiteit van een gebruiker. Afhankelijk van de rechten van de identiteit mag een gebruiker wel of geen gebruik maken van (delen van) de webapplicatie. Vertrouwelijkheid en onweerlegbaarheid; vertrouwelijkheid en onweerlegbaarheid richten zich op het versleutelen van vertrouwelijke gegevens en op de onweerlegbaarheid van transacties die gebruikers via de webapplicatie uitvoeren.

Daarnaast bevinden zich in het raamwerk ook nog een aantal verticale lagen. Deze lagen bieden ondersteuning aan de horizontale lagen: • Beveiligingsintegratie; deze laag richt zich op het integreren van de webapplicatie(s) met de beveiligingsoplossingen uit de verschillende beveiligingslagen. Via correct ingerichte beveiligingsintegratie kan een webapplicatie bijvoorbeeld de services van een toepassing die zich richt op het toegangsbeheer benaderen. 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-1 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 dient te beschikken.

2.4

Doelen Het RBW kent de volgende doelen: • • • • Dienen als referentiepunt voor het implementeren van beveiligingsmaatregelen rondom webapplicaties; Bereiken van samenhang tussen gekozen beveiligingsoplossingen voor webapplicaties; Bereiken van hergebruik van beveiligingsoplossingen zodat niet elke webapplicatie een nieuwe beveiligingsoplossing introduceert; Bevorderen van snelheid en kwaliteit in de implementatie van beveiliging voor webapplicaties (en daarmee het bevorderen van snelheid en kwaliteit in de implementatie van webapplicaties).

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

9/116

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 niet in slagen om hackpogingen op de webapplicatie uit te voeren. Een dergelijke hackpoging kan leiden tot financiële, politieke en juridische schade. Enkele voorbeelden van negatieve publiciteit (imagoschade) waartoe misbruik van een webapplicatie kan leiden ziet u in figuur 2-2.

Figuur 2-2: schade door misbruik

2.5

Scope De scope van het RBW is technisch van aard. Dit betekent dat een aantal aspecten van informatiebeveiliging geen onderdeel uitmaken van het raamwerk. Het raamwerk besteedt bijvoorbeeld geen aandacht aan zaken als beveiligingsorganisatie, fysieke beveiliging en personeel. Veel van de zaken die dit document behandelt, zijn niet alleen van toepassing op webapplicaties maar ook op andere soorten applicaties. Het is daarom onvermijdelijk dat het document naast specifieke beveiligingsoplossingen voor webapplicaties ook algemene beveiligingsoplossingen beschrijft die het beveiligen van webapplicaties vereist.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

10/116

Het raamwerk houdt zich bezig met allerlei zaken die zich binnen een webhosting omgeving kunnen afspelen. Het is goed mogelijk dat voor een webhosting omgeving afwijkende regels en standaarden gelden dan voor een regulier kantoornetwerk. Zo kunnen bijvoorbeeld afwijkende hardenings- en beschikbaarheidseisen 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-3 illustreert de infrastructuur waarin een webhostingomgeving zich kan bevinden en de afbakening van het RBW daarin (rode vlak).

Figuur 2-3: scope 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.6

Algemene aanbevelingen Dit document beschrijft per deelgebied van het RBW een aantal 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:

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

11/116

Test; voordat men een webapplicatie in productie plaatst, is het van belang dat men eerst een uitgebreide test uitvoert op de webapplicatie en de omliggende infrastructuur. Vanuit beveiligingsoptiek is het van belang dat men bij het uitvoeren de test controleert of de webapplicatie en/of de infrastructuur op enigerlei wijze is binnen te dringen of te misbruiken. Het uitvoeren van testen 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 monitoor; aanvallen op de omgeving en misbruik van webapplicaties herkent men in de regel aan afwijkende acties die plaatsvinden binnen de infrastructuur. Zonder een vooraf gedefinieerde baseline en juist ingerichte monitoring is het lastig om te bepalen of een situatie op een bepaald moment afwijkt van de “normale” situatie. Ziet men bijvoorbeeld een groot aantal clients verkeer richting de omgeving initiëren, waarbij dit verkeer de volledige beschikbare bandbreedte opslokt, dan is het de vraag of het hier gaat om een Distributed Denial-ofService (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 er in 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, incl. 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.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

12/116

3

NETWERKBEVEILIGING
Netwerkbeveiliging vormt de onderste laag van het RBW. Het netwerk maakt communicatie met de webapplicatie via internet mogelijk. Het uitvallen van het netwerk of een succesvolle aanval daarop kan daarom ook ernstige gevolgen hebben voor de beschikbaarheid van de webapplicatie. 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 één van de belangrijkste aandachtsgebieden bij het aanbieden van webapplicaties. Het juist afschermen van de verschillende componenten op netwerkniveau is randvoorwaardelijk voor het kunnen invoeren van andere beveiligingscomponenten. Gezien vanaf het internet laten de componenten uit de laag netwerkbeveiliging alleen essentiële internetprotocollen door (HTTP en HTTPS) en blokkeren deze alle overige protocollen4. In het verleden richtten aanvallen op internetomgevingen zich m.n. 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. Aanvallen die echter gebruik maken van valide netwerkverkeer nemen daarentegen steeds verder toe (aanvallen op applicatief niveau – zie hoofdstuk 5). Desalniettemin is het van essentieel belang dat een organisatie zijn netwerk afdoende beveiligt.

3.2

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

4

Hierbij wordt uitgegaan van een dedicated infrastructuur voor webapplicaties waarin zich geen andere services

bevinden zoals mail (SMTP) en DNS.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

13/116

3.2.1

(Distributed) Denial-of-Service5

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. Meestal geschiedt dit door excessief gebruik te maken van een op zich legitiem internetprotocol, bijvoorbeeld het opzetten van een TCPsessie. 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: • • • • Poging om een netwerk te overspoelen met dataverkeer, waarmee legitiem dataverkeer niet meer kan doorkomen; Poging om connecties tussen twee systemen te verbreken; Poging om een gebruiker geen toegang te geven tot een systeem; Poging om een service op een systeem te onderbreken.

Enkele voorbeelden van DoS-aanvallen zijn SYN-aanval, Smurf-aanval, Syslogaanval en E-mailbombing.

3.2.2

Server hopping

Het succesvol compromitteren van een server in de internetomgeving kan op zich al tot ernstige schade leiden. Wanneer een kwaadwillende zich via de gecompromitteerde server echter ook nog toegang kan verschaffen tot andere servers en netwerkcomponenten die zich in de omgeving van de gecompromitteerde machine bevinden (‘server hopping’), loopt de schade alleen nog maar verder op. De kans op ‘server hopping’ is met name aanwezig in platte omgevingen waarin alle servers in één logisch segment zijn geplaatst. In deze omgevingen vervult een centrale firewall een essentiële rol en zal de compromittering van deze firewall of een component achter de firewall tot ernstige consequenties leiden. Figuur 3-1 bevat een voorbeeld van een infrastructuur waarin ‘server hopping’ mogelijk is door de plaats van de firewall en het gebrek aan compartimentering van de achterliggende infrastructuur.

5

Onderstaande tekst is ontleend aan het whitepaper “Aanbevelingen ter bescherming tegen Denial-of-Service

aanvallen” van GOVCERT.NL (DDoS-GOVCERT, 2005). U kunt dit document downloaden via de Kennisbank van GOVCERT: kennisbank.govcert.nl (toegang tot deze Kennisbank is alleen mogelijk wanneer u beschikt over toegangsrechten) Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 14/116

Figuur 3-1: server hopping

In figuur 3-1 scheidt één enkele firewall het internet en de webhosting omgeving van elkaar. Op het moment dat een kwaadwillende de beperkingen van de firewall weet te omzeilen – door de kwetsbare machine te comprimmiteren – beschikt deze vervolgens over de ‘keys to the kingdom’: vanaf de gecomprommiteerde machine kan de kwaadwillende zonder tussenkomst van een firewall alle omliggende machines benaderen.

3.2.3

Kwetsbare DNS(configuratie)

Domain Name Services (DNS) zijn zeer belangrijke services voor webapplicaties. Zonder de beschikbaarheid van DNS kunnen gebruikers een website niet op basis van bekende hostnamen (bijvoorbeeld www.overheid.nl) bereiken. Problemen met DNS leiden daarom in veel gevallen tot een webapplicatie die nog wel beschikbaar, maar niet meer ‘vindbaar’ is. DNS maakt voor een groot gedeelte gebruik van het User Datagram Protocol (UDP). Vanuit het oogpunt van beveiliging betekent dit dat DNS vatbaar is voor zaken als hijacking en spoofing (een client die zich voordoet als een andere client). UDP maakt namelijk geen gebruik van de 3-way handshake van TCP (SYNSYN/ACK-ACK)6 waardoor geen sessie ontstaat tussen de client en de server. Hierdoor kan de afzender gebuik maken van ‘gespoofde’ bronadressen. De belangrijkste risico’s die zich kunnen voordoen bij de implementatie van DNSservices zijn hieronder kort beschreven:

6

Zie voor meer informatie over de TCP 3-way handshake:

http://www.cs.unc.edu/~jeffay/courses/nidsS05/attacks/schuba-ieee-secpriv97.pdf Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 15/116

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 zijn in principe bedoeld om primaire en secundaire DNS-servers gesynchroniseerd te houden. Wanneer willekeurige clients zone transfers kunnen uitvoeren richting de DNS-server, betekent dit dat iedereen alle informatie uit een zone kan 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 DoS-aanvallen. Wanneer de DNS-server een zeer groot aantal DNSverzoeken moet verwerken, kan dit ertoe leiden dat de DNS-server niet meer in staat is om te reageren op verzoeken. DNS cache poisoining; DNS cache poisoining kan zich voordoen op servers die naast de eigen authoritieve domeinen7 ook andere (nietauthoritieve) domeinen ondersteunen (caching servers). De kwetsbaarheid bestaat eruit 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 krijgt bij het DNSverzoek voor een bepaalde hostnaam. Het gevolg hiervan is dat de gebruiker verbinding maakt met een verkeerde webserver. Een kwaadwillende kan cache poisoining misbruiken om bijvoorbeeld phishingaanvallen uit te voeren.

ACHTERGROND Meer informatie over misbruik van DNS en de manieren waarop dit misbruik kan worden terug gedrongen kunt u ook vinden in het GOVCERT.NL whitepaper “DNS-misbruik: van herkenning tot preventie”. Dit whitepaper kunt u downloaden vanaf de Kennisbank van GOVCERT.NL

3.2.4

Kwetsbare firewall(configuratie)

Firewalls vormen een essentieel component in de beveiliging tegen aanvallen op webapplicaties. Door de belangrijke rol die een firewall vervult, is het ook gelijk een kwetsbaar element in de beveiligingsketen. 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 men 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 kan

7

Een authoritieve DNS-server is een DNS-server die volledige controle heeft over de inhoud van een zonefile

behorende bij het domein. Authoritieve servers voor een specifiek domein zijn via whois op te vragen – bijvoorbeeld door het commando ‘whois –h whois.sidn.nl govcert.nl’ uit te voeren op Linux-systemen (de authoritieve DNS-servers voor dit domein verschijnen onder de kop ‘Domain nameservers’). Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 16/116

men niet los zien van andere beveiligingsmaatregelen. • De firewall is geconfigureerd als router. Op een firewall kan men zoveel verbindingen toestaan als men maar wil. Door een rulebase8 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 innemen binnen een infrastructuur kan het op een gegeven moment gebeuren dat er zoveel verkeer door de firewall heen gaat 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. 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 welke verkeersstromen voor de specifieke webapplicatie door een firewall benodigd zijn. Het kan daardoor gebeuren dat het project meer verkeersstromen aanvraagt dan daadwerkelijk noodzakelijk is.

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 koppeling tussen het internet enerzijds en het interne netwerk anderzijds. 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.

8

De rulebase van een firewall beschrijft de verbindingen die een firewall toestaat. De rulebase bevat een lijst

met bronnen en doelen (IP-adressen) en toegestane poorten. Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 17/116

Een aantal verschillende overwegingen moeten als input dienen voor het ontwerp van de DMZ. Enkele belangrijke overwegingen die hierbij een rol kunnen spelen zijn: • • • • • • • • • • Welke verkeersstromen zijn benodigd? Gaan we compartimentering toepassen (zie 3.3.2)? Welke typen applicaties willen we via de DMZ ontsluiten? Welke ondersteunende applicaties (bijvoorbeeld databases) hebben we nodig voor het ontsluiten van deze applicaties? Hoe gaan we het verkeer richting deze applicaties door de DMZ routeren (zie 3.3.3)? Waar en hoe koppelen we de DMZ aan internet? Waar en hoe koppelen we de DMZ aan de backoffice? Moeten de webapplicaties ook toegankelijk zijn vanuit onze backoffice (zie 3.3.4)? Hoe regelen we het beheer van de DMZ in (welke protocollen, welke koppelingen, welke compartimenten, etc… - zie 3.3.5)? Gaan we een dual-vendor concept implementeren (zie 3.3.6)?

Figuur 3-2 beschrijft 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) hebben meegekregen. De komende paragrafen beschrijven deze verschillende onderdelen in meer detail.

Figuur 3-2: inrichting DMZ
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 18/116

3.3.2

Pas compartimentering toe

Rondom de firewall(s) in de DMZ kan men 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 web proxies in één segment, webservers voor internetsites in één segment, webservers voor extranetten in één segment, databases in één segment, etc… Door deze compartimentering toe te passen zorgt men ervoor dat compromittering van een server of applicatie in een compartiment geen directe gevolgen hoeft te hebben voor servers of applicaties in een ander compartiment. Daarnaast kan men via deze compartimentering onderscheid maken in servers die wel rechtstreeks vanaf internet bereikbaar zijn (bijvoorbeeld webservers) en servers die dat niet zijn (bijvoorbeeld directory servers). OPMERKING Voorkom te allen tijde dat webservers een rechtstreekse – ongefilterde - verbinding hebben met de backoffice. Webservers die in de backoffice geplaatst zijn, vormen een zeer ernstig beveiligingsrisico. Webservers dienen daarom altijd via minimaal één firewall gescheiden te zijn van de backoffice.

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 internetsite verloopt hierbij altijd via internet (rood), een proxy segment (rood/oranje), een tussensegment (oranje) en het websegment (groen). Verkeer richting een extranet volgt in grote lijnen dezelfde weg maar maakt vanaf het tussensegment (oranje) eerst nog een afslag richting een authenticatie- en autorisatiesegment (oranje/groen) alvorens bij de webserver te geraken. Door routepaden vast te stellen verzekert men zich ervan dat het omzeilen van verplichte beveiligingsmechanismen niet mogelijk is. Daarnaast beschrijft men op deze manier tevens een soort ‘template rulebase’ die de opzet van verkeersstromen bepaalt voor nieuwe webapplicaties.

3.3.4

Bepaal de toegang tot de webapplicaties vanuit de backoffice

Veel van de webapplicaties die een organisatie ondersteunt, moeten ook bereikbaar zijn vanaf het interne netwerk. Om deze koppeling tot stand te brengen heeft men de beschikking over grofweg twee alternatieven: • Routeer verkeer vanuit de backoffice via de internetkoppeling naar internet en vervolgens weer terug naar de eigen DMZ. Bij dit alternatief komt het erop neer dat men de webapplicaties vanuit de backoffice op eenzelfde manier benadert als alle andere webapplicaties op internet. Een argument dat tegen dit alternatief spreekt, is dat het onzinnig lijkt om
19/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

intern verkeer via het (externe) internet te routeren. • Routeer verkeer vanuit de backoffice rechtstreeks naar de webservers in de DMZ.

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 de backoffice 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 er 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.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

20/116

3.3.5

Scheid beheer- en productieverkeer

In het DMZ-ontwerp van figuur 3-2 is een onderscheid gemaakt tussen een ‘productie’-gedeelte (oranje lijnen) en een beheergedeelte (grijze lijnen/zwarte bolletjes). 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 heen gaan lopen. Beheer werkt vaak via webinterfaces en door beheer toe te staan via het productiegedeelte loopt men 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 men 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. Hiertoe bestaan verschillende mogelijkheden: • Implementeer beheerclients in het beheergedeelte die alleen te gebruiken zijn door er via 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 backoffice LAN. 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 in het backoffice LAN 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.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

21/116

3.3.6

Overweeg de invoering van een dual-vendor concept

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 kan men overwegen een dual-vendor concept te implementeren. Het dual-vendor 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 de backoffice. 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 voorkomt men dit. OPMERKING Het toepassen van een dual-vendor concept hoeft niet automatisch te betekenen dat men twee typen centrale firewalls in de omgeving plaatst. Dit concept kan men bijvoorbeeld ook invullen door, naast de centraal geplaatste firewalls, ook firewalls lokaal op de machines te installeren. Tools als ipfilter, ipfw en iptables bieden hiertoe mogelijkheden. Zie hoofdstuk 4 (“Platformbeveiliging”) voor meer informatie over dit type firewalls.

3.3.7

Behoud overzicht

Het is belangrijk dat beheerders overzicht behouden 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 daartoe ontwikkelde ‘verkeersoverzichten’ kunnen hieraan een bijdrage leveren. Een voorbeeld van een dergelijk verkeersoverzicht is weergegeven in figuur 3-4.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

22/116

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 tekent men de verkeersstromen tussen de componenten in. Hierdoor ontstaat een overzicht van de regels die op de firewalls benodigd 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 ideaal. 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 (in negatieve zin) 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 zijn aangesloten op dezelfde switch of hub waardoor een fysieke koppeling 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 fysieke (laag 2) koppelingen de logische (laag 3) segmentering te omzeilen, is in de praktijk vrij klein. Een kleine
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 23/116

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 kan men ook realiseren door (reverse) proxies inline te plaatsen. Dit betekent 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 SMTP-proxy voor e-mailverkeer, etc…). 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 applicatiebeveiliging (hoofdstuk 5). 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 whitepaper “Aanbevelingen ter bescherming tegen Denial-of-Serviceaanvallen” (DDoS-GOVCERT, 2005) beschrijft een aantal maatregelen die een organisatie kan treffen om zichzelf tegen (D)DoS-aanvallen te beschermen. De maatregelen die dit whitepaper voorstelt, zijn hieronder kort samengevat: • Maak gebruik van anti-spoofingmechanismen:

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

24/116

o

• • • • •

Unicast Reverse-Path Forwarding (uRPF); URPF controleert op een interface of een IP-pakket afkomstig is van een source IP-adres dat volgens de routeringstabel bereikbaar is via de betreffende interface. o Bogon lists; via bogon lists kan men IP-adressen die nog niet door IANA zijn uitgegeven blokkeren. o Access Control Lists (ACL); reguleren dataverkeer op basis van bijvoorbeeld IP-adres of poortnummer. Zet firewalls in. Harden systemen. Met name 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. Monitoor de infrastructuur zodat detectie van (D)DoS-aanvallen mogelijk is.

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 beveiling bij de inrichting van DNS-services voorop staat. Enkele aandachtspunten die van belang zijn bij het beveiligen van DNS: • Beperk de (bron) IP-adressen die zone transfers mogen uitvoeren met de DNS-server. Alleen primaire en secundaire DNS-servers zouden hiertoe gerechtigd mogen zijn. Sta via de firewall alleen verkeer toe richting 53/udp. Vrijwel alle DNSverzoeken maken gebruik van UDP. Alleen bij zeer grote verzoeken en zone transfers zal DNS overschakelen op het gebruik van TCP. Door 53/tcp te blokkeren in de firewall, voorkomt men dat willekeurige IP-adressen in staat zijn om zone transfers uit te voeren. Maak gebruik van meerdere authoritieve DNS-servers voor een zone. Verwijder onnodige records uit de zone. Onnodige records (bijvoorbeeld HINFO- en TXT-records) zijn niet benodigd en leveren een kwaadwillende alleen extra informatie.

• •

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 DNSservers. 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:

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

25/116

• •

• •

Sluit beheermogelijkheden zoveel mogelijk af. Biedt webinterfaces alleen aan via beheersegmenten. Maak alleen gebruik van versleutelde beheermechanismen. Maak dus bijvoorbeeld gebruik van Secure Shell (SSH) in plaats van Telnet en Secure Copy (SCP) in plaats van File Transfer Protocol (FTP). 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 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 appliances9 waarop weinig extra hardeningsmaatregelen mogelijk zijn. In de gevallen dat een netwerkcomponent echter niet gebaseerd is op een appliance, is het van belang dat men 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 aangeschakeld op netwerkcomponenten maar in veel gevallen niet benodigd 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 zijn 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: • • • On the Vulnerabilities and Protection of OSPF Routing Protocol (NCSU): http://www.cs.ucsb.edu/~rsg/Routing/references/wang98vulnerability.pdf Secure BGP Template (Cymru Team): http://www.cymru.com/Documents/secure-bgp-template.html Securing Cisco Routers (SANS/GIAC): http://www.giac.org/practical/GSEC/Nicholas_Vigil_GSEC.pdf
Een appliance is een deels voorgeconfigureerde machine met een specifieke functionaliteit (bijvoorbeeld

9

firewalling, routing, switching) en gelimiteerde toegang tot het besturingssysteem Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 26/116

• •

Secure IOS Configuration Template (Cymru Team): 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 de 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 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 richting 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. 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. DNSfunctionaliteit is een mechanisme om GSLB voor webapplicaties te bewerkstelligen. De ‘GSLB load balancer’ is hierbij autoritief voor de zone waarin de webapplicatie zich bevindt en fungeert voor deze zone als DNSserver. Door verzoeken voor de zone te beantwoorden met steeds wisselende IP-adressen komen gebruikers uit op de verschillende geografisch gescheiden locaties. Deze aanpak verschilt van de standaard Round Robin (RR) functionaliteit in DNS omdat GSLB rekening houdt met de load die een bepaalde locatie op dat moment ondervindt en de beschikbaarheid van deze locatie. Valt een geografische locatie bijvoorbeeld uit dan zal de ‘GSLB load balancer’ de bijbehorende IPadressen niet meer uitdelen. Bij gebruik van RR-DNS zal de DNS-server het IP-adres van de uitgevallen server gewoon blijven retourneren omdat de DNS-server geen middelen heeft om te achterhalen of de betreffende webserver nog bereikbaar is.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

27/116

Figuur 3-6: voorbeeldinrichting GSLB

In figuur 3-6 is een voorbeeld opgenomen van de inrichting van een GSLBoplossing. Hierbij is te zien dat de ‘GSLB load balancers’ status informatie over een locatie krijgen via lokale ‘LSLB load balancers’. Op basis van deze statusinformatie en polling-gegevens besluit de GSLB load balancer om een bepaald IP-adres te koppelen aan een DNS-verzoek van een client. Door de afhankelijkheid van GSLB-oplossingen van DNS kan dit in de praktijk tot problemen leiden. Zo gebruiken GSLB-oplossingen een zeer kleine Time-to-Live (TTL) voor DNS-records. De lengte van de TTL bepaalt hoe lang componenten (werkstations, DNS caching servers, etc…) opgevraagde DNS-informatie mogen bewaren. Internet Service Providers (ISP’s) kunnen ervoor kiezen om deze TTL te negeren en een standaard TTL van 24 uur aan te houden. In dit soort gevallen werkt de oplossing niet goed voor klanten die zijn aangesloten via deze provider omdat deze providers DNS-records minimaal 24 uur cachen. Hierdoor duurt het mogelijk 24 uur voordat een uitgevallen locatie niet meer wordt geadverteerd richting clients. Bij de keuze voor een GSLB-oplossing is het raadzaam voldoende aandacht te besteden aan deze factoren. 3.3.12.2 Voer centrale componenten redundant uit Centrale componenten in de infrastructuur kan men redundant uitvoeren zodat zij geen Single Point-of-Failure (SPOF) vormen. Veel netwerkcomponenten bieden standaard ondersteuning voor redundantie en bijbehorende statussynchronisatie.
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 28/116

Componenten (op netwerkniveau) die met name in aanmerking komen voor redundante uitvoering zijn: • • • • • • Communicatieverbindingen; Firewalls; Load balancers; Proxies; Routers; Switches.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

29/116

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 Server of Linux-/Unix-varianten. Dit hoofdstuk besteedt aandacht aan de kwetsbaarheden en bedreigingen die er bestaan op het gebied van platformen en zal tevens aanbevelingen doen ter voorkoming van deze kwetsbaarheden en bedreigingen.

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. Eventuele kwetsbaarheden die zich bevinden in het platform kunnen daarom direct de beveiliging van de webapplicatie in gevaar brengen.

4.2

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

4.2.1

Kwetsbaarheden in het OS

Leveranciers van besturingssystemen brengen met grote regelmaat patches uit voor nieuwe kwetsbaarheden. Niet alle kwetsbaarheden hebben direct gevolgen voor servers die in gebruik zijn door webapplicaties. Dit komt met name omdat 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 welke kwaadwillenden via de webserver kunnen misbruiken, dan kan dit ernstige gevolgen hebben voor alle webapplicaties die van deze server gebruik maken. Een buffer overflow is een specifieke kwetsbaarheid. Buffer overflows in het platform kunnen ertoe leiden dat kwaadwillenden willekeurige code uitvoeren op de webserver wanneer de betreffende kwetsbare service bereikbaar is vanaf het internet. In sommige gevallen biedt een buffer overflow alleen mogelijkheden om de kwetsbare service te laten crashen. Het probleem bij een buffer 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. Hierdoor overschrijft het programma mogelijke andere buffers en data van andere programma’s.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

30/116

ACHTERGROND Een buffer overflow op het platform kan met name 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 kan men denken aan een kwetsbaarheid in de implementatie van TCP/IP. Uit een onderzoek van beveiligingsbedrijf Internet Security Systems (ISS) blijkt dat de tijd die men heeft om bekende beveiligingslekken te patchen steeds verder afneemt. 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 exploitcode10 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 tot uitbuiting.

4.2.2

Onveilig ingerichte beheermechanismen

Het beheer van server in de hosting omgeving kan op verschillende manieren plaatsvinden. Enkele van de meest gebruikte beheermechanismen zijn: • Consoleverbindingen; een consoleverbinding kan men normaal gesproken alleen benaderen wanneer men een fysieke verbinding met de server of het component kan opzetten. Hiervoor dient men dan ook fysieke toegang te hebben tot de ruimte waarin de server zich bevindt. Ten behoeve van beheer kan men consoleverbindingen ook via het netwerk beschikbaar stellen. In dit geval sluit men de consoleverbindingen aan op een netwerk-enabled component. Door een Telnet-verbinding op te zetten met een dergelijk component kan men een consoleverbinding via het netwerk benaderen. Telnet; via telnet kan men een command-line sessie openen met een machine. Telnet is een redelijk gedateerd mechanisme dat vanwege beveiligingsredenen steeds minder vaak wordt toegepast. Secure Shell (SSH); via een SSH-verbinding kan men een veilige (versleutelde) verbinding opzetten tussen een client en een server. Optioneel kan men gebruik maken van certificaten om wederzijdse authenticatie te laten plaatsvinden. Via SSH kan men een command-line sessie openen met een server. Het is echter ook mogelijk om andere functionaliteiten (zoals het kopiëren van bestanden via Secure Copy) via een SSH-verbinding te tunnelen. File Transfer Protocol (FTP); via FTP kan men 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

10

Programmacode waarmee men een bekende kwetsbaarheid kan misbruiken 31/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

onveilig is. • Webinterface; veel systemen bieden tegenwoordig een webinterface via welke men de belangrijkste beheeractiviteiten kan uitvoeren. Een dergelijke webinterface kan gebruik maken van bestaande beveiligingsmechanismen op dit gebied zoals versleuteling via SSL, authenticatie op basis van X.509-certificaten, etc… Hoewel webinterfaces dus mogelijkheden bieden tot veilige inrichting hoeft dit niet per definitie te gebeuren. Wanneer men onvoldoende aandacht besteed aan het gebruik van veilige mechanismen rondom een webinterface kan een onveilige situatie ontstaan.

Afhankelijk van de inrichting van de infrastructuur rondom de hostingomgeving (zie hoofdstuk 3) kan het gebruik van bepaalde beheermechanismen een beveiligingsrisico met zich meebrengen. Het gaat hier met name om beheermechanismen die geen gebruik maken van versleutelingen en die gebruikersnamen en wachtwoorden in cleartext over het netwerk versturen. Wanneer men dergelijke beheermechanismen toestaat over het internet, bestaat de kans dat kwaadwillenden deze authenticatiegegevens onderscheppen. Figuur 4-1 geeft een voorbeeld van de informatie (gebruikersnaam ‘anonymous’ en wachtwoord ‘a@b.nl’) 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, bestandssysteem, register, etc… zoveel mogelijk in te perken. Op het moment dat dit niet gebeurt, kunnen onveilige situaties ontstaan. Besturingssystemen bieden op verschillende manieren mogelijkheden om rechten te koppelen aan processen. Dit doet men door een proces onder een bepaald ‘serviceaccount’ te laten draaien. Daarnaast biedt een besturingssysteem altijd de mogelijkheid om rechten te koppelen aan bestanden, directories, etc… Richt men
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 32/116

de rechten op een webserver niet op een juiste manier in dan kunnen een groot aantal problemen ontstaan; 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. Wanneer 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’, etc..), 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. Dit is zo ontstaan tijdens de ontwikkeling van de webapplicatie. Er blijkt zich echter een SQL injection kwetsbaarheid in de webapplicatie te bevinden. Deze SQL injection 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

Sommige van de services die standaard bij een installatie van een platform actief zijn, hoeft men niet per se nodig te hebben. 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 men bijvoorbeeld niet verwachtte dat deze service werd geïnstalleerd), ontstaat een belangrijke bron van beveiligingsproblemen.

4.3

Aanbevelingen Alle aanbevelingen uit deze paragraaf kan men scharen onder de noemer ‘hardening van het OS’. Hardening houdt in dat men het besturingssysteem zodanig inricht dat dit systeem beter bestand is tegen aanvallen van kwaadwillenden. De technische stappen die benodigd zijn om een
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 33/116

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 van hoe deze stap er op een specifiek type besturingssysteem uit zou kunnen zien.

4.3.1

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 dient te gaan met updates: hoe snel implementeert de organisatie een kritieke patch, welke stadia moet de patch doorlopen, wie draagt ervoor de verantwoordelijkheid, etc...? 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 Linux-systemen kennen standaard updatemechanismen. Hierbij kan men denken aan toepassingen als apt-get (Debian), up2date (Red Hat), MandrakeUpdate (Mandriva), YaST (SUSE) en yum (Fedora). Grofweg bestaat een juist ingericht patch management proces uit de volgende onderdelen: • Stap 1: vaststellen dat een patch beschikbaar is gekomen. Voordat de 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 gekomen. Hiertoe kan de organisatie monitoringprocessen inregelen voor de meest gebruikte technologieën. 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. Mogelijk is de kwetsbaarheid technisch gezien vrij ernstig maar bestaan er, gezien de inrichting van de infrastructuur van de organisatie, verzachtende omstandigheden waardoor de kwetsbaarheid voor de organisatie minder ernstig is. 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. De organisatie zal de patch moeten ophalen bij de leverancier ervan. Tegenwoordig verloopt dat in alle gevallen via internet.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

34/116

Stap 4: test de patch in een test- 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 test- en acceptatieomgeving is gebleken dat de patch geen negatieve effecten heeft, kan men besluiten om de patch uit te rollen op alle productieservers. Stap 6: monitoor eventuele 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.

4.3.2

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 komt men tot een minimale lijst van services die het betreffende systeem dient te ondersteunen. Alle overige services kan men óf uitschakelen óf 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 booten 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 kan men de configuratie ook aanpassen.

Bedenk dat niet-actieve maar wel aanwezige services op een systeem uiteindelijk toch tot een kwetsbaar systeem kunnen leiden aangezien ‘lekke’ programmacode
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 35/116

op het systeem aanwezig is. Veiliger is het daarom om onnodige services volledig van het systeem te verwijderen. 4.3.3 Richt access controls strikt in

Het beperken van rechten op een systeem voorkomt misbruik van dit systeem. De manier waarop het systeem deze rechtenbeperking mogelijk maakt, hangt af van het gebruikte 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 voorkomt men 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. • 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 voorkomt men dit. Sticky bits kan men daarom toepassen om de toegang tot het bestandssysteem verder in te perken. • 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: wanneer een gebruiker (of proces) een bestand met een ‘u’attribuut verwijdert, slaat het besturingssysteem de inhoud van dit bestand op. Hierdoor biedt het besturingssysteem de mogelijkheid om de verwijdering van een bestand later ongedaan te maken. • Bovenstaande punten hadden allen 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
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 36/116

administreren van deze rechten is lcap. 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) inregelen.

4.3.4

Harden de implementatie van essentiële protocollen

Door essentiële protocollen op een server te hardenen, voorkomt men misbruik van deze protocollen en verhoogt men de stabiliteit van het systeem. Dit kan ervoor zorgen dat een eventuele kwetsbaarheid in een dergelijk protocol niet direct ernstige consequenties voor het systeem hoeft te hebben. Eén van de protocollen die zich uitstekend leent voor hardening is TCP/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. Voor elk type besturingssysteem bestaan mogelijkheden om de configuratie van de TCP/IPstack zodanig te veranderen dat deze beter bestand is tegen aanvallen. Het is aan te raden om goed uit te testen wat de gevolgen van deze veranderingen zijn, zodat geen ongewenste gevolgen voortvloeien uit deze wijzigingen. VOORBEELD De TCP/IP-stack van Windows Server 2003 is standaard ingericht voor het afhandelen van intranet verkeer. Wanneer 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 voert men door, door de inhoud van bepaalde registersleutels aan te passen. Deze wijzigingen hebben tot doel om: • • • • • Timeouts 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.

Zie voor meer informatie: http://support.microsoft.com/?kbid=324270 In webomgevingen leent HTTP zich ook voor hardening. Om bijvoorbeeld een Denial-of-Service-aanval op HTTP-niveau te voorkomen, kan men ervoor kiezen om de idle timeout van een HTTP-sessie te verkleinen en ‘session pooling’ tussen een eventuele application-level firewall (hoofdstuk 5) en webservers aan te schakelen. ‘Session pooling’ verhoogt de performance van HTTP door de kosten die gepaard gaan met het steeds opnieuw opbouwen van een HTTP-sessie te voorkomen. Zo kan een application-level firewall meerdere kleinere bestanden via
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 37/116

éé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.5 Maak gebruik van jailing

Een mechanisme dat voornamelijk bestaat op het Linux- en Unix-platform is jailing (sandboxing). Het is een zeer eenvoudige vorm van isolatie van een proces. 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, kan het proces niet buiten zijn root-directory treden. Dit mechanisme kan men bijvoorbeeld inzetten om de 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/article.pl?sid=04/05/24/1450203

Voordat men besluit om Apache in een ‘chrooted’-configuratie te laten werken is het belangrijk dat men op de hoogte is van eventuele problemen die dit met zich mee kan brengen. Zo moet men eventuele bibliotheken en executables waarvan Apache gebruik maakt, beschikbaar maken in de ‘chrooted’-omgeving. Om deze problemen zoveel mogelijk te voorkomen is ‘chroot’-functionaliteit ook ingebouwd in de ModSecurity application-level firewall (vanaf versie 1.6). Meer informatie over deze – nog experimentele – functionaliteit in ModSecurity vindt u hier: http://www.modsecurity.org/documentation/apache-internal-chroot.html 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, het beperken van de toegestane hoeveelheid CPU-cycles, etc… VOORBEELD Afscherming van processen kan zover gaan dat op een gegeven moment virtualisatie ontstaat. Toepassingen als VMware, QEMU, Xen en Microsoft Virtual Server bieden bijvoorbeeld de mogelijkheid om volledig autonome besturingssystemen naast elkaar te laten functioneren.

4.3.6

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. Enkele aanbevelingen zijn echter meer generiek van aard en zijn van toepassing op vrijwel alle besturingssystemen:

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

38/116

• •

• •

• •

Zorg ervoor dat het systeem niet toegankelijk is op basis van ‘anonieme’ accounts. 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 6 (‘Identiteiten toegangsbeheer’) voor meer informatie over dergelijke authenticatiemechanismen. Beperk de groepslidmaatschappen van gebruikers. Implementeer een strikte password policy. In een password policy legt men zaken vast als minimale passwordlengte, lengte van de passwordhistorie, complexiteit van het wachtwoord, account lockouts, etc… Verwijder ongebruikte accounts en standaard aanwezige accounts. Hernoem ‘bekende’ accounts (zoals bijvoorbeeld ‘administrator’).

4.3.7

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). Het gebruik van ‘backdoors’ moet absoluut uitgesloten zijn. Een backdoor voor beheer is bijvoorbeeld een beheer interface waarvoor geen authenticatie benodigd 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.8

Maak back-ups

Back-ups vormen een laatste redmiddel in het geval de integriteit of beschikbaarheid van systemen of applicaties is aangetast. Om dit laatste redmiddel te kunnen hanteren dient men de beschikking te hebben over recente back-ups van deze systemen. Nog beter is het wanneer deze back-ups onderdeel uitmaken van een Disaster Recovery Plan (DRP). Tevens is het van belang dat men regelmatig test of de gemaakte back-ups de mogelijkheid bieden om een verloren gegaan systeem opnieuw op te bouwen. Frequente (veelal dagelijkse) back-ups van systemen zorgen ervoor dat men beschikt over snapshots van het systeem op gezette tijden. Voor sommige dynamische componenten (zoals databases) is deze dagelijkse snapshot wellicht niet afdoende. Bij dergelijke componenten kan men overwegen om de transactielog van de database beschikbaar te stellen op een uitwijklocatie (‘remote journaling’). In het geval het component crasht, kan men 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.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

39/116

4.3.9

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. Veel besturingssystemen bieden de mogelijkheid tot het gebruik van een lokale firewall. 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. 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 en Windows Server 2003.

Lokale firewalls hebben als voordeel dat ze niet alleen op poortniveau controles kunnen uitvoeren maar ook procesniveau. Verder hebben lokale firewalls vaak meer inzicht in het verkeer dat zich richting de machine begeeft omdat op de machine zelf ontsleuteling van eventuele 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 met name 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.10

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

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

40/116

zetten die deze wijzigingen in kaart brengen en deze informatie beschikbaar te stellen aan “Monitoring, auditing en alerting” (hoofstuk 9) kan men deze wijzigingen adequaat monitoren. 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 auditen. Het is van belang dat men, bij toepassing hiervan, strikte auditregels opstelt aangezien anders de hoeveelheid auditdata extreme vormen kan aannemen.

4.3.11

Maak gebruik van beveiligingstemplates

Alle hardeningsmaatregelen die benodigd zijn voor servers kan een organisatie opnemen in beveiligingstemplates. Beveiligingstemplates kan men 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, database server, etc…). Probeer alle mogelijke hardeningsmaatregelen eerst uit in een representatieve testomgeving zodat zeker is dat het betreffende systeem zonder probleem zal blijven functioneren zodra de maatregelen zijn geëffectueerd. Beveiligingstemplates bestaan in ieder geval uit documenten die de hardening beschrijven. Scripts, images, configuratiebestanden, etc… kunnen deze templates vervolgens technisch ondersteunen. ACHTERGROND Er zijn op internet diverse handleidingen te vinden die men kan gebruiken bij het opstellen van beveiligingstemplates. Onderstaand vindt u een opsomming van enkele bruikbare stukken op dit gebied: • Windows Server 2003 Security Guide (Microsoft): http://www.microsoft.com/downloads/details.aspx?familyid=8a2643c1-06854d89-b655-521ea6c7b4db The Threats and Countermeasures Guide (Microsoft): http://www.microsoft.com/downloads/details.aspx?FamilyID=1b6acf93-147a4481-9346-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/

• •

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

41/116

5

APPLICATIEBEVEILIGING

5.1

Inleiding 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. Een applicatiefilter heeft kennis over het gebruikte protocol en kan bepalen of het gebruik van het protocol voldoet aan eerder opgestelde policies en syntaxis. Door applicatie filtering toe te passen kunnen applicaties er vanuit gaan dat de aangeboden applicatieaanvragen (requests) syntactisch correct zijn bevonden en zijn genormaliseerd.

5.2

Mogelijke kwetsbaarheden en bedreigingen Veel identieke beveiligingsproblemen keren terug in een groot aantal verschillende webapplicaties. Het “Open Web Application Security Project” (OWASP – www.owasp.org) heeft de 10 meest gemaakte (beveiligings-)problemen in webapplicaties samengevat in een top 10. Deze paragraaf geeft een overzicht de meest voorkomende kwetsbaarheden en bedreigingen op het gebied van webapplicaties. De problemen zoals geschetst in de “OWASP top 10” zijn in dit overzicht verwerkt. ACHTERGROND Een project genaamd ‘Common Weakness Enumeration’ (CWE) tracht een complete lijst van alle mogelijke kwetsbaarheden in software samen te stellen. Deze zeer uitgebreide lijst bevat, naast de kwetsbaarheden zoals beschreven in deze paragraaf, nog een groot aantal andere kwetsbaarheden. Hoewel de lijst niet specifiek is toegespitst op webapplicaties is het aardig om de lijst eens te doorlopen om meer inzicht te krijgen in de mogelijke problemen die zich in software kunnen voordoen. U kunt de lijst hier terug vinden: http://cve.mitre.org/cwe/

5.2.1

Ongevalideerde input

Het niet juist valideren van input blijkt één van de meest gemaakte fouten in webapplicaties. Webapplicaties moeten er per definitie vanuit gaan dat alle informatie die zij toegestuurd krijgen niet te vertrouwen is. Applicaties kunnen niet vertrouwen op eventuele controles die client-side scripts hebben uitgevoerd omdat deze scripts eenvoudig te omzeilen zijn. Het niet juist valideren van input van gebruikers ligt ten grondslag aan drie bekende webapplicatiekwetsbaarheden; Cross-Site Scripting (XSS), SQL injection en buffer overflows. Deze begrippen komen aan bod in de paragrafen 5.2.2, 5.2.3 en 5.2.4.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

42/116

5.2.2

Cross-Site Scripting (XSS)

Cross-Site scripting (XSS11) houdt in dat een kwaadwillende kwaadaardige code injecteert in een link die verwijst naar een vertrouwde website. Hiertoe moet de kwaadwillende de beschikking hebben over een alom vertrouwde website die mogelijkheden biedt tot XSS. In juni 2006 ondervond PayPal zulke XSS-problemen op zijn website. Het scenario dat kwaadwillenden konden gebruiken om deze kwetsbaarheid uit te buiten is gelijk aan dat van figuur 5-1. In figuur 5-1 is een legale, vertrouwde website opgenomen. Een gebruiker ontvangt via zijn e-mail een verzoek om verbinding met deze website te maken (bijvoorbeeld met als reden dat er een speciale reclame zou zijn). Wanneer de gebruiker de link volgt zal deze in eerste instantie wellicht niet achterdochtig worden: de gebruiker krijgt een volledig correcte SSLverbinding met de betreffende website en het inloggen verloopt zonder problemen. Echter, de kwaadwillende heeft in de URL een script verpakt dat wordt uitgevoerd zodra het slachtoffer verbinding heeft gemaakt met de vertrouwde website. Doordat de website parameters in de URL niet goed afhandelt, stuurt de webserver het script als opdracht terug naar het slachtoffer, waarna de client het aldaar uitvoert. Het script dat de kwaadwillende heeft geïnjecteerd, zorgt ervoor dat de client de inloggegevens van de gebruiker verstuurt naar een server van de kwaadwillende. Op deze manier kan deze kwaadwillende inloggegevens van een groot aantal gebruikers verzamelen en misbruiken.

Figuur 5-1: voorbeeld van Cross-Site Scripting (XSS)

11

Bij de introductie van dit begrip werd Cross-Site Scripting afgekort tot CSS. Aangezien dit tot verwarring kan

leiden met andere reeds bestaande begrippen (bijvoorbeeld Cascading Style Sheets) is besloten om Cross-Site Scripting af te korten tot XSS. Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 43/116

XSS is ook in andere varianten mogelijk. Denk bijvoorbeeld aan een forum waarop iedereen berichten kan plaatsen. Wanneer de applicatie geen goede inputvalidatie uitvoert, is het mogelijk dat XSS plaatsvindt via de inhoud van het forum. De kwaadwillende hoeft dan alleen een specifiek stukje code te injecteren in de inhoud van het forum. ACHTERGROND Een poging tot het uitvoeren van een XSS-aanval kan men in veel gevallen herkennen aan het sleutelwoord ‘script’ in een link; dit ziet er bijvoorbeeld als volgt uit: http://www.legalewebsite.nl/user.php?op= userinfo&uname=&ltscript&gtalert(document.cookie);</script> Hoewel XSS dus geen directe schade berokkent aan de webapplicatie, kan een kwaadwillende de verzamelde gegevens nadien wel misbruiken om zich ongeautoriseerde toegang te verschaffen tot de webapplicatie. De webapplicatie moet voorkomen dat dergelijk misbruik via de website mogelijk is.

5.2.3

SQL injection

SQL injection ontstaat, net als XSS, door onvoldoende controles op de invoer van gebruikersdata. De aanwezigheid van een SQL injection kwetsbaarheid betekent dat een gebruiker op het internet in staat is om de SQL-verzoeken die een webapplicatie verstuurt naar de database, te manipuleren. De gevolgen van deze kwetsbaarheid zijn in grote mate afhankelijk van de programmalogica. Mogelijke gevolgen zijn: • 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 zonder dat de organisatie dit opmerkt; Een kwaadwillende kan de volledige database ‘droppen’ waardoor alle informatie uit de database verloren gaat; Een kwaadwillende kan een eigen gebruikersaccount aanmaken zonder dat de organisatie dit opmerkt en dit account gebruiken om toegang tot de webapplicatie te verkrijgen en te behouden.

• • •

Bovenstaande gevolgen dienen slechts als voorbeeld. In de praktijk zijn de gevolgen van SQL injection vrijwel oneindig. In figuur 5-2 is een voorbeeld opgenomen van een SQL injection kwetsbaarheid die ertoe kan leiden dat een gebruiker zonder geldige gebruikersnaam en wachtwoord toch kan inloggen op de webapplicatie.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

44/116

Figuur 5-2: voorbeeld van SQL injection

Zoals het proces in figuur 5-2 weergeeft, vertrouwt de webapplicatie de invoer van de gebruiker zonder meer en verwerkt de webapplicatie deze input 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 = ‘<gebruikersnaamveld>’ 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 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’

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

45/116

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 injection).

5.2.4

Buffer overflows

Buffer overflows kunnen zich voordoen in elk stuk softwarecode. Een buffer overflow doet zich voor op het moment dat de 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 willekeurige code op het systeem; hierdoor kan een kwaadwillende in het ernstigste geval volledige controle over een server krijgen. Buffer overflows zijn niet altijd eenvoudig te ontdekken en daarnaast blijkt het vaak moeilijk om een gevonden buffer overflow te misbruiken. Van sommige ontdekte kwetsbaarheden publiceert de ontdekker Proof-of-Concept (PoC) code op internet waardoor de kans op uitbuiting plotseling sterk toeneemt. In sommige gevallen publiceert de ontdekker zelfs code waarmee een kwaadwillende de kwetsbaarheid in zijn volledigheid kan uitbuiten (exploit). ACHTERGROND Proof-of-Concept (PoC) code bewijst dat een bepaalde kwetsbaarheid aanwezig is binnen software. Een PoC buit deze kwetsbaarheid echter niet maximaal uit. Een exploit doet dit wel. Een voorbeeld is een kwetsbaarheid in een browser waarbij men volledige controle kan krijgen over een kwetsbaar systeem. Een PoC bewijst dat de kwetsbaarheid aanwezig is door via de code de browser te laten crashen, de exploit biedt de mogelijkheid om ook daadwerkelijk controle over het kwetsbare systeem te krijgen. De code achter een PoC en een exploit kan vrijwel overeen komen.

5.2.5

Lekken van informatie

Webservers en webapplicaties kunnen op allerlei manieren informatie over zichzelf ‘lekken’. Deze informatie kan een kwaadwillende helpen om een goed beeld te krijgen van de omgeving waarin de webapplicatie zich bevindt. Op basis van de informatie kan de kwaadwillende bijvoorbeeld vaststellen dat de webapplicatie gebruik maakt van kwetsbare software. Het vervolg van deze paragraaf beschrijft enkele van de meest voorkomende vormen van lekken van informatie door webapplicaties.
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 46/116

5.2.5.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-3 toont een dergelijke foutmelding.

Figuur 5-3: voorbeeld van een verbale 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-injection kwetsbaarheid (5.2.3) bevat. De mogelijkheden die de kwaadwillende heeft zijn mogelijk redelijk beperkt als deze geen inzicht heeft in de opbouw van de code en de database. Wanneer de kwaadwillende er echter in slaagt om een foutmelding te forceren met daarin de beschrijving van een SQLverzoek dat mislukt, dan heeft deze op dat moment voldoende informatie om met andere (soortgelijke) SQL-verzoeken te gaan experimenteren. De kwaadwillende heeft op dat moment bijvoorbeeld kennis van attribuutnamen, tabelnamen, databasenamen, etc… OPMERKING Ook het ontstaan van foutmeldingen kan men deels wijten aan het onvoldoende controleren op input van gebruikers. Een foutmelding ontstaat namelijk in veel gevallen doordat er zich een uitzondering voordoet binnen de programmalogica. Deze uitzondering kan ontstaan uit het feit dat een verwachte verbinding richting een database niet beschikbaar is maar ook omdat de webapplicatie niet goed weet om te gaan met ‘afwijkende’ input’: de applicatie krijgt bijvoorbeeld een string te verwerken terwijl het een getal verwacht.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

47/116

5.2.5.2 Header-informatie HTTP-headers kunnen veel informatie verschaffen over de webapplicatie en de software waarvan de webapplicatie gebruik maakt. Eén van de bekendste HTTPheaders die informatie vrijgeeft is de “Server”-header. In veel gevallen zal de webserver via deze header informatie geven over het type webserver waarvandaan de pagina afkomstig is. In sommige gevallen bevat deze header echter nog veel meer informatie. Figuur 5-4 geeft een voorbeeld van een dergelijke header.

Figuur 5-4: voorbeeld van HTTP-header informatie

In figuur 5-4 is een voorbeeld opgenomen van een antwoord dat een webserver geeft n.a.v. het opvragen van een webpagina. Zoals in dit voorbeeld is te zien toont de webserver niet alleen de gebruikte webserver-versie (Apache/1.3.27 op Red Hat Linux) maar bijvoorbeeld ook de gebruikte versies van OpenSSL en PHP. Op basis van deze informatie kan een kwaadwillende zeer gerichte aanvallen uitvoeren op de webserver. Informatiebronnen als Secunia, de National Vulnerability Database (NVD) en SecurityFocus kunnen de kwaadwillende hierbij voorzien van de laatste kwetsbaarheden die bekend zijn met de gebruikte software. 5.2.5.3 Commentaarregels in scripts Commentaarregels in code kunnen ongewild informatie vrijgeven aan de eindgebruiker. Met name HTML-code en client-side scripts (zoals Javascript) kunnen dit commentaar bevatten. 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-5 geeft een zeer eenvoudig voorbeeld van commentaar in Javascript - in een inlogpagina - dat een kwaadwillende kan lezen en mogelijk misbruiken.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

48/116

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

5.2.6

Onveilige opslag van informatie

Een webapplicatie maakt vaak gebruik van grote hoeveelheden informatie. Van belang is op welke manier de webapplicatie deze informatie opslaat. Technisch gezien kan de webapplicatie voor opslag van gegevens gebruik maken van lokale bestanden op de webserver en databases. Vaak vindt de opslag van gegevens onversleuteld plaats. Dit kan ernstige gevolgen hebben wanneer een kwaadwillende erin slaagt om deze gegevens te benaderen. Onderstaand volgen twee voorbeelden van situaties waarin de onversleutelde opslag van gegevens tot problemen leidt. Voorbeeld #1: opslag van adresgegevens in een lokaal tekstbestand Een webapplicatie verzamelt adresgegevens van particulieren. De organisatie gebruikt deze gegevens om abonnees per post een nieuwsbrief te versturen. Zodra een gebruiker zijn gegevens invult op een webpagina slaat de webapplicatie de gegevens op in het bestand ‘/webapp/abonnees.txt’. De ontwikkelaar ging ervan uit dat deze gegevens hier veilig stonden omdat de webapplicatie draait vanuit ‘/webapp/wwwroot/’ (webroot). Een kwaadwillende vindt echter een fout in een script binnen de webapplicatie waardoor deze erin slaagt buiten de webroot te treden. Het volgende verzoek naar de webapplicatie levert de kwaadwillende de inhoud van het bestand op: http://www.eenwebsite.nl/showfile.php?file=%2Fwebapp%2Fabonnees.txt Hoewel het onversleutelde bestand normaal gesproken niet via internet te bekijken is, zorgt de kwetsbaarheid in een script (showfile.php) binnen de webapplicatie ervoor dat het bestand toch te benaderen en te lezen is.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

49/116

Voorbeeld #2: opslag van inloggegevens in een database Een webapplicatie slaat gebruikersnamen en wachtwoorden onversleuteld op in een database. Dit leidt normaal gesproken niet tot problemen aangezien de webapplicatie de inhoud van deze tabel op geen enkele manier toont. Een kwaadwillende vindt echter een SQL-injection kwetsbaarheid in de webapplicatie. Via deze kwetsbaarheid kan hij een SQL-verzoek richting de database versturen die alle gebruikersnamen en wachtwoorden van gebruikers toont. Ook wanneer de webapplicatie gegevens wel versleuteld opslaat hoeft dit niet per definitie te betekenen dat dit veilig is. Veel is afhankelijk van het gebruikte algoritme voor versleuteling van gegevens. Kiest men bijvoorbeeld voor een zeer zwak algoritme of een algoritme dat men zelf bedacht heeft, dan is de kans aanwezig dat een kwaadwillende dit algoritme in korte tijd kraakt.

5.2.7

Onveilige configuratie

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 een aantal verschillende beveiligingsproblemen voordoen. Enkele voorbeelden hiervan: • 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 kan men gebruik maken van standaard aanwezige gebruikersnamen en wachtwoorden. Richt men 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 men deze standaard gebruikersnamen en wachtwoorden niet wijzigt, kan een kwaadwillende zich mogelijk met deze gegevens toegang verschaffen tot databases en andere applicaties. VOORBEELD Van veel producten publiceert men bekende gebruikersnamen en wachtwoorden op internet. 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.de/dpl/dpl.html

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

50/116

Aanwezigheid van standaard plug-ins; een ‘kaal’ geïnstalleerde webserver kent over het algemeen al een aantal plug-ins die functionaliteiten binnen de webserver ondersteunen. 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, maar dat geen aandacht is besteed aan de beveiliging ervan. Hierdoor kan een mogelijk beveiligingslek ontstaan. Ontbreken van patches; wanneer men een applicatieplatform installeert vanaf een medium (bijvoorbeeld CD-ROM) is de kans aanwezig dat op dit medium nog niet de laatste patches voor het applicatieplatform zijn geplaatst. Wanneer men vergeet om deze patches na installatie van de webserver te downloaden en te installeren, bevat de applicatie ongedichte lekken. Het spreekt voor zich dat kwaadwillenden deze lekken kunnen misbruiken om zich toegang te verschaffen tot de webserver of webapplicatie. Aangeschakelde ‘debugging’-opties; sommige applicatieplatformen ondersteunen standaard een aantal ‘debugging’-opties. Debugging is bedoeld om het aantal bugs (fouten) in een applicatie te verminderen door duidelijke foutmeldingen te genereren in het geval zich een probleem voordoet. Deze foutmeldingen kan een kwaadwillende in zijn voordeel gebruiken (zie 5.2.5.1).

5.2.8

Kwetsbare aangekochte applicaties

Bij het nemen van beveiligmaatregelen rondom webapplicaties bestaat de kans dat de focus voornamelijk gericht is op intern ontwikkelde applicaties. ‘Extern aangekochte applicaties zijn veilig’, neigt men soms te denken. Niets is minder waar. Ook extern aangekochte applicaties zullen kwetsbaarheden bevatten. En juist omdat deze externe aangekochte applicaties in gebruik zijn door meer klanten is de kans groter dat kwaadwillenden hun pijlen op deze applicaties richten en bijvoorbeeld exploits voor deze producten publiceren. Producten waar men in dit verband aan kan denken zijn bijvoorbeeld Content Management Systemen (CMS), fora, PHP-bibliotheken en webmail-applicaties. VOORBEELD In beveilgingsadvies 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 XSSkwetsbaarheid) 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 B).

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

51/116

5.3

Aanbevelingen Deze paragraaf beschrijft aanbevelingen op het gebied van applicatiebeveiliging. De paragraaf start met een beschrijving van het begrip ‘application-level firewall’. Daarop volgen een groot aantal aanbevelingen die men zowel losstaand als via een application-level firewall kan implementeren.

5.3.1

Overweeg de invoering van een application-level firewall

Een application-level firewall heeft specifieke kennis van een bepaald protocol. In het geval van webapplicaties dient de application-level firewall diepgaande kennis te hebben van het HTTP-protocol. Daarnaast is ook kennis van de payloads van HTTP-berichten (XML in het geval van webservices) van belang. Een applicationlevel firewall kan een zeer sterke beveiliging bieden tegen zowel bekende als nietbekende aanvallen die gericht zijn op webapplicaties. 5.3.1.1 Wat is een application-level firewall? Een application-level firewall bevindt zich tussen een client en een server een maakt in de meeste gevallen gebruik van applicatie-proxies. Deze applicatieproxies zetten, voor de totstandkoming van een verbinding tussen client en server, aparte sessies op met de client en met de server. Op deze manier kunnen de applicatie-proxies al het verkeer dat client en server met elkaar uitwisselen inspecteren en op deze manier verdacht verkeer tegen houden. Een applicatieproxy heeft specifieke kennis van een bepaald protocol. Wanneer men spreekt over een application-level firewall die ingezet wordt voor de beveiliging van webapplicaties (een web application-level firewall) dan betekent dit dat de firewall gebruik maakt van applicatie-proxies die specifieke kennis hebben van HTTP en aanverwante protocollen en standaarden (bijvoorbeeld HTML en XML). 5.3.1.2 Plaatsing van de application-level firewall Een application-level firewall kan men op verschillende manieren inpassen in de DMZ-infrastructuur. Binnen de infrastructuur fungeert de application-level firewall als een reverse proxy. Dit betekent dat de application-level firewall alle verbindingen vanaf een client richting een webapplicatie afhandelt en dat de reverse proxy (de application-level firewall) zélf een verbinding opzet met de achterliggende webapplicatie. Dit is dus precies een omgekeerde (reverse) werking van een ‘normale’ proxy waarbij de proxy intern verkeer naar externe servers verstuurt. Figuur 5-6 geeft een overzicht van mogelijke manieren waarop men de application-level firewall in de DMZ van hoofdstuk 3 kan plaatsen.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

52/116

Figuur 5-6: plaats van de application-level firewall

Bij de oplossingen (a), (b) en (c) uit figuur 5-6 is de application-level firewall een losstaand netwerkcomponent binnen de DMZ-infrastructuur. Er bestaan echter ook een aantal oplossingen die niet als losstaand netwerkcomponent maar als plug-in op de webserver fungeren. Deze situatie is weergegeven in optie (d) in figuur 5-6.

5.3.1.3 Functionaliteiten De functionaliteiten die application-level firewalls bieden, verschillen van leverancier tot leverancier. Er zijn echter een aantal functionaliteiten die in veel producten terugkeren: • Caching: het tijdelijk cachen van opgevraagde content (zoals bijvoorbeeld plaatjes) teneinde de load op de achterliggende webservers te verminderen. Beheer via een eigen grafische gebruikersinterface; veel applicationlevel firewalls komen in de vorm van een appliance en zijn via een (HTTP-) gebruikersinterface te beheren. Redirecten van gebruikers afhankelijk van de gekozen URL; een application-level firewall kan gebruikersverzoeken doorsturen naar verschillende achterliggende webservers. De keuze baseert de applicationlevel firewall hierbij op de gebruikte URL. Op deze manier is het mogelijk dat de inhoud van één website afkomstig is van verschillende

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

53/116

achterliggende webservers. • Uitvoeren van inputvalidatie (zie 5.3.2): deze inputvalidatie betreft validatie van gebruikte URL’s, inhoud van invoervelden, inhoud van XMLberichten, inhoud van parameters, grootte van het bericht, etc… Terminatie van SSL-verbindingen (zie 5.3.3); omdat de applicationlevel firewall fungeert als proxy termineert deze SSL-verbindingen. Dit houdt in dat de application-level firewall sites authenticeert middels server-side SSL-certificaten en daarnaast gebruikersauthenticatie middels client-side SSL-certificaten kan toepassen. Controle van digitale handtekeningen (hoofdstuk 6); wanneer op basis van standaard protocollen digitale handtekeningen op uitgewisselde informatie zijn geïmplementeerd, kan de application-level firewall deze handtekeningen controleren en verkeer alleen accepteren wanneer de digitale handtekening in orde blijkt te zijn. Deze functionaliteit is voornamelijk aanwezig bij het gebruik van webservices. Bescherming tegen lekken van informatie (zie 5.3.5); door de uitgebreide controles die de application-level firewall kan uitvoeren op de verschillende onderdelen van een HTTP-antwoord, kan deze gevoelige informatie uit het antwoord filteren en een gefilterd antwoord retourneren aan de gebruiker. Normaliseren van HTTP-verzoeken (zie 5.3.6); voordat een applicationlevel firewall een HTTP-verzoek valideert, zal deze het verzoek eerst normaliseren. Hierdoor voorkomt men dat kwaadwillenden via geëncodeerde karakters e.d. beveiligingsmechanismen omzeilen. Controle tegen bekende aanvalspatronen (zie 5.3.7); als laatste ‘redmiddel’ kan een application-level firewall een verzoek controleren op bekende aanvalspatronen. Wanneer een HTTP-verzoek overeen komt met een bekend patroon (bijvoorbeeld een bekend verzoek van een worm) dan kan de application-level firewall dit verzoek blokkeren. Controle op HTTP-methoden (zie 5.3.8); hoewel HTTP vanuit de RFC ondersteuning biedt voor een groot aantal verschillende HTTP-methoden, gebruiken webapplicaties in de praktijk slechts twee van deze methoden veelvuldig: GET en POST. De application-level firewall kan mogelijk onveilige HTTP-methoden blokkeren. Controle op gebruikte HTTP-headers (zie 5.3.10); zowel HTTPverzoeken als HTTP-antwoorden kunnen beveiligingsproblemen opleveren wanneer deze speciale HTTP-headers bevatten. Een application-level firewall kan diepgaande filtering op deze headers toepassen.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

54/116

Voorkomen misbruik van cookies (zie 5.3.11); webapplicaties maken vaak gebruik van cookies om statusinformatie op te slaan. Misbruik van deze cookies kan leiden tot het omzeilen van authenticatie- en autorisatiemechanismen of inbreuk op de integriteit van gegevens. Door controles uit te voeren op uitgewisselde cookies, voorkomt men dat kwaadwillenden misbruik maken van dit cookiemechanisme. Detectie van brute force aanvallen.

5.3.1.4 Interne architectuur van een application-level firewall Een belangrijke eigenschap van een application-level firewall is of deze een positief of negatief beveiligingsbeleid implementeert. Een positief beveiligingsbeleid is een beveiligingsbeleid waarbij de application-level firewall alle verzoeken blokkeert, tenzij expliciet toegestaan. Bij een negatief beveiligingsbeleid blokkeert de application-level firewall helemaal niets, tenzij expliciet verboden. Application-level firewalls die een positief beveiligingsbeleid hanteren (of in ieder geval daartoe de mogelijkheid bieden) krijgen vanuit het oogpunt van beveiliging de voorkeur boven application-level firewalls die een negatief beveiligingsbeleid implementeren. Een positief beveiligingsbeleid werkt met een syntax waaraan een HTTP-verzoek moet voldoen vanuit een vooropgestelde configuratie. De application-level firewall blokkeert verzoeken die niet aan deze syntax voldoen. Op deze manier is de kans klein dat kwaadwillenden nieuwe – onbekende – kwetsbaarheden kunnen uitbuiten. Een negatief beveiligingsbeleid werkt op basis van aanvalspatronen (handtekeningen van kwaadaardige verzoeken). Alleen wanneer een verzoek blijkt te matchen met een aanvalspatroon zal de application-level firewall dit verzoek blokkeren. Dit betekent in de praktijk dat de application-level firewall alleen bekende aanvallen richting de webapplicatie zal blokkeren. Veel application-level firewalls implementeren een positief beveiligingsbeleid en bieden de mogelijkheid om verzoeken die op basis van het positieve beveiligingsbeleid zijn toegestaan, als laatste controle ook nog eens tegen de verzameling van aanvalspatronen te houden (negatief beveiligingsbeleid). ACHTERGROND Application-level firewalls kennen veel benamingen. Het artikel “Web Application Firewalls Primer” (INSECURE, 2006) geeft een overzicht van 22 van deze benamingen. Enkele van de meest in het oogspringende zijn: Web Application Firewall, Application Level Gateway, Web Application Proxy, Web Intrusion Prevention System en Web Security Proxy. In dit document zullen we echter de term Application-level firewall hanteren. Een application-level firewall werkt, zoals al eerder werd beschreven, in veel gevallen als een reverse proxy. Dit betekent dat de client nooit een rechtstreekse verbinding kan opzetten met de webserver; zodra een client een webpagina opvraagt ontstaan in ieder geval twee verbindingen op IP-niveau: één tussen de client en de application-level firewall en één tussen de application-level firewall en de webserver. Een webserver logt normaliter bij alle verzoeken die het krijgt te verwerken ook het IP-adres van waaraf dit verzoek afkomstig is. In het geval men
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 55/116

gebruik maakt van een reverse proxy zal dit IP-adres dus altijd het IP-adres van de application-level firewall zijn via welke de client een verbinding krijgt. Omdat op deze manier waardevolle informatie verloren gaat, moet men een configuratiewijziging doorvoeren op zowel de appliction-level firewall als de webserver. Deze configuratiewijziging bestaat eruit dat de application-level firewall het originele IP-adres van de client doorstuurt in een aparte HTTP-header (bijvoorbeeld HTTP_ORIG_IP_ADDRESS) en de webserver niet het IP-adres van de application-level firewall in het requestlog plaatst, maar het IP-adres uit de eerder genoemde HTTP-header. 5.3.1.5 Voordelen Één van de belangrijkste voordelen van de inzet van een application-level firewall is dat deze bescherming kan bieden tegen bekende én nieuwe (0-day) kwetsbaarheden. Door uit te gaan van een positief beveiligingsbeleid zal de application-level firewall veel pogingen tot misbruik automatisch blokkeren, aangezien deze werken op basis van bijvoorbeeld een groot aantal karakters, vreemde karakters of speciale encodering. Op het moment dat leveranciers nieuwe kwetsbaarheden bekend maken en patches ter beschikking stellen is de noodzaak tot het installeren van deze patches wellicht iets minder dringend. Zolang de application-level firewall verzoeken blokkeert die de kwetsbaarheid uitbuiten, loopt de webserver/webapplicatie minder gevaar. Uiteraard is het nog steeds van belang om de patches uiteindelijk te installeren, alleen is de periode waarbinnen dit moet gebeuren mogelijk iets ruimer. Daarnaast kan de inzet van een application-level firewall met een zeer strikt positief beveiligingsbeleid, dwingen tot webapplicaties die voldoen aan strenge vereisten op het gebied van beveiliging. Een strikt positief beveiligingsbeleid zorgt er namelijk voor dat de application-level firewall veel verzoeken richting de applicatie blokkeert zodra ze gebruik maken van vreemde karakters, vreemde headers, lange strings, relatieve paden, etc… Op deze manier dwingt de application-level firewall ontwikkelaars ertoe goed na te denken over de opbouw van de applicatie. Uiteraard is het wel van belang dat systeemontwikkelaars op de hoogte zijn van het standaard beveiligingsbeleid zodat zij weten aan welke voorwaarden een webapplicatie moet voldoen om zonder problemen te kunnen functioneren achter de application-level firewall. OPMERKING Vrijwel alle application-level firewalls bieden mogelijkheden om aparte policies te definiëren op URL-basis. Dat betekent dat in theorie elke webapplicatie een apart beveiligingsbeleid kan hanteren. Dit kan echter leiden tot een onoverzichtelijk geheel waarin zich beveiligingsproblemen voordoen. Het is daarom aan te raden altijd te werken met een standaard positief beveiligingsbeleid en hier alleen in specifieke gevallen een uitzondering op te maken. 5.3.1.6 Voorbeelden Application-level firewalls zijn in steeds grotere getale beschikbaar. Onderstaand volgt – in alfabetische volgorde - een overzicht van enkele producten die veel van de functionaliteiten uit dit hoofdstuk implementeren. Het bestuderen van
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 56/116

informatie over deze producten kan bijdragen aan de kennisvorming over de producten en de mogelijkheden ervan. Er is bij het overzicht onderscheid gemaakt tussen application-level firewalls die zich voornamelijk richten op het controleren van HTTP/HTML-verkeer en application-level firewalls die zich voornamelijk richten op XML-verkeer (webservices): HTML • CheckPoint Application Intelligence (beperkte functionaliteiten); • Citrix/Teros Secure Application Gateway; • eEye SecureIIS (Microsoft IIS plug-in); • F5 Trafficshield; • Imperva SecureSphere; • Microsoft Internet Security and Acceleration Server (ISA); • Kavado Defiance; • ModSecurity (Open Source Web Application Firewall); • Netcontinuum Web Application Firewall; • Sentryware HIVE; • TUNIX/Webguard; • Watchfire/Sanctum Appshield. XML • Datapower; • Reactivity XML Security Gateway; • Vordel VordelSecure; • Xtradyne Web Services Domain Boundary. Een speciale soort application-level firewall is een SSL-VPN appliance. Via een SSL-VPN ontsluit men interne applicaties via een SSL-interface. Op deze manier kunnen medewerkers van een organisatie bijvoorbeeld bestanden bekijken, e-mail raadplegen, verbinding maken met een Citrix-server, verbinding maken met een SSH-service, etc… via een webinterface. SSL-VPN appliances lenen zich met name voor toepassing in thuiswerken en extranetten. Een SSL-VPN biedt ook mogelijkheden om policies toe te passen op het verkeer dat eindgebruiker en interne server met elkaar uitwisselen. 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.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

57/116

ACHTERGROND Het Web Application Security Consortium (WebAppSec) biedt organisaties die de inzet van een application-level firewall 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 web application firewall voor een organisatie. Het document kunt u downloaden vanaf http://www.webappsec.org/projects/wafec/

5.3.2

Voer inputvalidatie uit

Inputvalidatie is essentieel voor het afdoende kunnen beschermen van een webapplicatie tegen een verscheidenheid aan aanvallen. Cross-site scripting (5.2.2) en SQL injection (5.2.3) zijn bekende aanvallen die misbruik maken van het ontbreken van gedegen inputvalidatie. Inputvalidatie moet plaatsvinden op alle onderdelen van een HTTP-verzoek. Voordat inputvalidatie plaatsvindt op een verzoek is het van belang dat het verzoek eerst genormaliseerd is (zie 5.3.6). Bij inputvalidatie kan men denken aan de volgende maatregelen: • Controle op lengte en type van invoer. Wanneer bijvoorbeeld maximaal 20 karakters in een variabele passen moet de applicatie controleren of de gebruiker niet meer dan 20 karakters heeft ingevuld. Hierdoor voorkomt men bijvoorbeeld buffer overflows. Controle op karakters. De applicatie moet elke invoer controleren op de aanwezigheid van speciale karakters. Bij SQL injection maken kwaadwillenden bijvoorbeeld veel gebruik van quotes (‘) en dubbele mintekens (‘--‘) om SQL-commando’s te kunnen injecteren. Deze karakters horen veelal niet thuis in reguliere invoer en dient de applicatie daarom uit te filteren. Controle op sleutelwoorden. Door invoer te controleren op de aanwezigheid van specifieke sleutelwoorden voorkomt men veel gebruikte aanvallen. Sleutelwoorden als ‘<script>’, ‘DELETE FROM’, ‘SELECT’, ‘INSERT’ en ‘DROP’ horen niet thuis in invoervelden, waardoor de applicatie verzoeken waarin deze sleutelwoorden voorkomen vaak zonder problemen kan blokkeren. Controle op lengte en type van attachments. Sommige websites bieden de mogelijkheid om bestanden te uploaden. Denk hierbij aan online fotoalbums e.d. Belangrijk is in dit geval te controleren of het type attachment overeenkomt met het verwachte type (bijvoorbeeld JPG) en of de grootte van het attachment geen grenzen overschrijdt. Hierdoor voorkomt men dat bestanden van enkele honderden megabytes de schijven van de webserver laten vollopen en extreem veel resources (bandbreedte, CPU, etc…) gebruiken.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

58/116

Controle tegen een vooropgesteld XML-template. XML-berichten die men uitwisselt via webservices zijn vrijwel altijd gebaseerd op XMLtemplates. Deze XML-templates nemen vaak de vorm aan van een Web Service Description Language (WSDL) bestand. Het WSDL-bestand beschrijft welke namespaces de webservice gebruikt, welke methoden de webservice ondersteunt, welke attributen de webservice verwacht (of verplicht stelt) en hoe deze attributen moeten zijn opgebouwd. Door een aangeboden XML-bericht te controleren tegen het XML-template, kan men vaststellen of het XML-bericht voldoet aan datgene wat de webapplicatie verwacht. Afwijkingen van het XML-template duiden mogelijk op een poging tot misbruik. Figuur 5-7 geeft een voorbeeld van een definitie uit een WSDL-bestand. In dit voorbeeld is te zien dat de WSDL beschrijft welke data-typen de applicatie verwacht en hoe vaak een bepaald type moet en mag voorkomen in een ‘sequence’.

Figuur 5-7: definitie uit een WSDL-bestand

Alle bovenstaande controles dient men uit te voeren op alle onderdelen van het HTTP-bericht. Hiertoe dient de applicatie het HTTP-bericht volledig te ontleden en elk onderdeel apart te evalueren. Figuur 5-8 geeft een voorbeeld van een HTTPverzoek vanaf een client met daarin de onderdelen waarop de applicatie controles kan uitvoeren.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

59/116

Figuur 5-8: onderdelen van een HTTP-verzoek

Inputvalidatie past men in sommige gevallen al toe op de client. Zo kan men bijvoorbeeld in webformulieren een maximale lengte van het invoerveld bepalen (via het MAXLENGTH attribuut). Deze controles aan de clientkant voorkomen dat reguliere gebruikers verkeerde invoer versturen. Het voorkomt echter niet dat kwaadwillenden verkeerde invoer versturen. Het is immers eenvoudig om de beperkingen van een formulier te omzeilen door buiten de webbrowser om een verzoek richting de webapplicatie te versturen. Inputvalidatie via de browser kan dus helpen om de invoer van een reguliere gebruiker te sturen maar mag nooit als beveiligingsmiddel dienen. OPMERKING Naast inputvalidatie (wat krijgen we binnen?) is ook outputvalidatie (wat sturen we terug?) van belang. Paragraaf 5.3.4 gaat hiertoe met name in op de vraag hoe de applicatie kan voorkomen dat deze onbedoeld informatie ontsluit richting clients.

5.3.3

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 middels SSL of TLS voorkomt men dat kwaadwillenden eenvoudig de verkeersstromen tussen client en server kunnen inzien. Men moet zich 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 dient men aparte maatregelen te treffen (zie 5.3.12).
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 60/116

Bij de inzet van een application-level firewall handelt niet de webserver maar de application-level firewall de SSL-verbinding af. Zodra de SSL-verbinding tot stand is gekomen, zal de application-level firewall de verbinding doorproxien naar de achterliggende webserver. De verbinding tussen de application-level firewall en de achterliggende webserver hoeft niet per definitie op basis van SSL of TLS te worden gerealiseerd. Aangezien deze laatste verbinding zich vrijwel altijd in een vertrouwde en afgeschermde omgeving bevindt (de DMZ van de organisatie), kan men 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 verkeer te laten bekijken door eventueel 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 application-level firewall in combinatie met een HTTP-verbinding tussen de application-level firewall en de webapplicatie plotseling wel. Zie hoofdstuk 9 voor meer informatie over de inzet van een IDS. Figuur 5-9 illustreert het hierboven beschreven concept.

Figuur 5-9: SSL/TLS naar HTTP-omzetting op de application-level firewall

Als een application-level firewall de SSL-verbinding termineert en op basis van HTTP richting de achterliggende webservers communiceert (zoals in figuur 5-9), betekent dit wel dat de achterliggende webservers niet de beschikking krijgen over de SSL-authenticatieinformatie in het geval de application-level firewall het gebruik van clientcertificaten heeft afgedwongen. Mocht de webapplicatie deze informatie wel nodig hebben, dan kan de application-level firewall deze informatie veelal doorgeven via (door de application-level firewall) ingevoegde HTTP-headers of toegevoegde parameters bij een URL-aanroep. Dit is een functionaliteit die de aandacht krijgt in de laag beveiligingsintegratie (hoofdstuk 8).

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

61/116

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 kan men 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 accelarators voor verschillende webapplicaties niet mogelijk is. Bij gebruik van SSL heeft men de keuze tussen verschillende versleutelingsprotocollen voor (1) het uitwisselen van sleutels, (2) het authenticeren van gebruiker en 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 SSLbeveiliging breken. VOORBEELD Apache, een bekende 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.

5.3.4

Voorkom het lekken van informatie

Het lekken van informatie richting een kwaadwillende moet men zoveel mogelijk voorkomen. De volgende aanbevelingen beschrijven de belangrijkste manieren waarop de applicatie dit kan voorkomen: • Retourneer alleen standaard HTTP-headers. Alleen headers die voor het functioneren van HTTP van belang zijn, dient men te retourneren aan gebruikers (RFC 261612 voor HTTP/1.1, RFC 194513 voor HTTP/1.0). Alle overige HTTP-headers kan de applicatie in de regel zonder gevolgen uit een HTTP-antwoord verwijderen (zie ook 5.3.9). 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 kan men ervoor kiezen om bijvoorbeeld de “Server”-header uit het antwoord te verwijderen of deze te voorzien van een nietszeggende inhoud als “Server: WebServer 1.0”.

12 13

Zie: http://rfc.net/rfc2616.html Zie: http://rfc.net/rfc1945.html 62/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

Voorkom het lekken van 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 m.b.t. de applicatielogica openbaart (databasenamen, gebruikersnamen, bestandsnamen, interne IP-adressen, etc…). In het geval een applicationlevel firewall een dergelijke statuscode detecteert kan deze een standaard foutmelding (bijvoorbeeld “Er heeft zich een onbekende fout voorgedaan.”) retourneren aan de client en het gedetailleerde antwoord van de webserver negeren. Ook webservers zelf bieden functionaliteit om standaard meldingen te laten genereren a.d.h. van specifieke statuscodes. OPMERKING HTTP kent een groot aantal verschillende codes. Bij elke webapplicatie dient men zich af te vragen 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 in 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.

Voorkom de aanwezigheid van commentaarregels in scripts. Voordat men code vanuit een acceptatie- of testomgeving in productie plaatst, moet men eerst een scan uitvoeren 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 runtime uit HTML- en scriptcode te verwijderen en zodoende ‘gefilterde’ antwoorden terug te geven aan de client.

5.3.5

Normaliseer HTTP-verzoeken

HTTP-verzoeken kunnen allerlei ‘vreemde’ onderdelen bevatten. Er kunnen in het verzoek speciale karakters geencodeerd zijn, de URL kan ‘backslashes’ in plaats van ‘forward slashes’ bevatten, etc… Al deze afwijkingen kunnen wijzen op een kwaadwillende die de webapplicatie op één of andere manier wil misbruiken en de beveiliging, die de application-level firewall biedt, wil omzeilen. Daarom is het belangrijk om HTTP-verzoeken eerst te normaliseren ofwel ‘normaal te maken’. Policies e.d. past men het beste toe op een genormaliseerd verzoek in plaats van op een ruw verzoek teneinde foute beslissingen te voorkomen. Normaliseren van HTTP-verzoeken houdt in dat men in ieder geval de volgende acties uitvoert op deze verzoeken: • URL decodering; URL encodering is ooit ontstaan uit het feit dat niet alle soorten karakters zijn toegestaan in een URL. Om dit probleem te omzeilen bedacht men het concept van geencodeerde karakters. De
63/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

encodering bestaat eruit dat de client niet het karakter, maar de hexadecimale waarde van het karakter in de URL plaatst. Een spatie komt op deze manier als ‘%20’ in een URL terecht en een komma als ‘%2C’. URL encodering kan men voor alle mogelijke karakters uitvoeren. Hierdoor kan het gebeuren dat een kwaadwillende speciale karakters of karakterreeksen niet direct opneemt in een URL, maar deze encodeert. Op deze manier hoopt de kwaadwillende controles te omzeilen. Daarom is het belangrijk dat een applicatie een HTTP-verzoek eerst decodeert alvorens hiermee aan de slag te gaan. • HTML decodering; naast decodering van de URL moet de applicatie ook HTML decoderen. HTML biedt namelijk de mogelijkheid om in HTML karakters te encoderen zoals ampersand tekens (‘&amp;’), groter-dan tekens (‘&gt;’), kleiner-dan tekens (‘&lt;’), etc… De applicatie moet deze geencodeerde karakters decoderen alvorens met de verwerking van de invoer te starten. Pad normalisatie; pad normalisatie betekent dat een applicatie alle relatieve padverwijzingen uit een URL filtert en een absolute URL samenstelt. Dit betekent dat de applicatie relatieve pad verwijzingen als ‘/./’ en ‘/../’ uitfiltert. Hierdoor verandert de URL ‘/a/b/c/.././../d/script.html’ in ‘/a/d/script.html’. Door deze normalisatie uit te voeren voorkomt men ook dat een aanroep buiten de webroot treedt (een verzoek naar ‘/a/b/../../../../script.html’ is bijvoorbeeld niet toegestaan omdat de uiteindelijke – genormaliseerde – directory buiten de webroot valt). Ook invoervelden waarvan een webapplicatie gebruikt maakt, dient de applicatie te controleren op genormaliseerde paden. Converteren backslashes naar forward slashes; het web maakt gebruik van forward slashes (‘/’) in plaats van backslashes (‘\’). De aanwezigheid van backslashes kan duiden op een poging tot misbruik van een op Windows-gebaseerd systeem. Aangezien backslashes niet thuishoren in HTTP-verzoeken moet de applicatie deze backslashes ‘vertalen’ naar forward slashes.

5.3.6

Sta alleen benodigde HTTP-methoden toe

HTTP ondersteunt verschillende methoden (zie tabel 5-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 benodigd is. Methoden anders dan GET en POST zijn vrijwel nooit benodigd en vormen alleen een extra beveiligingsrisico. Niet benodigde methoden kan men daarom via configuratie van de webserver of via de application-level firewall blokkeren.

Methode CONNECT

Omschrijving Een methode die aangeeft dat een tussenliggende proxy het verzoek niet mag aanpassen c.q. onderzoeken en simpelweg moet
64/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

Methode DELETE GET HEAD OPTIONS POST PUT TRACE

Omschrijving doorsturen Verwijderen van het object op de webserver onder de gedefinieerde URL Opvragen van informatie betreffende het object Idem aan GET met het verschil dat bij HEAD de webserver niet de body van het bericht retourneert Biedt de mogelijkheid om te achterhalen welke HTTP-methoden een specifiek object ondersteunt Versturen van gegevens richting de webserver om verwerkt te worden door het object Plaatsen van een nieuw object op de webserver onder de gedefinieerde URL 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 5-1: overzicht HTTP-methoden (RFC 2616)

VOORBEELD Veel webservers bieden de mogelijkheid om alleen selectief HTTPmethoden 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. Zie voor meer informatie over het configureren van deze methoden onder Lotus Domino, zie: http://www-1.ibm.com/support/docview.wss?uid=swg21201202

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

65/116

5.3.7

Sta beperkt bestandsextensies toe

De bestandsextensie is meestal het gedeelte achter de laatste ‘.’ in een URL. De bestandsextensie bepaalt welk type bestand de client bevraagt. Naast standaard bestandsextensies (.html, .htm, .jpeg, .jpg, etc…) ondersteunen veel webservers ook minder generieke bestandsextensies (bijvoorbeeld .aspx voor Microsoft .NET webservers, .jar voor Websphere servers, etc…). Vaak ondersteunt een webserver meer extensies dan daadwerkelijk benodigd is voor het goed functioneren van de webapplicatie. In dit soort gevallen is het aan te raden om deze extensies onschadelijk te maken omdat elke extensie een mogelijke nieuwe ingang is tot misbruik van de webserver. Niet gebruikte bestandsextensies kunnen op de volgende manieren onschadelijk worden gemaakt: • Door het uitvoeren van een controle op de bestandsextensie op een application-level firewall. Een application-level firewall kan een HTTP-verzoek ontleden en bepalen welke bestandsextensie is aangeroepen. Alleen wanneer de bestandsextensie voldoet aan een de lijst met standaard toegestane extensies zal deze het verzoek doorlaten richting de webapplicatie. In alle andere gevallen blokkeert de applicationlevel firewall het verzoek. Zelfs wanneer de webserver een bepaalde gevaarlijke bestandsextensie ondersteunt (bijvoorbeeld .exe) zal de kwaadwillende er, bij een strikte configuratie van de application-level firewall, niet in slagen om bestanden met deze extensie aan te roepen op de webserver. Door het hardenen van de webserver. Na installatie van een webserver ondersteunt deze out-of-the-box een verzameling extensies waarvan de webapplicatie zeer waarschijnlijk maar een gedeelte daadwerkelijk gebruikt. Door de configuratie van de server te veranderen (bijvoorbeeld het verwijderen van ISAPI-filters op een Microsoft IISserver) voorkomt men dat de webserver bepaalde extensies ‘begrijpt’ en verwerkt.

Bij het gebruik van een application-level firewall hoeft men het blokkeren van bestandsextensies slechts op te nemen in het standaard beveiligingsbeleid waarna de application-level firewall dit voor elke webapplicatie bekrachtigt. Kiest men ervoor om bestandsextensies te blokkeren door het hardenen van webservers, dan zal men elke webserver (en mogelijk ook elke virtuele website op deze webserver) apart moeten configureren. VOORBEELD Een voorbeeld van een zeer gevaarlijke bestandsextensie bij uitstek is de .exe bestandsextensie op Windows-servers. Op het moment dat een kwaadwillende erin slaagt om bijvoorbeeld de cmd.exe executable aan te roepen op de webserver kan deze allerlei commando’s uit laten voeren op de webserver. Door de .exe-extensie op voorhand te blokkeren richting webservers (webapplicaties mogen deze extensie nooit gebruiken), voorkomt men misbruik op deze manier. De alom bekende Nimda-worm maakt bijvoorbeeld misbruik van de cmd.exe executable (via een verzoek als ‘GET

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

66/116

/c/winnt/system32/cmd.exe?/c+dir’). Zie voor meer informatie over de Nimdaworm CERT-advisory CA-2001-26: http://www.cert.org/advisories/CA-2001-26.html

5.3.8

Controleer verzoeken tegen bekende aanvalspatronen

Application-level firewalls bieden doorgaans de mogelijkheid om HTTP-verzoeken te controleren tegen een lijst van bekende aanvalspatronen. Deze vorm van negatief beveiligingsbeleid past men in de regel alleen toe als laatste controle op een HTTP-verzoek. Op het moment dat een applicatie het HTTP-verzoek controleert tegen de lijst met aanvalspatronen moeten de syntactische controles vanuit het positieve beveiligingsbeleid al zijn uitgevoerd zonder (negatief) resultaat. Door te controleren tegen bekende aanvalspatronen voorkomt men dat aanvallen die syntactisch volledig in orde zijn toch de webapplicatie bereiken. Een negatief beveiligingsbeleid vereist wel dat de application-level firewall continu wordt voorzien de laatste signatures. Verzuimt men deze nieuwe signatures beschikbaar te stellen aan de application-level firewall dan zal ook het negatieve beveiligingsbeleid geen beveiliging kunnen bieden tegen recente exploits, wormen en virussen.

5.3.9

Controleer de inhoud van HTTP-headers

Ook HTTP-headers bieden kwaadwillenden de mogelijkheid om misbruik van een webapplicatie te maken. Controle op de inhoud van deze HTTP-headers is daarom ook belangrijk. Een controle op deze headers moet zowel plaatsvinden op het HTTP-verzoek als op het HTTP-antwoord. In het geval een application-level firewall een HTTP-header detecteert die niet voldoet aan de policy kan het de volgende beslissingen nemen: • • • De inhoud van de header aanpassen en deze aangepaste header doorlaten; De header uit het HTTP-bericht verwijderen en het gefilterde bericht doorsturen; Het HTTP-bericht in zijn geheel blokkeren.

Onderstaand volgen enkele voorbeelden van mogelijk misbruik via HTTP-headers en de oplossing die filtering van deze headers in dit geval biedt. Voorbeeld #1: ongewenste authenticatie Een bepaalde webapplicatie is alleen bedoeld voor gebruik door anonieme gebruikers. Dit betekent dat gebruikers zich in geen enkel geval hoeven te authenticeren tegen de webapplicatie. De anonieme gebruiker heeft minimale rechten op het bestandssysteem van de webserver. Op de webserver is ook een ‘administrator’-account aanwezig dat uiteraard veel uitgebreidere rechten heeft dan de anonieme gebruiker. Een kwaadwillende wil proberen om een verbinding met de webapplicatie te krijgen om vervolgens te gaan werken onder het

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

67/116

‘administrator’-account in plaats van het anonieme account. Hiertoe voegt de kwaadwillende een ‘Authorization’ header toe aan het HTTP-verzoek: Authorization: Basic YWRtaW46YWRtaW4= Hoewel de webserver geen authenticatie afdwingt accepteert deze de Authorization-header wel en zal de webserver proberen om de gebruiker te authenticeren op basis van de meegestuurde authenticatiegegevens (admin:admin in dit geval). Indien dit succesvol is, krijgt de kwaadwillende de beschikking over een verbinding op basis van uitgebreidere toegangsrechten. In de application-level firewall configureert men dat het hier gaat om een publieke webapplicatie zonder authenticatie. Daarom filtert de application-level firewall HTTP-headers die bedoeld zijn voor authenticatie uit het bericht, waardoor het gefilterde verzoek zonder de ‘Authorization’ header terecht komt bij de webapplicatie. De kwaadwillende slaagt er hierdoor niet in om zich tegen de webserver authenticeren en onder het ‘administrator’-account een verbinding met de webapplicatie op te zetten. Voorbeeld #2: ongewenst lekken van informatie Een webserver lekt via HTTP-headers allerlei informatie over de gebruikte software op de webserver. De application-level firewall zorgt ervoor dat deze informatie niet terecht komt bij de eindgebruiker door bepaalde HTTP-headers uit te filteren en de inhoud van andere HTTP-headers te wijzigen. Figuur 5-5 geeft een voorbeeld van de werking van een application-level firewall als het gaat om het uitvoeren van controles op HTTP-headers.

Figuur 5-10: HTTP-header filtering

In het voorbeeld van figuur 5-10 heeft de application-level firewall een aantal HTTP-headers uit het antwoord van de webserver verwijderd (‘X-Aspnet-version’ en ‘Accept-Ranges’) en heeft het daarnaast de inhoud van de HTTP-header ‘Server’ aangepast. Het resultaat is een gefilterd antwoord richting de client zonder daarbij ongewenst informatie over de webserver te lekken.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

68/116

5.3.10

Controleer het gebruik van cookies

Cookies vormen een veelgebruikt middel om statusinformatie vast te leggen. Een webserver verstuurt een cookie richting de client via een ‘Set-Cookie’ HTTP responseheader; een client biedt een cookie aan een webapplicatie aan via een ‘Cookie’ HTTP requestheader. Kwaadwillenden kunnen het cookiemechanisme misbruiken om bijvoorbeeld sessies te ‘spoofen’ om op die manier ongeautoriseerd toegang te verkrijgen tot een webapplicatie. Door aan de serverkant actief te controleren op het gebruik van deze cookies kan men de kans op misbruik hiervan verminderen. Een application-level firewall kan wederom een rol spelen in het blokkeren van verzoeken met ongeldige cookies. Een mogelijk proces rondom de controle op cookies is afgebeeld in figuur 5-11.

Figuur 5-11: registratie van cookies

In figuur 5-11 start het proces met het uitgeven van een cookie door de webserver via een ‘Set-Cookie’ HTTP-header (1). De application-level firewall registreert de uitgifte van dit cookie in een eigen database (2). Naast de inhoud van het cookie registreert de application-level firewall bijvoorbeeld ook een IPadres waarnaar deze het cookie zal versturen en de webapplicatie die het cookie heeft uitgegeven. De application-level firewall retourneert het cookie aan de client (3) waarna de client het cookie zal opslaan in zijn geheugen of op de harde schijf (afhankelijk van het type cookie). Vervolgens tracht een kwaadwillende ditzelfde cookie te gebruiken om ook toegang tot de webapplicatie te verkrijgen (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 application-level firewall controleert vervolgens de inhoud van het aangeboden cookie tegen de database met uitgegeven cookies
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 69/116

(5). De application-level firewall zal vervolgens vaststellen dat het betreffende cookie nooit is uitgegeven of niet is uitgegeven aan de betreffende client. De application-level firewall zal het verzoek daarom blokkeren en niet doorsturen naar de webserver waardoor misbruik van het cookiemechanisme is voorkomen. OPMERKING Ook wanneer men geen gebruik maakt van een application-level firewall kan men deze controle op cookies uitvoeren. De webapplicatie zal deze functionaliteit in dit geval moeten bieden. Dit betekent een extra inspanning op het gebied van systeemontwikkeling.

5.3.11

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 (Platformbeveiliging). Een updatemechanisme voor alle applicatieplatformen, applicaties, databases, etc… die bovenop dit platform draaien is minstens zo belangrijk. Zorg er daarom voor dat de verschillende stappen uit patch management (vaststellen, beoordelen, verkrijgen, testen, uitrollen en monitoren) ook zijn ingeregeld voor dit soort applicaties.

5.3.12

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 ls-commando 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 geeft absolute paden door 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).

5.3.13

Hanteer safe coding technieken

Veel van de maatregelen die dit hoofdstuk voorstelt, hebben te maken met veilig programmeren (safe coding). Het is van belang om tijdens het ontwikkelen van een applicatie het aspect beveiliging continu in het achterhoofd te houden. Er bestaan enkele vuistregels die kunnen helpen om de veiligheid van code te vergroten. De belangrijkste vuistregels vindt u hieronder. Ten overvloede merken we hierbij op dat enkele vuistregels al eerder de revue passeerden of onderdeel uitmaakten van een andere maatregel. Het gaat om de volgende vuistregels: • Valideer alle invoer van een gebruiker (5.3.2).

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

70/116

Zorg voor een veilige beëindiging van een programma. Ongeacht de reden waarom de uitvoer van een programma stopt, moet dit op een veilige manier gebeuren. Dit betekent dat het programma alle mogelijke foutsituaties (bijvoorbeeld ongeldige invoer, database niet beschikbaar, onvoldoende rechten bij het schrijven naar een bestand, etc…) correct afhandelt. In theorie betekent dit dat een webapplicatie nooit en te nimmer een statuscode 500 (Internal Server Error) retourneert. Normaliseer alle invoer alvorens deze te verwerken (5.3.5). Zorg ervoor dat geencodeerde strings e.d. uit de invoer zijn verdwenen alvorens hier verdere bewerkingen op uit te voeren. Behandel gevoelige informatie voorzichtig (hoofdstuk 7). Gevoelige informatie moet men niet klakkeloos opslaan in databases en bestanden, zeker niet als dit onversleuteld gebeurt. Bedenk daarom tijdens het afhandelen van gevoelige informatie in code op welke manier de applicatie deze informatie zo veilig mogelijk kan behandelen. Maak hackers niet wijzer dan ze al zijn. Dit komt er in het kort op neer dat men geen gevoelige informatie via de code zou moeten lekken; specifiek voor webapplicaties gaat het om het lekken van informatie via HTTPheaders, foutmeldingen en commentaar in code (5.3.4). Repareer niet alleen fouten, bestudeer ze aandachtig. Zelfs bij professionele software komt het voor dat de leverancier een kwetsbaarheid in functie A verhelpt en exact dezelfde kwetsbaarheid in functie B over het hoofd ziet. Hierdoor is het programma na het verhelpen van de fout nog steeds kwetsbaar. Belangrijk is daarom om bij het verhelpen van een fout te bedenken of deze fout zich ook op andere plekken kan manifesteren en of men alleen de aanvalsvector heeft weggenomen of daadwerkelijk het probleem heeft opgelost.

5.3.14

Voer een (geautomatiseerde) code review uit

Nadat code gereed is voor productie, kan men via een blackbox test vaststellen of deze code kwetsbaar is voor zaken als SQL-injection en XSS. Een dergelijke blackbox test (dynamische analyse) zal echter niet in alle gevallen alle potentiële problemen in een webapplicatie detecteren. Daarom is het verstandig dat men ook een code review uitvoert (statische analyse); bij een code review scant een persoon (anders dan de ontwikkelaar) of een programma de programmacode op mogelijke kwetsbaarheden. Deze whitebox aanpak kan problemen aan het licht brengen die men via een blackbox aanpak niet zal kunnen zien. Daarnaast kan men de geautomatiseerde code review in verschillende stadia van het ontwikkelproces uitvoeren teneinde fouten in een vroeg stadium te kunnen verhelpen. Nadeel is echter dat een code review meer inspanning kan vergen als een blackbox test. Tools voor het uitvoeren van geautomatiseerde code reviews bestaan er in vele soorten en maten, van open source software tot prijzige commerciële toepassingen. Onderstaande - niet uitputtende - lijst geeft enkele punten weer waarop een geautomatiseerde tool kan controleren:

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

71/116

• • • • • •

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 input validatie; Datastromen door een webapplicatie.

5.3.15

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 aangekochte applicaties.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

72/116

6

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.

6.1

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

Figuur 6-1: opbouw van een identiteit

De identifier representeert de gebruiker of de applicatie. Hierbij kan men 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 persoonsnummer (identifier) uniek binnen Nederland (domein). Daarnaast is de identifier over het algemeen niet onderhevig aan een lifecycle. De gebruikersnaam van een medewerker voor een bepaalde applicatie wijzigt bijvoorbeeld vrijwel nooit en het persoonsnummer dat een inwoner van Nederland bij geboorte krijgt verandert nooit meer tot zijn/haar dood.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

73/116

De authenticator is datgene dat een persoon gebruikt om de identifier te ‘bewijzen’. Om te bewijzen dat een gebruikersnaam een valide identifier is, moet een gebruiker ook zijn wachtwoord (authenticator) opgeven. Om te bewijzen dat het persoonsnummer inderdaad een bepaalde persoon toebehoort, moet deze persoon zijn paspoort (authenticator) tonen. Authenticatoren verschillen veelal in sterkte. Zo vormt een wachtwoord van drie letters een stuk minder sterke authenticator dan een certificaat dat is opgeslagen op een smartcard. Daarnaast dient men de authenticator beveiligd op te slaan. Een paspoort hoort normaal gesproken in de kluis, een wachtwoord in het hoofd (en 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 zou men bijvoorbeeld elke maand moeten veranderen, een paspoort moet men elke 10 jaar vernieuwen. Het profiel bevat tot slot bepaalde kenmerken (attributen, rollen en data) die toebehoren aan de identiteit. Hierbij moet men 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 repositories 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 privacy gevoelig. De identifier en/of het profiel bepaalt vervolgens welke autorisaties een gebruiker krijgt binnen de webapplicatie. Er bestaan verschillende autorisatiemechanismen 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; beschrijft specifieke regels waaraan een gebruiker moet voldoen (bijvoorbeeld attribuut x >= 1) voordat deze toegang krijgt op basis van gegevens uit zijn/haar profiel. Bij rule-based access control hoeft het controlerende mechanisme alleen attributen van een gebruiker te controleren. Daarom kan rule-based access control performancevoordelen geven boven control mechanismen waarbij de server bijvoorbeeld een grote groep moet nalopen op een mogelijk lidmaatschap van een bepaalde gebruiker. Mandatory Access Control (MAC); bij dit model baseert men de autorisaties op classificaties of labels aan een object gecombineerd met het classificatieniveau of labels van de gebruiker. Discretionary Access Control (DAC); toegang tot bestanden wordt bepaald door de rechten die een gebruiker heeft toegewezen gekregen. De eigenaar van het bestand kan vervolgens zelf weer rechten uitdelen aan andere gebruikers.
74/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

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 om het authenticeren van identiteiten op basis van hun authenticator. Op eenzelfde manier betreft toegangsbeheer alle activiteiten die applicaties moeten uitvoeren om de autorisaties rondom deze webapplicatie in te regelen en af te dwingen (runtime uitdelen van autorisaties op basis van een autorisatietabel).

6.2

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

6.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 inmiddels succesvol heeft geauthenticeerd. Zou dit niet zo zijn dan zou de gebruiker zich bij elk volgend verzoek opnieuw moeten authenticeren en gaat de historie van zijn acties binnen de webapplicatie verloren. Om de sessie tussen een gebruiker en een webapplicatie te ‘fixeren’ staan de systeemontwikkelaar ruwweg de volgende mechanismen ter beschikking: • Sessie-fixatie 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.eenwebsite.nl/aanroep.asp?sessieid=123. Sessie-fixatie 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 daarmee in dit geval ook de informatie uit de onzichtbare velden. Onzichtbaar is hierbij echter een relatief begrip. De velden zijn niet direct zichtbaar vanuit een webbrowser. Onzichtbare velden maakt men echter op eenvoudige wijze zichtbaar door de broncode van een pagina te bekijken of via een sniffer de uitwisseling van gegevens te bestuderen. Kiest een ontwikkelaar ervoor om de velden van een formulieren via een GET-actie te versturen naar de webapplicatie dan verschijnen de ‘verborgen’ velden automatisch als argument in de URL (zie vorige punt). 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
75/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

van het bericht. • Sessie-fixatie op basis van cookies; sessie-fixatie op basis van cookies is de meest populaire manier om sessie-fixatie te bereiken. Hierbij verstuurt de server 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. Op het moment dat de gebruiker naar een website surft waarvoor het een cookie bezit zal de webbrowser dit cookie automatisch aanbieden aan de webapplicatie. OPMERKING Het is van belang het verschil te kennen 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 sessie-fixatie kunnen problemen ontstaan. Onderstaande lijst beschrijft twee van deze problemen: • Een kwaadwillende ontdekt dat een webapplicatie gebruik maakt van het verborgen veld genaamd ‘userid’. Bij het initieel benaderen van de webapplicatie is de inhoud van dit verborgen veld leeg. Nadat de kwaadwillende probeert in te loggen met een standaard gebruikersnaam en wachtwoord blijkt dit niet te lukken en het ‘userid’ veld 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. Nadat hij dit gedaan heeft krijgt hij de melding ‘Welkom Blackhat’ en kan hij gebruik maken van de webapplicatie zonder zich geauthenticeerd te hebben. De webapplicatie blijkt in dit geval volledig te vertrouwen op de waarde van het verborgen veld ‘userid’. Een reguliere gebruiker van een webapplicatie 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’ blijkt hij nog steeds geauthenticeerd te zijn en krijgt hij de gegevens te zien van een volledig 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 blijkt aldus een zeer lastig onderdeel van een webapplicatie. Niet alleen het fixeren van een sessie kan lastig blijken. Ook het uiteindelijk ‘ontmantelen’ van een sessie kan problemen met zich
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 76/116

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 open blijven staan. De aanwezigheid van een sessie zorgt aan de ene kant voor onnodig resourcegebruik op de server (de server moet alle sessies op één of andere manier administreren 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 via een internetcafé).

6.2.2

Foutieve implementatie van toegangsbeheer

Vergelijkbare problemen als bij authenticatie en sessiemanagement (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 al dan niet mogen uitvoeren van een bepaalde transactie of het al dan niet mogen bekijken van een specifieke webpagina. Het volgende voorbeeld illustreert een mogelijk probleem dat zich kan voordoen bij toegangsbeheer: Een webapplicatie kent de pagina ‘/protected/insidernews.aspx’ waartoe alleen geregistreerde gebruikers toegang hebben. Binnen de applicatie is vastgelegd dat voor alle verzoeken naar ‘/protected/*’ een speciale autorisatievlag benodigd is. De volgende voorbeelden illustreren implementatiefouten die ertoe kunnen leiden dat de webapplicatie deze autorisaties niet goed afhandelt: • De applicatie voert geen normalisatie van het verzoek vanaf de gebruiker uit (zie 5.3.5). Een kwaadwillende kan dit misbruiken door geen verzoek te doen naar ‘/protected/insidernews.aspx’ maar naar ‘/./protected/insidernews.aspx’. Logischer wijs 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 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 inhoud. Het blijkt dat de webapplicatie zijn beslissing om toegang te verlenen baseert op de inhoud van het betreffende cookie.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

77/116

Een kwetsbaar script binnen de webapplicatie voert geen goede inputvalidatie 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 er vele implementatiefouten binnen een webapplicatie kunnen bestaan die ertoe kunnen leiden dat kwaadwillenden autorisaties omzeilen.

6.2.3

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. Op het moment dat een kwaadwillende erin slaagt om authenticatiegegevens te achterhalen, kan deze zich er vervolgens zelf mee gaan authenticeren tegen de webapplicatie. Voor het onderscheppen van authenticatiegegevens staan de kwaadwillende een aantal mogelijkheden ter beschikking: • Phishing: hierbij achterhaalt een kwaadwillende authenticatiegegevens (en mogelijke andere informatie) door gebruikers te verleiden om naar een namaak website te surfen en daar deze (authenticatie-)gegevens in te laten vullen. Social engineering: social engineering bestaat eruit authenticatiegegevens te achterhalen door gebruikers over te halen deze te onthullen. Social engineering speelt ook een belangrijke rol bij phishing. Social engineering is echter breder (het kan hier 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 authenticatiegegevens zijn onderschept.

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=

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

78/116

Op het eerste oog lijkt het erop dat de authenticatiegegevens versleuteld zijn aangezien deze niet direct uit de inhoud van de HTTP-header af te leiden zijn. Het blijkt echter dat ‘basic authentication’ gebruik maakt van ‘base64 encoding’. Strings die middels base64 geencodeerd zijn, kan men ook eenvoudig weer decoderen. Figuur 6-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 6-2: base64 encoding/decoding

ACHTERGROND In juli 2006 verscheen voor het eerst een grootschalige 'man-in-the-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 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

6.2.4

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 zelfs sprake van een beveiligingsrisico omdat data onvoldoende beschermd bereikbaar is via internet.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

79/116

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 men nalaat is regelmatig opnieuw een risicoanalyse uit te voeren op de applicatie. Hierdoor blijkt op een gegeven moment het gebruikte authenticatiemechanisme niet meer te voldoen voor de gestaag doorgegroeide applicatie.

6.2.5

Het wiel opnieuw uitvinden

De implementatie van authenticatie- en 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 men beheermechanismen inregelen, moeten diepgaande testen worden uitgevoerd, etc… De kans dat men 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 middels 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 zal men voor deze webservice een nieuw authenticatieproces inrichten. Dit terwijl het grootste gedeelte van het bestaande authenticatiemechanisme in veel gevallen herbruikt kan worden.

6.2.6

Incompatibele authenticatiemechanismen

Wanneer men het wiel voor elke webapplicatie opnieuw uitvindt (6.2.5), 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
80/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

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 niet ondenkbaar 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 of via een “big-bang” aanpak (het lanceren van een volledig nieuw systeem als vervanging voor de twee oudere systemen). • De beheermechanismen rondom het ene authenticatiemechanisme zijn niet toepasbaar op het andere authenticatiemechanisme. Gevolg hiervan is dat men rondom elk authenticatiemechanisme een apart beheerproces (inclusief achterliggende techniek) moet inrichten voor gebruikersbeheer, rollenbeheer, etc… Het is niet mogelijk een goed profiel worden 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 kan men geen geheel omvattend profiel van deze persoon opmaken en moeten applicaties overlappende gegevens ieder apart bijhouden (denk hierbij bijvoorbeeld aan een adreswijziging die elke applicatie afzonderlijk moet doorvoeren).

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

6.3.1

Bepaal de plek van identiteit- en toegangsbeheer

Eén van de belangrijkste stappen die men op het gebied van identiteit- en toegangsbeheer moet nemen, is bepalen waar men identiteit- en toegangsbeheer belegt. Kiest men voor dit doel een gezamenlijk raamwerk of verwerkt men dit steeds opnieuw los in de applicatie? Figuur 6-3 toont een aantal mogelijke alternatieven die er op dit gebied bestaan.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

81/116

Figuur 6-3: verdeling identiteit- en toegangsbeheer applicatie/centraal

Het overzicht van figuur 6-3 toont vijf verschillende applicaties (A-E) die allen een andere invulling hebben gegeven aan identiteitbeheer en toegangsbeheer. Bij de 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 identiteit- en 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. M.a.w.: 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.

6.3.2

Overweeg de invoering van I&AM tooling

Op het moment dat men besloten heeft waar taken op het gebied van identiteiten toegangsbeheer worden belegd kan men vervolgens de keuze overwegen tooling op op dit gebied te implementeren: I&AM (Identity & Access Management) tooling. Uiteraard is een keuze voor dergelijke tooling alleen relevant wanneer men de intentie heeft om in ieder geval bepaalde delen van identiteit- en toegangsbeheer buiten de applicatie te plaatsen (applicatie B-E uit het overzicht van figuur 6-3).

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

82/116

6.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 6-4 beschrijft een voorbeeld van een mogelijke implementatie van I&AM tooling (op basis van een reverse proxy oplossing).

Figuur 6-4: mogelijke opstelling centrale authenticatie en autorisatie

In figuur 6-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 authenticatie- en autorisatieproces geheel transparant. 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 8). 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 aangezien deze alleen werkt op basis van een identifier en dus ‘authenticatoronafhankelijk’ is.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

83/116

6.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 getrokken. Hierdoor vermindert de complexiteit van de webapplicatie en kunnen ontwikkelaars zich in het geheel richten op het verwerken van functionaliteit in de webapplicatie. Dit betekent dat de ontwikkeling van webapplicaties sneller zal kunnen verlopen 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 men bijvoorbeeld met een webapplicatie die beveiliging vereist op basis van een gebruikersnaam/wachtwoord en blijkt dit later niet meer voldoende te zijn (i.v.m. de classificering van de data die de webapplicatie aanbiedt), dan is het redelijk eenvoudig om de gebruikte authenticator te wijzigen. Hiertoe voert men wijzigingen door in de I&AM tooling en hoeft de achterliggende webapplicatie hier in principe niets van te merken. 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.eenwebsite.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 hierbij 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 6.3.5) wordt op deze manier een stuk eenvoudiger. 6.3.2.3 Voorbeelden Er zijn verschillende producten op de markt die services op het gebied van identiteit- en 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: • • • • • Entrust GetAccess; eTrust Siteminder; IBM Tivoli Access Manager (voorheen IBM Policy Director); Oblix NetPoint; RSA Cleartrust.

6.3.3

Maak een gefundeerde keuze voor authenticatiemechanisme

Er bestaan een groot aantal authenticatiemechanismen die een organisatie kan inzetten voor de bescherming van een webapplicatie. Het is van belang dat men op basis van een (korte) risicoanalyse bekijkt welk authenticatiemechanisme het
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 84/116

beste past bij de betreffende applicatie. Figuur 6-5 geeft een overzicht van enkele authenticatiemechanismen.

Iets dat je weet -Wachtwoord -Passphrase -PIN-code

Iets dat je hebt -Token -Smartcard -Mobiele telefoon

Iets dat je bent - Biometrische kenmerken

Figuur 6-5: Overzicht van authenticatiemechanismen en voorbeelden14

Authenticatie kan men 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 PIN-code); 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
14

Fotoverantwoording:

iPhone: Dylan Parker; token: P^2 (via flickr.com); creditcard: Cheon Fong Liew (liewCF.com); iris en vingerafdruk: stockfoto, rechten voorbehouden; handtekening: GOVCERT.NL; mond: Julia Freeman-Woolpert

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

85/116

authentication”). Hierbij kan men denken aan het combineren van smartcards (iets dat de gebruiker heeft) met een passphrase (iets dat de gebruiker weet).

6.3.4

Denk niet alleen aan inloggen

Bij het authenticeren van gebruikers besteedt men over het algemeen veel aandacht aan het inloggen van gebruikers. Wat men echter vaak vergeet is dat gebruikers op een gegeven moment ook weer de kans moeten krijgen om uit te loggen. Tijdens het uitloggen van een gebruiker wordt zijn/haar 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 dient op dat moment een Single Sign-Out plaats te vinden waarbij het mechanisme de authenticatie richting alle betrokken systemen weer ongedaan maakt. Verder is het zaak aandacht te besteden aan de idle time per sessie. Hoe lang mag een gebruiker verbonden (geauthenticeerd) blijven als er geen activiteit vanaf de gebruiker meer afkomt? Het is altijd aan te raden om een zodanige idle timeout 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 vermindert men 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.

6.3.5

Zorg voor uniforme en flexibele authenticatiemechanismen

Zoals in paragraaf 6.2.5 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 dataverzamelingen terecht komen. Creëer geen aparte databases met gebruikers voor verschillende applicaties maar consolideer deze zoveel mogelijk in één database. Hierdoor vermindert de beheerlast, voorkomt men dat authenticatiemechanismen gerepliceerd en gesynchroniseerd dienen te worden en verhoogt men 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.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

86/116

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 benodigd zijn. Denk hierbij bijvoorbeeld aan de implementatie van authenticatie op basis van digitale (X.509-)certificaten: wanneer men dit gehele proces heeft ingericht voor een webapplicatie op basis van HTML, moet het gehele authenticatiemechanisme eenvoudig te porteren zijn naar een webservice op basis van XML. • Wees erop voorbereid dat aankomende technologieën eenvoudig kunnen worden ingepast. Denk hierbij aan zaken als Federated Identity, SAML, WS-Trust, etc… ACHTERGROND De SAML-standaard is een relatief nieuwe standaard die staat voor Secure Assertion Markup Language. De standaard definieert een raamwerk voor het uitwisselen van beveiligingsinformatie tussen verschillende (online) organisaties. Via SAML kunnen deze organisaties op basis van XML ‘assertions’ aanmaken, opvragen en uitwisselen. Hierdoor kan op een gegeven moment een vorm van inter-organisationele Single Sign-On 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.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

87/116

7

VERTROUWELIJKHEID EN ONWEERLEGBAARHEID
Vertrouwelijkheid en onweerlegbaarheid zijn twee zaken die nauw aan elkaar verbonden zijn. In het geval men gebruik maakt van asymmetrische versleuteling (verschillende sleutels voor versleuteling en ontsleuteling), dient het publieke deel van de sleutel voor versleuteling (vertrouwelijkheid) van gegevens en het privédeel van de sleutel voor ontsleuteling hiervan en het plaatsen van digitale handtekeningen (onweerlegbaarheid/onloochenbaarheid). Dit hoofdstuk gaat dieper in op de begrippen vertrouwelijkheid en onweerlegbaarheid in het kader van webapplicaties.

7.1

Inleiding De laag “Vertrouwelijkheid en onweerlegbaarheid” vormt de laatste schakel (laag) in het contact tussen een client en een webapplicatie. Deze laag is met name 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.

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

7.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 kan men ook nauwer definiëren: 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 informatie verstrekt (zie ook hoofdstuk 5): • • • Een webserver toont de gebruikte versies van software en plug-ins; Een script bevat commentaar waarin details omtrent de werking van het script zijn opgenomen; Een foutmelding bevat informatie over de gebruikte database met bijbehorende gebruikersnamen en wachtwoorden.
88/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

Zaken zoals hierboven beschreven, zijn redelijk basaal en kwamen al 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 bestanden met vertrouwelijke informatie uit de backoffice te benaderen terwijl deze bestanden niet bedoeld zijn voor ontsluiting via de webapplicatie.

7.2.2

Weerlegbaarheid

Er is sprake van weerlegbaarheid op het moment dat 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/haar 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 zich in een transactie bevindt.

• •

7.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 twisten over het feit dat deze transacties hebben plaatsgevonden.

7.3.1

Versleutel vertrouwelijke informatie

Door de inzet van SSL/TLS zorgt men ervoor dat informatie tijdens transport versleuteld is. Deze versleuteling stopt echter op het moment dat de webapplicatie met de gegevens aan de slag gaat. Op het moment dat de webapplicatie deze gegevens onversleuteld opslaat in een bestand of database
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 89/116

loopt de organisatie het risico dat deze informatie op één-of-andere manier in handen van kwaadwillenden komt. Daarom is het aan te raden om vertrouwelijke informatie op te slaan in versleutelde vorm. Er zijn een groot aantal standaard bibliotheken beschikbaar die een ontwikkelaar van een webapplicatie kan gebruiken om versleuteling van gegevens te bereiken. Het is aan te raden dergelijke standaard bibliotheken te gebruiken boven eigen ontwikkelde bibliotheken om versleuteling toe te passen. Deze standaard bibliotheken zijn veelal ver uitontwikkeld, zijn door de internetgemeenschap uitgebreid onderzocht en beproefd en bieden een maximale performance. Bovenop (of in plaats van) transportversleuteling via SSL/TLS kan men er ook voor kiezen om specifieke onderdelen van het bericht te versleutelen. Hiermee voorkomt men dat een kwaadwillende via een man-in-the-middle aanval de SSL/TLS-sessie onderbreekt en daarmee toegang krijgt tot de inhoud van HTMLen XML-berichten. Voor het versleutelen van specifieke onderdelen uit een XMLbericht bestaan inmiddels al een aantal standaarden; voor HTML-berichten is dat niet het geval. De XML-Encryption standaard is een voorbeeld van een standaard die men kan toepassen om versleuteling van gegevens in een XML-bestand te bereiken. Via deze standaard is het mogelijk om een gedeelte van het XML-bericht te versleutelen en sleutelinformatie te versturen. ACHTERGROND Meer informatie over het versleutelen van gegevens in XML kunt u terugvinden 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-os-SOAPMessageSecurity.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 message broker. Een message broker ontvangt berichten van verschllende bronnen en routeert het bericht uiteindelijk naar de juiste eindbestemming. Door onderdelen van het bericht apart te versleutelen voorkomt men dat deze message broker inzage krijgt in mogelijk vertrouwelijke gegevens. Figuur 7-1 geeft deze situatie weer. In de situatie van figuur 7-1 wisselen een client en een server informatie uit via een broker. De informatie betreft een drietal velden: A, B en C. De communicatieverbindingen tussen clientbroker en broker-server realiseert men op basis van SSL/TLS waardoor transportversleuteling ontstaat. Client 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. Het is niet de bedoeling dat de broker inzicht krijgt in de waarde van dit veld. Aangezien de broker de SSL-sessie met de client termineert 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).

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

90/116

Vertrouwelijkheid van de informatie in veld C is hierdoor bewerkstelligd, ondanks de tussenkomst van een (minder vertrouwde) message broker.

Figuur 7-1: versleuteling van gegevens

7.3.2

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 kan ertoe leiden dat kwaadwillenden zich ongeautoriseerd toegang verschaffen tot een webapplicatie. Dit kan gebeuren op het moment dat een kwaadwillende een cookie weet op te vangen (door het netwerkverkeer te sniffen) of op het moment dat deze een achtergebleven cookie op een werkstation in handen krijgt (bijvoorbeeld in een internetcafé). Veel van deze problemen met cookies kan men voorkomen door het cookie te versleutelen of door extra controles uit te voeren op cookies (zie hoofdstuk 5). Het versleutelen van het cookie dient te gebeuren 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) kan de inhoud van het cookie niet inzien. Door het versleutelen van cookies voorkomt men 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 vermijden kan de webapplicatie

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

91/116

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

7.3.3

Maak gebruik van digitale handtekeningen

In sommige gevallen kan het benodigd zijn dat transacties – en de inhoud hiervan - onweerlegbaar zijn. In dit soort gevallen ontkomt men er vrijwel niet aan om te gaan werken met digitale handtekeningen. Bij een digitale handtekening maakt de ondertekenaar gebruik van een ‘geheim’ dat alleen bij deze gebruiker bekend is. Dit kan bijvoorbeeld een code of een privé-sleutel zijn. De eerste implementatie van een digitale handtekening maakte gebruik van Public Key Cryptography (PKI) 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. Hiertoe voert gebruiker A 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, etc… 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. Doordat het bericht versleutelt 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 men een digitale handtekening op de inhoud van
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 92/116

een bericht (of delen daarvan) kan plaatsen; XML Signature is een voorbeeld van een dergelijke standaard. Figuur 7-2 bevat een voorbeeld van een XML bestand dat (geheel) ondertekend is met een digitale handtekening.

Figuur 7-2: 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 webbrowser benodigd zijn om functionaliteiten op het gebied van digitale handtekeningen te kunnen implementeren.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

93/116

8

BEVEILIGINGSINTEGRATIE
De beveiligingsintegratielaag is vooral bedoeld om functionaliteit te bieden. Het is daarnaast ook een virtuele laag: er bestaan geen specifieke producten die beveiligingsintegratie met beveiligingscomponenten (en beveiligingscomponenten onderling) mogelijk maken. Het is een ingebouwde functionaliteit van beveiligingscomponenten die webapplicaties (en andere beveiligingscomponenten) kunnen aanroepen c.q. raadplegen. Dit hoofdstuk gaat in op de manier waarop beveiligingsintegratie tussen webapplicaties en beveiligingsapplicaties (en beveiligingscomponenten onderling) tot stand kan komen.

8.1

Inleiding Beveiligingsintegratie houdt in dat een webapplicatie de beschikking krijgt over informatie die aanwezig is binnen de beveiligingscomponenten. Hierdoor kan een beveiligingsoplossing als generiek onderdeel binnen een webomgeving fungeren 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 6, figuur 62). Enkele voorbeelden van beveiligingsintegratie die een webapplicatie kan wensen 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 application-level firewall met de eindgebruiker heeft; Een webapplicatie wil een load balancer opdracht geven geen verkeer meer richting een specifieke webserver te versturen (omdat er bijvoorbeeld onderhoud op deze webserver gaat plaatsvinden).

• •

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

8.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
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 94/116

beveiligingsintegratie houdt in dat de webapplicatie actief contact legt met het beveiligingscomponent om informatie op te vragen of opdrachten te geven. Het vervolg van deze paragraaf bespreekt passieve en actieve beveiligingsintegratie in meer detail.

8.2.1

Passieve beveiligingsintegratie

Passieve beveiligingsintegratie is op verschillende manieren te implementeren. Drie generieke stappen doorlopen gebruikers, beveiligingscomponent en applicatie altijd bij passieve beveiligingsintegratie: 1. De gebruiker maakt contact met het beveiligingscomponent; 2. De beveiligingscomponent voert zijn beveiligingsacties uit; 3. De gegevens die uit deze beveiligingsactie naar voren komen stelt de beveiligingscomponent bij voorbaat beschikbaar voor achterliggende componenten. De mogelijkheid bestaat dat achterliggende componenten geen gebruik maken van deze informatie.

Figuur 8-1: passieve beveiligingsintegratie

Figuur 8-1 toont drie mogelijke implementaties van bovenstaande stappen: 1. Opslaan van gegevens in een tussenliggende datastore; hierbij plaatst het 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 (beveilgingscomponent plaatst de gegevens altijd in de database) en actieve integratie (de

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

95/116

achterliggende applicatie moet de gegevens zelf weer actief uit de database halen). 2. Doorgeven van waarden via een querystring; bij deze oplossing plakt het beveiligingscomponent belangrijke gegevens achter de gebruikte URL in de vorm van een querystring. De achterliggende applicatie kan de gegevens uit de querystring vervolgens gebruiken in de eigen programmalogica. 3. Doorgeven van waarden via HTTP-headers; de informatie die het beveiligingscomponent in voorgaand punt verwerkt in een querystring kan dit beveiligingscomponent ook aanbieden via HTTP-headers. De achterliggende applicatie kan besluiten om de gegevens uit deze headers op te halen en te verwerken in de eigen programmalogica. VOORBEELD Passieve beveiligingsintegratie kan van groot nut zijn wanneer men bijvoorbeeld in zeer korte tijd Single Sign-On moet inregelen 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 tooling voor deze applicaties in te zetten en enkele specifieke wijzigingen in deze tooling door te voeren, bereikt men dit relatief eenvoudig zonder hiervoor ook maar één wijziging door te voeren in de twee applicaties. De I&AM tooling 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&AM tooling een POST-request waarin het de gebruikersnaam en het wachtwoord van de gebruiker verwerkt. De I&AM tooling simuleert hiermee het inloggen van het formulier op de webapplicatie en het klikken op de knop ‘Inloggen’. Hierdoor lijkt het dat de gebruiker zelf inlogt op de webapplicatie 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&AM tooling een “Authorization” HTTP-header waarin het de gebruikersnaam en het wachtwoord van de gebruiker in base64 encoding opneemt. Deze HTTP-header voegt de I&AM tooling toe aan elk verzoek dat de gebruiker verstuurt naar Applicatie B. Applicatie B merkt hierdoor niet dat niet de gebruiker maar de I&AM tooling inlogt op de applicatie. Wederom biedt de I&AM tooling 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 tooling kan de gebruiker zonder problemen ‘switchen’ tussen de verschillende applicaties zonder dat hij/zij zich daarvoor opnieuw moet authenticeren. Voor de gebruiker kan het dus om één applicatie lijken te gaan terwijl hij/zij in werkelijkheid wordt bediend door twee losstaande applicaties.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

96/116

8.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 het beveiligingscomponent dus niet inline (d.w.z. tussen de client en achterliggende applicatie) geplaatst te zijn. Figuur 8-2 schetst deze twee alternatieven.

Figuur 8-2: actieve beveiligingsintegratie

Bij inline plaatsing zal het beveiligingscomponent het verzoek van de gebruiker valideren en, indien akkoord bevonden, doorsturen naar de achterliggende webapplicatie. Bij het doorsturen van verzoek zal het beveiligingscomponent geen gegevens over de sessie met de gebruiker naar de applicatie meesturen (zoals bij passieve beveiligingsintegratie). Bij het ontvangen van het verzoek zal de applicatie zelf actief contact gaan leggen met het beveiligingscomponent om informatie over uitgevoerde beveiligingsacties door het beveiligingscomponent te achterhalen. Ook wanneer het beveiligingscomponent niet inline geplaatst is, kan de achterliggende webapplicatie actief contact leggen met het beveiligingscomponent om beveiligingsinformatie op te vragen. Zo kan de webapplicatie bijvoorbeeld aan het beveiligingscomponent vragen om een bepaalde gebruikersnaam/wachtwoord combinatie te valideren en het resultaat te retourneren. Een voor de hand liggende methode voor het bereiken van actieve beveiligingsintegratie is de toepassing van webservices.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

97/116

VOORBEELD F5, leverancier van netwerk- en beveiligigingsapparatuur, 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 F5-componenten aan te sturen en te bevragen.

8.3

Aanbevelingen Met de invoer van elk nieuw beveiligingscomponent dient men zich af te vragen: hoe integreer ik dit component binnen mijn omgeving? Belangrijk is vast te stellen: • • Welke services de omgeving van het 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 productieselectie. 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 integreren.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

98/116

9

MONITORING, AUDITING EN ALERTING

9.1

Inleiding 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 hieraan een invulling geven. Heel belangrijk is dat men monitoring, auditing en alerting niet los op elke laag beschouwt, maar dat (causale) verbanden kunnen worden gelegd tussen de afzonderlijke logging- en monitoringmechanismen. Dit soort denken is m.n. van belang door de steeds verder voortschrijdende ketenintegratie waarbij componenten aan elkaar gekoppeld worden en de sterkte van de keten bepaald wordt door de zwakste schakel. Ketenintegratie vereist tevens dat verschillende competenties binnen een organisatie (bijvoorbeeld netwerkbeheer en systeemontwikkeling) nauwer met elkaar gaan samenwerken. Vindt er bijvoorbeeld een aanval plaats op een applicatie binnen het RBW, dan dient men de logging events op de verschillende lagen van het RBW te kunnen combineren om zodoende een duidelijk aanvalspatroon (met bijbehorend bewijsmateriaal) te kunnen verzamelen. Door op deze manier te werk te gaan, kan men 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 men afzonderlijke componenten monitoort is het tevens belangrijk 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 gehele keten en moet dit ook als zodanig worden opgemerkt.

9.2

Mogelijke kwetsbaarheden en bedreigingen Deze paragraaf beschrijft kwetsbaarheden en bedreigingen die men op het gebied van monitoring, auditing en logging kan onderscheiden.

9.2.1

Ontbreken van toezicht

Wanneer een kwaadwillende een webapplicatie - of de infrastructuur hieromheen probeert aan te vallen kan dit kwalijke gevolgen hebben. Op het moment dat de organisatie een aanval detecteert kan het passende maatregelen nemen en de schade tot een minimum proberen te beperken. Dit kan echter alleen wanneer de juiste mechanismen zijn ingezet om aanvallen te detecteren en deze

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

99/116

mechanismen juist zijn geconfigureerd. Door verschillende oorzaken kan het organisaties aan dit toezicht ontbreken: • • Er is überhaupt geen monitoring van netwerkverkeer ingeregeld; De monitoringcomponenten leveren zoveel informatie dat de belangrijke aanvallen niet meer te onderscheiden zijn van de vele ‘script kiddie’ aanvallen; men ziet m.a.w. door de bomen het bos niet meer. De monitoringcomponenten verzamelen wel continu data maar er is geen medewerker beschikbaar om deze logging door te nemen. De monitoringcomponenten verzamelen wel continu data maar de gebeurtenissen vanaf 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.

9.2.2

Impact: onbekend

Wanneer een component een losstaande gebeurtenis rapporteert, helpt dit in het bepalen van de technische impact: het component is bijvoorbeeld tijdelijk niet meer beschikbaar of de performance is tijdelijk verlaagd. Maar wat betekent dit nu voor de gehele keten? Merkt de gemiddelde 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, moet men de gebeurtenis in een groter geheel (de keten) bekijken. Dit is niet mogelijk wanneer men de omgeving beschouwt als een verzameling van losstaande componenten. De beschouwing van de omgeving als een keten van nauw samenwerkende componenten is in dit geval de enige juiste. Inzicht in de verbanden die zich tussen de componenten bevinden is hierbij essentieel. Op basis van dit inzicht zou de organisatie vervolgens een afhankelijkheids- en kwetsbaarhedenanalyse (kortweg A&K analyse) of risicoanalyse moeten uitvoeren.

9.2.3

Gebrek aan coördinatie en samenwerking

De componenten die logging genereren vallen vaak onder verschillende competenties binnen een organisatie. Een netwerkbeheer team beheert de netwerkcomponenten, een applicatiebeheerteam de webapplicaties, een autorisatiebeheerteam de autorisaties, etc… Het analyseren van complexe gebeurtenissen binnen de omgeving vereist dat deze verschillende competenties nauw met elkaar samenwerken. Als de verschillende teams binnen de organisaties functioneren als ‘eilandjes’ zal deze samenwerking in veel gevallen niet tot stand komen. Door dit gebrek aan samenwerking – en het gebrek aan coördinatie tussen deze verschillende partijen – zal een complexe gebeurtenis daarom nooit volledig geanalyseerd kunnen worden.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

100/116

9.3

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

9.3.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 DMZ-segmenten 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 Systems (NIDS); een NIDS plaatst men als losstaand component in het netwerk waarna deze vervolgens netwerkverkeer opvangt door de interface in promiscious mode te plaatsen. Promiscious mode houdt in dat de interface niet alleen verkeer opvangt dat specifiek voor deze interface bedoeld is, maar dat de interface al het verkeer dat het voorbij ziet komen (dus ook het verkeer dat niet aan de interface is gericht) verwerkt. 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 waardoor mogelijk aanvallen niet gedetecteerd worden en dat versleuteld verkeer (zoals bijvoorbeeld HTTPS) niet kan worden bekeken. Daarnaast vereist een NIDS dat men de aansluiting hiervan op de infrastructuur zodanig inregelt dat al het verkeer beschikbaar komt voor het NIDS. In het geval de organisatie gebruik maakt van switches kan dit betekenen dat men de switch zodanig moet configureren dat de switch al het verkeer ook kopieert naar het aansluitpunt van het NIDS (span port) of dat het IDS dit verkeer ontvangt via speciale ‘vampire taps’ (onderbrekingen in de kabelverbinding). Host-based Intrusion Detection Systems (HIDS); een HIDS installeert men op een server waarna het HIDS continu de activiteiten op deze server monitoort. Het HIDS kijkt hierbij niet alleen naar het netwerkverkeer (zoals het NIDS) maar vooral ook naar logging en andere lokale wijzigingen. Voordelen van de inzet van een HIDS zijn dat het meer aanvallen zal detecteren als het NIDS en dat het bovendien in staat is om versleutelde informatie te bekijken. Nadelen zijn dat het HIDS negatieve effecten kan hebben op de werking van het system en het netwerk (performance-impact) en dat het onderhouden van alle lokaal geïnstalleerde HIDS-systemen veel beheerlast met zich mee kan brengen. Application-based IDS; een application-based IDS wordt specifiek ingezet voor het monitoren van misbruik van een specifieke applicatie. Dit is de minst gangbare vorm van een IDS.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

101/116

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

NIDS • • Monitoort het gehele netwerk Kan alle aanvallen op een omgeving vastleggen Reageert direct op afwijkend netwerkverkeer (real time); 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

HIDS • • Monitoort alleen een specifiek 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 ook succesvol is Levert een mogelijke vertraging op in de werking van het systeem Mogelijk complexe setup bij veel hosts Bekijkt de header van pakketten niet

• • • •

• • • •

• •

• •

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

Tabel 9-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 systemen noemt men ook wel signature-based aangezien deze systemen op basis van bekende ‘handtekeningen’ van aanvallen detectie uitvoeren. Het nadeel van deze werkwijze is dat het IDS alleen bekende aanvallen 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). Deze systemen vereisen eerst een inleerperiode waarin zij bekijken wat ‘normaal’ gedrag is. Vervolgens kan het systeem afwijkingen op dit normale gedrag herkennen en dit rapporteren als een mogelijke aanval. Voordeel van deze werkwijze is dat een dergelijk IDS nieuwe – onbekende – aanvallen hoogst waarschijnlijk zal detecteren. Nadeel is dat het systeem veel false positives kan opleveren: een alarm zonder dat er iets aan de hand blijkt te zijn. Dit is met name het geval op het moment dat de organisatie een nieuwe applicatie in de omgeving uitrolt of een nieuwe versie van een bestaande applicatie introduceert. Van alle soorten IDS’en is de network-based variant (NIDS) met signatures de meest gebruikte en meest bekende vorm. Bij het inrichten van een NIDS is het zaak goed te bekijken welke meetpunten interessant zijn voor het NIDS. In figuur
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 102/116

9-1 is een voorbeeld opgenomen van mogelijk interessante meetpunten aan de hand van de DMZ-opbouw zoals in hoofdstuk 3 werd beschreven.

Figuur 9-1: mogelijke plaatsing van een NIDS

Het NIDS uit figuur 9-1 kent drie meetpunten: één voor de eerste firewall (1), één tussen de twee (dual-vendor) firewalls (2) en één tussen de DMZ en de backoffice. Op punt (1) kan het IDS alle aanvallen die gericht zijn op de omgeving detecteren omdat hier nog geen filtering van netwerkverkeer heeft plaatsgevonden. De gegevens van dit meetpunt zijn dan ook vooral van statistische waarde en leiden niet per definitie tot een alarm. Op punt (2) heeft al enige filtering plaatsgevonden (van een firewall en mogelijk van een proxy). 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 dient dit een hogere prioriteit te krijgen als bij punt (1). Tenslotte monitoort het IDS op punt (3) het verkeer tussen de DMZ en de backoffice. Dit is met name een interessant meetpunt aangezien de meest vertrouwelijke informatie zich per definitie zal bevinden in de backoffice en de toegang tot deze vertrouwelijke informatie nauwkeurig moet worden gemonitoord. ACHTERGROND Door het aantal geregistreerde gebeurtenissen op punt 1 en punt 2 met elkaar te vergelijken ontstaat ook inzicht in de effectiviteit van de filteringsmechanismen binnen de omgeving. Dit kan een organisatie helpen in het opstellen van bijvoorbeeld een return-on-investment analyse voor beveiligingscomponenten.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

103/116

Naast het verzamelen van al deze informatie is het ook van belang dat men de inrichting van het NIDS verder goed inregelt. Enkele aandachtspunten die hierbij van belang zijn: • Zorg ervoor dat signature-based systemen regelmatig worden voorzien 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. Men dient ook na te denken over de duur die logging moet worden opgeslagen en de manier waarop de logging zal worden gearchiveerd. Zorg ervoor dat de alarmering van het NIDS goed getuned wordt. Een NIDS dat continu alarmen uitzendt, zullen beheerders niet meer serieus nemen. Regel een goede beheerprocedure rondom het NIDS. Een medewerker van de organisatie zal de logging van het NIDS regelmatig (bijvoorbeeld elke ochtend) moeten bekijken. Het is belangrijk dat binnen de organisatie is belegd wie dit doet. Daarnaast is het, ter verbetering van de leesbaarheid van de logging, aan te raden filters op de logging te plaatsen. Onderschat de hoeveelheid mankracht die benodigd 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 optomaal in te richten.

9.3.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 logging beschikbaar via SNMP. Al deze verschillende loggingmechanismen zorgen ervoor dat logging versnipperd raakt en men het overzicht over alle gebeurtenissen mogelijk snel kwijtraakt. Om beveilingsissues efficiënt te kunnen detecteren is het van belang deze logging op één centraal punt weer bijeen te brengen. OPMERKING 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 de informatie vanuit verschillende lagen van het RBW. Dit kan uiteindelijk resulteren in een situatie zoals weergegeven in figuur 9-2.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

104/116

Figuur 9-2: inrichting centrale logging

In een centrale loggingdatabase komt de logginginformatie 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, etc… Logging op het niveau van platformbeveiliging: logging van ongeautoriseerde bestandstoegang, potentieel gevaarlijke configuratiewijzigingen, toevoeging van nieuwe gebruikersaccounts, etc… Logging op het niveau van applicatiebeveiliging: logging van uitgefilterde HTTP-headers, geblokkeerde URL’s, geblokkeerd lekken van informatie, etc… Logging op het niveau van identiteitbeheer: logging van foutieve inlogpogingen op de webapplicatie, accounts die ‘locked-out’ raken, sessiemisbruik, etc… Logging op het niveau van autorisatiebeheer: logging van autorisatiemisbruik, uitgedeelde autorisaties (met mogelijk uitgebreide rechten), etc… Logging op het niveau van vertrouwelijkheid en onweerlegbaarheid: logging van onweerlegbare transacties, foutieve handtekeningen, etc…

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) hier veel van kunnen leren v.w.b. de opbouw van de
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 105/116

infrastructuur en de gebruikte componenten hierin 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 (vertrouwelijkheid) en hierin geen wijzigingen kunnen aanbrengen (integriteit). 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.

9.3.3

Breng correlaties aan

Nadat alle logginginformatie m.b.t. webapplicaties bijeen gebracht is (9.3.2), bestaat de volgende stap uit het aanbrengen van correlaties tussen de verschillende logging gebeurtenissen. De uitdaging hierbij is om alle gebeurtenissen op de verschillende niveau’s aan elkaar en aan een specifieke webapplicatie te correleren. Op deze manier kan men 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 9-3 geeft een voorbeeld van correlaties die er kunnen bestaan tussen een applicatie en de aanwezige componenten (blauwe lijn) en de correlaties (afhankelijkheden – rode lijnen) tussen componenten onderling.

Figuur 9-3: monitoringafhankelijkheden

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

106/116

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. Een goed ingerichte Configuration Management Database (CMDB) kan het leggen van correlaties voor een belangrijk gedeelte vereenvoudigen.

9.3.4

Richt NTP correct in

Om gebeurtenissen binnen verschillende componenten aan elkaar te kunnen relateren is het van belang dat de timestamps van deze gebeurtenissen overeen komen. Deze timestamps zijn afhankelijk van een juiste instelling van de tijd op de betreffende componenten. Correcte inzet van het Network Time Protocol (NTP) kan ervoor zorgen dat de tijdstippen op alle servers en andere componenten overeen komen. Vrijwel alle besturingssystemen ondersteunen het gebruik van NTP.

9.3.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 ‘applicatieverantwoordelijken’ uitgedeelde autorisaties regelmatig onder de loep nemen. Hiertoe moeten zij een overzicht toegestuurd krijgen met de huidige stand van zaken rondom autorisaties voor de webapplicatie waarvoor deze persoon autorisatieverantwoordelijk is. De applicatieverantwoordelijke zal vervolgens moeten bekijken of er autorisaties bestaan die niet meer nodig zijn of gewijzigd dienen te 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.

9.3.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. Het is daarom belangrijk om op voorhand te bepalen 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: • Het component normaal door laten functioneren terwijl deze de logging niet kan opslaan. Dit betekent dat logging verloren gaat.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

107/116

Het component normaal door laten functioneren en de logging lokaal laten queuen. Veel componenten beschikken over een lokaal mechanisme om logging tijdelijk te queuen. Op het moment dat het centrale logging mechanisme weer beschikbaar komt, sluist het component de verzamelde logging alsnog door. Dit voorkomt dat het 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 queue vol loopt moet opnieuw besloten worden wat het component hierna doet (door functioneren – zie bovenstaande optie – of stoppen met functioneren – zie volgende optie). Het component acuut laten stoppen met functioneren. Dit betekent dat gebruikers hoogst waarschijnlijk niet meer kunnen doorwerken. Het voorkomt wel dat het component mogelijk malafide acties niet meer kan registreren.

Vanuit het oogpunt van beveiliging en beschikbaarheid heeft het de voorkeur componenten eerst lokaal gebeurtenissen te laten queuen om vervolgens het component te laten stoppen met functioneren zodra deze queue vol is. Bij de selectie van een nieuw beveiligingscomponent is het daarom zaak goed te evalueren of deze voldoet aan de vereisten op het gebied van logging en tijdelijke queueing van logging.

9.3.7

Stel bewaartermijnen van logging vast

Intensieve logging binnen een hostingomgeving 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 blijken in het efficiënt verhelpen van beveiligingsincidenten. De duur van offline beschikbaarheid kan beperkt worden door wet- en regelgeving (zie bijvoorbeeld ook de tekst bij ‘Achtergrond’). Voordat een organisatie besluit om gebeurtenissen binnen een hostingomgeving te loggen is het daarom van belang dat men bepaalt hoe lang en hoe logging beschikbaar moet blijven. Een beslissing op dit gebied bepaalt vervolgens welke media benodigd zijn en hoeveel capaciteit men voor de logging moet reserveren. ACHTERGROND Bij het vaststellen van bewaartermijnen van logging moet men ook rekening houden met privacywetgeving. Vrijwel elk beveiligingscomponent zal in zijn logging het IP-adres opnemen van de machine van waaraf deze verkeer heeft geregistreerd. Dit 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_z20000340.stm

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

108/116

9.3.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. Controle van de logging moet hiertoe onderdeel uitmaken van procedures waardoor taken en verantwoordelijkheden op dit gebied duidelijk 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.

9.3.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. Dit kan bijvoorbeeld nodig zijn op het moment dat een IDS een aanval detecteert en op verschillende beveiligingslagen bekeken moet worden wat over deze aanval kan worden teruggevonden. 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 kan men bijvoorbeeld gebruik maken van virtuele teams.

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

109/116

A

REFERENTIES
(DDoS-GOVCERT, 2005) GOVCERT.NL, Aanbevelingen ter bescherming tegen Denial-of-Service-aanvallen. Den Haag, 2005. (FBI/CSI, 2005) Computer Security Institute, 2005 CSI/FBI Computer Crime and Security Survey. San Francisco, 2005. (INSECURE, 2006) Ivan Ristic, Web Application Firewalls Primer. INSECURE Magazine maart 2006. Beschikbaar: http://www.insecuremagazine.com/INSECURE-Mag-5.pdf (online)

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

110/116

B

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 Advisory ID Versie Risico CVE ID Schade : : : : : : Outlook Web Access (OWA) kwetsbaar voor script-injectie GOVCERT.NL-2006-133 1.0 medium CVE-2006-1193 (http://cve.mitre.org/cve/) high Mogelijkheid tot cross-site scripting Omzeilen van restricties

Auteur Uitgiftedatum Toepassing Versie(s)

: : 20060613 : Microsoft Exchange : 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 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.
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 111/116

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

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

112/116

C

AFKORTINGEN EN DEFINITIES

Afkorting ACL AD API BGP CDP CMDB CMS CSI CWE DBA (D)DoS DMZ DNS EPFW FBI FTP GPO GSLB HIDS HTML HTTP(S) I&AM IDS IIS IP ISAPI ISP ISS LAN LDAP LSLB MTU NAT NIDS NTP NVD OS OSPF OWA OWASP PFW PKI

Omschrijving Access Control List Active Directory Application Programming Interface Border Gateway Protocol Cisco Discovery Protocol Configuration Management Database Content Management System Computer Security Institute Common Weakness Enumeration Database Administrator (Distributed) Denial-of-Service Demilitarised Zone Domain Name Services End-Point Firewall Federal Bureau of Investigation File Transfer Protocol Group Policy Object Global Server Load Balancing Host-based Intrusion Detection System HyperText Markup Language HyperText Transfer Protocol (Secure) Identity and Access Management Intrusion Detection System Internet Information Services Internet Protocol Internet Server Application Program Interface Internet Service Provider Internet Security Systems Local Area Network Lightweight Directory Access Protocol Local Server Load Balancing Message Transfer Unit Network Address Translation Network-based Intrusion Detection System Network Time Protocol National Vulnerability Database Operating System Open Shortest Path First Outlook Web Access Open Web Application Security Project Perimeter Firewall Public Key Cryptography
113/116

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

Afkorting PoC RBW RDP RFC RSS SAML SCP SIRT SMTP SNMP SPOF SQL SSH SSL SSO STP TCP TFTP TLS TTL UDP URL uRPF VLAN WSDL WSUS XML XSS

Omschrijving Proof-of-Concept Raamwerk Beveiliging Webapplicaties Remote Desktop Protocol Request For Comment 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) Security Assertion Markup Language Secure Copy Security Incident Response Team Simple Mail Transfer Protocol Simple Network Management Protocol Single Point-of-Failure Structured Query Language Secure Shell Secure Sockets Layer Single Sign-On / Single Sign-Out Spanning Tree Protocol Transport Control Protocol Trivial File Transfer Protocol Transport Layer Security Time-To-Live User Datagram Protocol Uniform Resource Locator Unicast Reverse-Path-Forwarding Virtual LAN Web Service Description Language Windows Server Update Services eXtensible Markup Language Cross-Site Scripting

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

114/116

D

HOOFDPUNTEN BEVEILIGING
Deze bijlage geeft een overzicht van de kwetsbaarheden, dreigingen en maatregelen die in dit document aan bod komen. D.1 Kwetsbaarheden en dreigingen

Netwerk • (Distributed) Denial-of-Service • Server hopping • Kwetsbare DNS(configuratie) • Kwetsbare firewall(configuratie) Platform • Kwetsbaarheden in het OS • Onveilige ingerichte beheermechanismen • Onjuiste autorisaties • Onnodige services Applicatie • Ongevalideerde input • Cross-Site Scripting (XSS) • SQL injection • Buffer overflows • Lekken van informatie • Onveilige opslag van informatie • Onveilige configuratie • Kwetsbare aangekochte applicaties Identiteit- en toegangsbeheer • Foutieve implementatie van authenticatie en sessiemanagement • Foutieve implementatie van toegangsbeheer • Onveilige authenticatiemechanismen • Discrepantie tussen authenticatiemechanisme en beveiligingsbeleid • Het wiel opnieuw uitvinden • Incompatibele authenticatiemechanismen Vertrouwelijkheid en onweerlegbaarheid • Lekken van informatie • Weerlegbaarheid Monitoring, auditing en alerting • Ontbreken van toezicht • Impact: onbekend • Gebrek aan coördinatie en samenwerking

§3.2.1 §3.2.2 §3.2.3 §3.2.4

§4.2.1 §4.2.2 §4.2.3 §4.2.4

§5.2.1 §5.2.2 §5.2.3 §5.2.4 §5.2.5 §5.2.6 §5.2.7 §5.2.8

§6.2.1 §6.2.2 §6.2.3 §6.2.4 §6.2.5 §6.2.6

§7.2.1 §7.2.2

§9.2.1 §9.2.2 §9.2.3

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

115/116

D.2

Maatregelen

Netwerk • Besteed veel aandacht aan het DMZ-ontwerp • Pas compartimentering toe • Leg routepaden vast • Bepaal de toegang tot de webapplicaties vanuit de backoffice • Scheid beheer- en productieverkeer • Overweeg de invoering van een dual-vendor concept • Behoud overzicht • Breng fysieke scheiding aan • Implementeer maatregelen tegen (D)DoS • Harden de (externe) DNS-infrastructuur • Harden ook de rest van de infrastructuur • Besteed aandacht aan beschikbaarheidvraagstukken Platform • Richt een solide updatemechanisme in • Verwijder onnodige services • Richt access controls strikt in • Harden de implementatie van essentiële protocollen • Maak gebruik van jailing • Hanteer strikte OS-authenticatie(mechanismen) • Maak gebruik van veilige beheermechanismen • Maak back-ups • Maak gebruik van lokale firewalls • Audit de wijzigingen op het systeem • Maak gebruik van beveiligingstemplates Applicatie • Overweeg de invoering van een application-level firewall • Voer inputvalidatie uit • Maak (extern) gebruik van SSL-verbindingen • Voorkom het lekken van informatie • Normaliseer HTTP-verzoeken • Sta alleen benodigde HTTP-methoden toe • Sta beperkt bestandsextensies toe • Controleer verzoeken tegen bekende aanvalspatronen • Controleer de inhoud van HTTP-headers • Controleer het gebruik van cookies • Richt een solide updatemechanisme in • Schakel ‘directory listings’ uit • Hanteer safe coding technieken • Voer een (geautomatiseerde) code review uit • Pas alle maatregelen op alle applicaties toe

§3.3.1 §3.3.2 §3.3.3 §3.3.4 §3.3.5 §3.3.6 §3.3.7 §3.3.8 §3.3.9 §3.3.10 §3.3.11 §3.3.12

§4.3.1 §4.3.2 §4.3.3 §4.3.4 §4.3.5 §4.3.6 §4.3.7 §4.3.8 §4.3.9 §4.3.10 §4.3.11

§5.3.1 §5.3.2 §5.3.3 §5.3.4 §5.3.5 §5.3.6 §5.3.7 §5.3.8 §5.3.9 §5.3.10 §5.3.11 §5.3.12 §5.3.13 §5.3.14 §5.3.15

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

116/116

Identiteit- en toegangsbeheer • Bepaal de plek van identiteit- en toegangsbeheer • Overweeg de invoering van I&AM tooling • Maak een gefundeerde keuze voor authenticatiemechanismen • Denk niet alleen aan inloggen • Zorg voor uniforme en flexibele authenticatiemechanismen Vertrouwelijkheid en onweerlegbaarheid • Versleutel vertrouwelijke informatie • Versleutel cookies • Maak gebruik van digitale handtekeningen Monitoring, auditing en alerting • Maak gebruik van Intrusion Detection Systemen (IDS) • Breng logging op één punt samen • Breng correlaties aan • Richt NTP correct in • Audit de uitgedeelte autorisaties regelmatig • Bepaal wat te doen bij het uitvallen van loggingmechanismen • Stel bewaartermijnen van logging vast • Voer actief controles uit op logging • Coördineer en bevorder samenwerking

§6.3.1 §6.3.2 §6.3.3 §6.3.4 §6.3.5

§7.3.1 §7.3.2 §7.3.3

§9.3.1 §9.3.2 §9.3.3 §9.3.4 §9.3.5 §9.3.6 §9.3.7 §9.3.8 §9.3.9

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009

117/116

Sign up to vote on this title
UsefulNot useful