31476268 dutch raamwerk beveiliging webapplicaties govcert

121
  RAAMWERK BEVEILIGING WEBAPPLICATIES WWW.GOVCERT.NL 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 [email protected] Auteur(s) : GOVCERT.NL Versie : 1.3 27.10.2006 Den Haa : Publieke ui t ave: 30.07.2009

Upload: bvisserprive3721

Post on 09-Jul-2015

202 views

Category:

Documents


0 download

DESCRIPTION

Dutch info sec.

TRANSCRIPT

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

RAAMWERKBEVEILIGINGWEBAPPLICATIES

WWW.GOVCERT.NL

POSTADRES

Postbus 840112508 AA Den HaagBEZOEKADRES

Wilhelmina van Pruisenweg 1042595 AN Den HaagTELEFOON

070 888 75 55FA X

070 888 75 50E-MAIL

[email protected]

Auteur(s) : GOVCERT.NL

Versie :1.327.10.2006

Den Haa : Publieke uit ave: 30.07.2009

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

GOVCERT.NLis het Computer Emergency ResponseTeam van en voor de Nederlandse overheid.Zij ondersteunt overheidsorganisaties in hetVoorkomen en afhandelen van ICT-gerelateerdeveiligheidsincidenten, 24 uur per dag, 7 dagenper week. Advies en preventie, waarschuwing,incidentafhandeling en kennisdelingzijn hierbij sleutelwoorden.

GBO.OVERHEID

is de Gemeenschappelijke Beheer Organisatiewaar GOVCERT.NL sinds 1 januari 2006 deelvan uit maakt. Zij is verantwoordelijk voorbeheer en verdere ontwikkeling van een aantaloverheidsbrede ICT-voorzieningen.

Gebruik:

Dit werk is gepubliceerd onder de voorwaarden beschreven inde Creative Commons Naamsvermelding-Niet-commercieel-Gelijk delen 3.0 Nederland licentie. Kijk voor meer informatieop http://creativecommons.org/licenses/by-nc-sa/3.0/nl/

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

INHOUD

Engl ish Summary .........................................................................................................1  1  Inleiding ..........................................................................................................2  1.1  Leeswijzer ....................................................................................................... 2 2  Raamw erk Beveil iging Webappl icaties ............................................................4 2.1  Webapplicaties................................................................................................. 4 2.2  Mogelijke kwetsbaarheden en bedreigingen.......................................................... 6 2.3  Het Raamwerk ................................................................................................. 7 2.4  Doelen............................................................................................................ 9 2.5  Scope ........................................................................................................... 10 2.6  Algemene aanbevelingen ................................................................................. 11 3  Netw erkbeve il ig ing .......................................................................................13 3.1  Inleiding........................................................................................................ 13 3.2  Mogelijke kwetsbaarheden en bedreigingen........................................................ 13 3.3  Aanbevelingen ............................................................................................... 17 4  Platformbeveil ig ing .......................................................................................30  4.1  Inleiding........................................................................................................ 30 4.2  Mogelijke kwetsbaarheden en bedreigingen........................................................ 30 4.3  Aanbevelingen ............................................................................................... 33 5  Appl icat iebevei liging .....................................................................................42  5.1  Inleiding........................................................................................................ 42 5.2  Mogelijke kwetsbaarheden en bedreigingen........................................................ 42 5.3  Aanbevelingen ............................................................................................... 52 6  Identitei t- en Toegangsbeheer ......................................................................73  6.1  Inleiding........................................................................................................ 73 6.2  Mogelijke kwetsbaarheden en bedreigingen........................................................ 75 6.3  Aanbevelingen ............................................................................................... 81 7  Ver trouw eli jkheid en onw eer legbaarhe id ......................................................88  7.1  Inleiding........................................................................................................ 88 7.2  Mogelijke kwetsbaarheden en bedreigingen........................................................ 88 7.3  Aanbevelingen ............................................................................................... 89 8  Beveil ig ings integrat ie ....................................................................................94  8.1  Inleiding........................................................................................................ 94 8.2  Mechanismen................................................................................................. 94 8.3  Aanbevelingen ............................................................................................... 98 

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

9  Monitoring, auditing en alert ing ....................................................................99 9.1  Inleiding........................................................................................................ 99 9.2  Mogelijke kwetsbaarheden en bedreigingen........................................................ 99 9.3  Aanbevelingen ..............................................................................................101 A  Referent ies ..................................................................................................110  B  Beveil igingsadvies GOVCERT.NL-2006-133..................................................111  C  Afkort ingen en def in ities .............................................................................113  D  Hoofdpunten Beveiliging .............................................................................115  

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 1/116

ENGLISH SUMMARY

This Framework for Web Application Security provides an overview of securityaspects at various layers of a web application environment; i.e. any applicationthat can be reached over HTTP. The framework describes vulnerabilities, threatsand recommendations in chapters about the following layers:

The network. This is one of the most important layers when securing webapplications and is the precondition for securing other layers. The components in

this layer should only allow essential protocols, such as HTTP and HTTPS, andblock 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 webapplication. Vulnerabilities in the operating system can have a direct impact onthe 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 applicationshas 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 (rolebased, rule based, mandatory etc), the use of two factor authentication andsession management.

Confidentiality and Integrity of information, using encryption and digitalsignatures.

Integration of the web application with various security components. Thischapter discusses ways in which a web application can retrieve information fromother components for security purposes, such as the usernames of authenticatedusers. A well designed and coherent system of components will greatly increasethe overall security.

Monitoring, auditing and logging.

The framework does not treat these layers as separate components, but rather aspart of a chain of components that all need to be secured in order to provide for asecure environment.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 2/116

1  INLEIDING

Steeds meer organisaties bieden services aan klanten aan via internet. Mengebruikt hiervoor bijvoorbeeld websites, extranetten en webservices. Met detoename aan webapplicaties gaat ook een toename aan beveiligingsincidentengepaard. 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 10beveiligingsincidenten per jaar met webapplicaties registreerden. Opvallend is dateen jaar eerder maar 5% van de respondenten aangaf meer dan 10

beveiligingsincidenten met webapplicaties te hebben meegemaakt. Verschillendeoorzaken kunnen ten grondslag liggen aan deze dramatische toename vanbeveiligingsincidenten; enkele mogelijke oorzaken zijn:

•  Het aantal webapplicaties is sterk toegenomen waardoor de kans opmisbruik ook toeneemt;

•  De monitoring van de beveiliging rondom webapplicaties is verbeterdwaardoor beveiligingsincidenten eerst niet werden opgemerkt maar nuwel;

•  Publieke exploits voor kwetsbaarheden verschijnen steeds sneller opinternet waardoor de kans op uitbuiting van deze kwetsbaarheden

toeneemt.

Ongeacht de exacte oorzaak van de toename aan incidenten is het bij hetinrichten van webapplicaties van belang dat het aspect beveiliging voldoendeaandacht krijgt. Aangezien een webapplicatie onderdeel uitmaakt van een ketenvan ict-services is het belangrijk dat de aandacht niet alleen uitgaat naar sec dewebapplicatie. Ook alle omliggende componenten (databases, logging servers,procies, etc…), waarvan de webapplicatie afhankelijk is, vervullen een belangrijkerol in het functioneren van de webapplicatie. Deze componenten dient mendaarom te betrekken in het geheel aan beveiligingsmaatregelen. Dit documentbeschrijft een raamwerk (het Raamwerk Beveiliging Webapplicaties, kortwegRBW) dat aandacht besteedt aan alle lagen van beveiliging rondom webapplicatiesen omliggende componenten.

1.1   Leeswijzer

Hoofdstuk 2 van dit document introduceert het Raamwerk BeveiligingWebapplicaties (RBW). Het raamwerk bestaat uit verschillende lagen die elk eenonderdeel van de beveiliging rondom webapplicaties behandelen. Dedaaropvolgende hoofdstukken gaan dieper in op de verschillende onderdelen vandit raamwerk. Elk hoofdstuk start met een beschrijving van het specifiekeonderdeel uit het raamwerk waarna de bedreigingen, kwetsbaarheden en

mogelijke maatregelen de revue passeren. Mocht u geïnteresseerd zijn in éénspecifiek onderdeel van beveiliging van webapplicaties dan kunt u het beste eerst

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 3/116

hoofdstuk 2 doorlezen om vervolgens één van de deelonderwerpen in meer detailte 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 manierwaarop een webapplicatie informatie over geauthenticeerde gebruikerskan 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 vanbeveiliging vanuit een ketenperspectief (tegenover beveiliging van lossecomponenten) van belang is. Door tijdens het inrichten van beveiliging vanwebapplicaties alleen beveiliging per losstaand component in te richten, ontstaat

geen optimaal beveiligde omgeving. Daarom is het, voor een juiste perceptie opbeveiliging van webapplicaties, aan te raden om het gehele document door telezen.

Dit document maakt veelvuldig gebruik van afkortingen en specifieke termen. Eenoverzicht van alle gebruikte afkortingen en termen kunt u terugvinden in bijlageC. Een puntsgewijze opsomming van alle kwetsbaarheden, bedreigingen enaanbevelingen uit dit document vindt u terug in bijlage D.

Tot slot gebruikt dit document ook voetnoten om bepaalde termen of begrippen teverduidelijken. 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 wijzegoedkeurt, afkeurt, aanraadt, afraadt of anderszins hiermee verbonden is.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 4/116

2  RAAMWERK BEVEILIGING WEBAPPLICATIES

Dit hoofdstuk introduceert het RBW. Dit raamwerk beschrijft de verschillendeaandachtspunten die aan bod moeten komen bij het beveiligen van eenwebapplicatie. Het hoofdstuk start met een beschrijving van het begripwebapplicatie 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 grotelijnen: een applicatie die bereikbaar is via een webbrowser of via een andereclient die ondersteuning biedt voor het HyperText Transfer Protocol (HTTP). Eendergelijke client noemt men een ‘HTTP user agent’. Kern van deze definitie is dateen webapplicatie altijd bereikbaar is op basis van HTTP of de versleutelde vormhiervan: HTTPS (HTTP Secure). De functionaliteit die een webapplicatie kanbieden is oneindig, de techniek is echter altijd gebaseerd op de HTTPprotocolstandaard zoals gedefinieerd in RFC 26161.

Enkele voorbeelden van applicaties die volgens deze definitie onder de noemerwebapplicatie vallen:

•  Internetsites; internetsites zijn publieke websites die voor iedereentoegankelijk zijn. Door met een browser naar een website te surfen(bijvoorbeeld www.govcert.nl) kan men informatie over een organisatieopvragen, formulieren downloaden, vragen aan de organisatie stellen,etc….

•  Extranetten; extranetten maken gebruik van dezelfde technieken alsinternetsites met het verschil dat vaak enige vorm van authenticatie enautorisatie plaatsvindt. Extranetten zijn in de regel bedoeld voor klantenvan een organisatie. Via een extranet kan een klant bijvoorbeeldopdrachten geven, statussen bekijken, documenten inzien, etc… Dekennisbank van GOVCERT.NL (kennisbank.govcert.nl) is een voorbeeld vaneen extranet.

•  Intranetten; ook intranetten maken gebruik van dezelfde technieken alsinternetsites. Intranetten zijn echter alleen bedoeld voor internemedewerkers van een organisatie en bieden bijvoorbeeld de mogelijkheidom interne berichten te verspreiden. Intranetten zijn veelal alleen vanuitde infrastructuur van de eigen organisatie te bereiken.

1 Zie: http://rfc.net/rfc2616.html

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 5/116

•  Webservices; de voorgaande typen webapplicaties maken allen gebruikvan HyperText Markup Language (HTML) om te communiceren met degebruiker. HTML maakt het mogelijk om webpagina’s op te maken en weerte geven in een webbrowser. Webservices maken geen gebruik van HTMLmaar van eXtensible Markup Language (XML). SOAP is één van de meestgebruikte standaarden om invulling te geven aan een webservice. XMLbevat geen lay-out informatie zoals bij HTML, maar bevat informatie in eengestructureerde, vooraf gedefinieerde, vorm. Webservices verbinden in deregel applicaties met elkaar en baseren informatie-uitwisseling tussen dezeapplicaties op het gebruik van XML-berichten. De RSS2-feed van DeWaarschuwingsdienst (http://www.waarschuwingsdienst.nl/rss.xml) is een

voorbeeld van een webservice.

Hoewel webapplicaties normaal gesproken gebruik maken van de standaard TCP-poorten (80/tcp voor HTTP, 443/tcp voor HTTPS) kan een webapplicatie ookgebruik maken van een andere poort (bijvoorbeeld 8080/tcp). In dat gevalspreken we nog steeds van een webapplicatie aangezien de applicatie tebenaderen is op basis van standaard HTTP-berichten.

ACHTERGROND Om de verschillende dreigingen, kwetsbaarheden envoorgestelde maatregelen in dit document goed te kunnen begrijpen, is het vanbelang enige basiseigenschappen van HTTP goed te begrijpen. Hieronder volgen

de belangrijkste eigenschappen van HTTP:

•  HTTP werkt met vraag- (HTTP-request) en antwoordberichten (HTTP-response);

•  In de meeste gevallen is communicatie via HTTP synchroon van aard: declient stuurt en vraag en ontvangt, in dezelfde sessie, onmiddellijk eenantwoord van de server. In sommige gevallen is de actie die de servermoet uitvoeren dusdanig complex dat deze niet binnen een bepaalde time-out kan reageren. In dit soort gevallen bestaat de mogelijkheid om over teschakelen op asynchrone communicatie. Hierbij ontvangt de client hetantwoord van de server via een aparte sessie. Een overeenkomstig

kenmerk in het vraag- en antwoordbericht is in deze gevallen benodigd omvraag en antwoord aan elkaar te kunnen koppelen. Sommige webservicesmaken gebruik van asynchrone communicatie;

•  Elk HTTP-bericht bestaat uit een kop en een bericht (HTTP-payload). Dekop bevat o.a. de zogenaamde HTTP-headers. HTTP-headers bevattenmeta-informatie over het bericht zoals het type payload (bijvoorbeeldtekst, HTML, XML, etc…), het gebruikte type webserver, de naam van dete bevragen host, de inhoud van een cookie, etc…

•  HTTP is stateless. Dit betekent dat elk vraag-antwoordkoppel los vanelkaar staat. De webserver beantwoordt elk vraagbericht daaromonafhankelijk 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

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 6/116

•  Omdat statusbehoud wel van belang is (bijvoorbeeld het onthouden vanauthenticatieinformatie) hebben ontwikkelaars via speciale mechanismenstatusinformatie ingebouwd in HTTP. Cookies vormen één van demogelijkheden om deze status te behouden.

•  Een typisch vraag-antwoordkoppel ziet er als volgt uit:

•  Om HTTP-berichten versleuteld over internet te sturen kan men gebruikmaken van SSL (HTTPS). SSL kan tevens wederzijdse authenticatieverzorgen: de server authenticeert zich (bewijst zijn identiteit) middelseen server certificaat, de gebruiker via een client certificaat. In veelgevallen past men bij SSL-authenticatie alleen authenticatie van de servertoe.

2.2   Mogelijke kwetsbaarheden en bedreigingen

Een webapplicatie heeft te maken met een groot aantal mogelijke

kwetsbaarheden en bedreigingen. Deze kwetsbaarheden en bedreigingenbevinden zich op verschillende niveau’s; hierbij kan men denken aankwetsbaarheden en bedreigingen op netwerkniveau (bv. Denial-of-Service), opauthenticatieniveau (bv. omzeilen van authenticatiemechanismen) of opapplicatieniveau (bv. Cross-Site Scripting). Deze kwetsbaarheden en bedreigingenkrijgen een plek in het RBW en komen aan de orde bij de beschrijving van deafzonderlijke 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 totbeveiligingsproblemen leiden. In andere gevallen denkt men wel na overde configuratie, maar doen zich fouten voor bij het daadwerkelijk

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 7/116

implementeren van de configuratie. Ook in het laatste geval kunnenbeveiligingsproblemen het resultaat zijn.

•  Aanwezigheid van bekende kwetsbaarheden; dagelijks verschijnen opinternet beveiligingsadviezen van verschillende leveranciers waarin deleverancier een kwetsbaarheid in één van zijn softwareproductenbeschrijft. Zodra de ontdekker of de leverancier details over een dergelijkekwetsbaarheid bekend maakt, is het veelal een kwestie van tijd voordatpublieke code verschijnt waarmee kwaadwillenden deze kwetsbaarheid opeenvoudige manier kunnen misbruiken. Het is dan zaak om tijdig de doorde leverancier aangeleverde updates te installeren om de kwetsbaarheid te

verhelpen.

•  Aanwezigheid van nieuwe (0-day) kwetsbaarheden; wanneer niet deleverancier maar een derde (bijvoorbeeld een hacker) een kwetsbaarheidbekend maakt, en de leverancier niet in staat is gesteld om updates voorzijn software uit te brengen, dan spreekt men van een 0-day kwetsbaarheid. Aangezien organisaties een dergelijke kwetsbaarheid nietkunnen verhelpen door updates te installeren, is men afhankelijk vanwork-arounds en de effectiviteit en haalbaarheid van deze work-arounds.Kwaadwillenden maken dankbaar misbruik van 0-day kwetsbaarheden omaanvallen op webapplicaties uit te voeren.

Voor zowel bekende als 0-day kwetsbaarheden geldt dat kwaadwillenden vaak opbasis van specifieke eigenschappen kunnen zoeken naar kwetsbarewebapplicaties. Zoekmachines als Google kunnen de kwaadwillende hierbij vannut zijn (‘Google Hacking’).

2.3   Het Raamwerk

In figuur 2-1 is het RBW weergegeven. Het raamwerk bevindt zich hierbij logischgezien tussen een client en een webapplicatie.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

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

Figuur 2-1: Raamwerk Beveiliging Webapplicaties

Zoals uit het raamwerk van figuur 2-1 is op te maken bestaat de beveiliging vanwebapplicaties uit verschillende (beveiligings)lagen. Bekeken vanaf de clientverschijnen achtereenvolgens de volgende lagen:

•  Netwerkbeveiliging ; beveiliging die zich met name richt op hetafschermen van informatiestromen op het transport-/netwerkniveau.

•  Platformbeveiliging; richt zich op het beveiligen van de verschillendeplatformen (besturingssystemen) waarvan webapplicaties – enaanverwante componenten zoals databases – gebruik maken.

•  Applicatiebeveiliging; richt zich op het beveiligen van de webapplicatieen het applicatieplatform3. Applicatiebeveiliging hoeft geen geïntegreerdonderdeel van de applicatie zelf te zijn, maar kan ook als losstaandcomponent functioneren binnen de infrastructuur van de webapplicatie.Een application-level firewall is een typisch losstaand component dat geengeïntegreerd onderdeel van de applicatie uitmaakt, maar welbeveiligingservices biedt voor deze applicatie.

•  Identiteitbeheer; identiteitbeheer richt zich o.a. op het authenticerenvan gebruikers van webapplicaties. Daarnaast is ook het beheren van dezeidentiteiten een belangrijke functie.

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

Websphere server

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 9/116

•  Toegangsbeheer; binnen toegangsbeheer worden rechten toegekend opbasis van de identiteit van een gebruiker. Afhankelijk van de rechten vande identiteit mag een gebruiker wel of geen gebruik maken van (delenvan) de webapplicatie.

•  Vertrouwelijkheid en onweerlegbaarheid; vertrouwelijkheid enonweerlegbaarheid richten zich op het versleutelen van vertrouwelijkegegevens en op de onweerlegbaarheid van transacties die gebruikers viade 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 dewebapplicatie(s) met de beveiligingsoplossingen uit de verschillendebeveiligingslagen. Via correct ingerichte beveiligingsintegratie kan eenwebapplicatie bijvoorbeeld de services van een toepassing die zich richt ophet toegangsbeheer benaderen.

•  Monitoring, auditing en alerting; deze laag richt zich op het monitorenvan de werking van de verschillende componenten uit de horizontalelagen. Daarnaast houdt deze laag zich bezig met het vastleggen van

belangrijke acties die plaatsvinden binnen de omgeving van dewebapplicatie en het uitsturen van alarmmeldingen op het moment datzich afwijkende (mogelijk schadelijke) gebeurtenissen voordoen.

Als laatste is in figuur 2-1 het informatiebeveiligingsbeleid afgebeeld. Dit beleid isleidend voor de invulling van de verschillende andere onderdelen van hetraamwerk. Dit informatiebeveiligingsbeleid komt in dit document verder niet aande orde omdat een organisatie bij het implementeren van de maatregelen uit hetRBW al over een dergelijk beleid dient te beschikken.

2.4   Doelen

Het RBW kent de volgende doelen:

•  Dienen als referentiepunt voor het implementeren vanbeveiligingsmaatregelen rondom webapplicaties;

•  Bereiken van samenhang tussen gekozen beveiligingsoplossingen voorwebapplicaties;

•  Bereiken van hergebruik van beveiligingsoplossingen zodat niet elkewebapplicatie een nieuwe beveiligingsoplossing introduceert;

•  Bevorderen van snelheid en kwaliteit in de implementatie vanbeveiliging voor webapplicaties (en daarmee het bevorderen van snelheid

en kwaliteit in de implementatie van webapplicaties).

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 10/116

Implementatie van het RBW moet ertoe leiden dat de mogelijkheid tot misbruikvan de webapplicatie tot een minimum beperkt wordt. Dit alles moet ervoorzorgen dat kwaadwillenden er niet in slagen om hackpogingen op de webapplicatieuit 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 aantalaspecten van informatiebeveiliging geen onderdeel uitmaken van het raamwerk.Het raamwerk besteedt bijvoorbeeld geen aandacht aan zaken alsbeveiligingsorganisatie, fysieke beveiliging en personeel.

Veel van de zaken die dit document behandelt, zijn niet alleen van toepassing opwebapplicaties maar ook op andere soorten applicaties. Het is daaromonvermijdelijk dat het document naast specifieke beveiligingsoplossingen voor

webapplicaties ook algemene beveiligingsoplossingen beschrijft die het beveiligenvan webapplicaties vereist.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 11/116

Het raamwerk houdt zich bezig met allerlei zaken die zich binnen een webhostingomgeving kunnen afspelen. Het is goed mogelijk dat voor een webhostingomgeving afwijkende regels en standaarden gelden dan voor een regulierkantoornetwerk. Zo kunnen bijvoorbeeld afwijkende hardenings- enbeschikbaarheidseisen voor servers gelden. In sommige gevallen is dewebhostingomgeving zelfs extern ondergebracht en maakt de omgeving geenonderdeel uit van het netwerk van de organisatie. Figuur 2-3 illustreert deinfrastructuur waarin een webhostingomgeving zich kan bevinden en deafbakening 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 hetoogpunt van de aanbiedende partij (de serverzijde). Het raamwerk besteedtdaarom geen aandacht aan de manier waarop afnemende partijen (dewerkstations) 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 eenvoldoende niveau te kunnen brengen. Een aantal aanbevelingen is echteralgemener van aard en is van toepassing op alle lagen uit het RBW. Het gaat omde volgende aanbevelingen:

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 12/116

•  Test; voordat men een webapplicatie in productie plaatst, is het vanbelang dat men eerst een uitgebreide test uitvoert op de webapplicatie ende omliggende infrastructuur. Vanuit beveiligingsoptiek is het van belangdat men bij het uitvoeren de test controleert of de webapplicatie en/of deinfrastructuur op enigerlei wijze is binnen te dringen of te misbruiken. Hetuitvoeren van testen is niet alleen belangrijk bij de initiële ingebruiknamevan de webapplicatie, maar ook na het doorvoeren van belangrijkewijzigingen in de webapplicatie of de infrastructuur.

•  Bepaal een baseline en monitoor; aanvallen op de omgeving enmisbruik van webapplicaties herkent men in de regel aan afwijkende acties

die plaatsvinden binnen de infrastructuur. Zonder een vooraf gedefinieerdebaseline en juist ingerichte monitoring is het lastig om te bepalen of eensituatie op een bepaald moment afwijkt van de “normale” situatie. Zietmen bijvoorbeeld een groot aantal clients verkeer richting de omgevinginitiëren, waarbij dit verkeer de volledige beschikbare bandbreedteopslokt, dan is het de vraag of het hier gaat om een Distributed Denial-of-Service (DDoS) aanval of dat het ‘gewoon’ druk is. Zonder informatie overde bandbreedte die normaal in gebruik is, is dit onmogelijk te bepalen.

•  Wees voorbereid; een organisatie kan een groot aantal maatregelentreffen om misbruik van systemen tot een minimum te beperken. Ondanks

al deze maatregelen is het niet uitgesloten dat een kwaadwillende er inslaagt om door te dringen tot een systeem. Daarom is het van belang dateen organisatie altijd is voorbereid op dit soort zaken. Het opstellen vaneen incident response procedure, incl. inbedding hiervan binnen deorganisatie (via bijvoorbeeld een Security Incident Response Team –SIRT), is essentieel om de schade bij een dergelijk incident tot eenminimum te kunnen beperken.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 13/116

3  NETWERKBEVEILIGING

Netwerkbeveiliging vormt de onderste laag van het RBW. Het netwerk maaktcommunicatie met de webapplicatie via internet mogelijk. Het uitvallen van hetnetwerk of een succesvolle aanval daarop kan daarom ook ernstige gevolgenhebben voor de beschikbaarheid van de webapplicatie. Dit hoofdstuk gaat dieperin op bedreigingen en aanbevelingen op het gebied van netwerkbeveiliging voorwebapplicaties.

3.1   Inleiding

Het afschermen van het netwerk is één van de belangrijkste aandachtsgebiedenbij het aanbieden van webapplicaties. Het juist afschermen van de verschillendecomponenten op netwerkniveau is randvoorwaardelijk voor het kunnen invoerenvan andere beveiligingscomponenten. Gezien vanaf het internet laten decomponenten uit de laag netwerkbeveiliging alleen essentiële internetprotocollendoor (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 vanbeveiligingstechnologieën op dit gebied, gecombineerd met een groeiendbewustzijn bij organisaties, nemen aanvallen op netwerkniveau steeds verder af.Aanvallen die echter gebruik maken van valide netwerkverkeer nemendaarentegen steeds verder toe (aanvallen op applicatief niveau – zie hoofdstuk 5).Desalniettemin is het van essentieel belang dat een organisatie zijn netwerkafdoende beveiligt.

3.2   Mogelijke kwetsbaarheden en bedreigingen

Deze paragraaf beschrijft mogelijke kwetsbaarheden en bedreigingen opnetwerkniveau die mogelijk van belang zijn voor webapplicaties.Achtereenvolgens komen aan de orde: (Distributed) Denial-of-Service, serverhopping, 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.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 14/116

3.2 .1   (D i s t r i bu t ed ) Den ial - o f -Se rv i ce  5 

Denial-of-Service-aanvallen (DoS) zijn aanvallen op een systeem of dienst met alsdoel een systeem, dienst of netwerk zo te belasten dat deze uitgeschakeld wordtof niet meer beschikbaar is. Meestal geschiedt dit door excessief gebruik te makenvan een op zich legitiem internetprotocol, bijvoorbeeld het opzetten van een TCP-sessie.

Een Denial-of-Service-aanval kan worden geïnitieerd vanaf een enkel systeem,maar ook vanaf meerdere systemen tegelijkertijd. Een Denial-of-Service aanvalvanaf meerdere systemen wordt een Distributed Denial-of-Service (DDoS) aanvalgenoemd.

Over het algemeen gelden de volgende eigenschappen voor een Denial-of-Serviceaanval:

•  Poging om een netwerk te overspoelen met dataverkeer, waarmeelegitiem 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, Syslog-

aanval en E-mailbombing.

3.2 .2    Serve r hopp ing  

Het succesvol compromitteren van een server in de internetomgeving kan op zichal tot ernstige schade leiden. Wanneer een kwaadwillende zich via degecompromitteerde server echter ook nog toegang kan verschaffen tot andereservers en netwerkcomponenten die zich in de omgeving van degecompromitteerde machine bevinden (‘server hopping’), loopt de schade alleennog maar verder op. De kans op ‘server hopping’ is met name aanwezig in platteomgevingen waarin alle servers in één logisch segment zijn geplaatst. In deze

omgevingen vervult een centrale firewall een essentiële rol en zal decompromittering van deze firewall of een component achter de firewall toternstige consequenties leiden. Figuur 3-1 bevat een voorbeeld van eeninfrastructuur waarin ‘server hopping’ mogelijk is door de plaats van de firewall enhet gebrek aan compartimentering van de achterliggende infrastructuur.

5

Onderstaande tekst is ontleend aan het whitepaper “Aanbevelingen ter bescherming tegen Denial-of-Serviceaanvallen” 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)

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 15/116

Figuur 3-1: server hopping

In figuur 3-1 scheidt één enkele firewall het internet en de webhosting omgevingvan elkaar. Op het moment dat een kwaadwillende de beperkingen van de firewall

weet te omzeilen – door de kwetsbare machine te comprimmiteren – beschiktdeze vervolgens over de ‘keys to the kingdom’: vanaf de gecomprommiteerdemachine kan de kwaadwillende zonder tussenkomst van een firewall alleomliggende machines benaderen.

3.2 .3    Kw etsba re DNS(con f i gu ra t i e )

Domain Name Services (DNS) zijn zeer belangrijke services voor webapplicaties.Zonder de beschikbaarheid van DNS kunnen gebruikers een website niet op basisvan bekende hostnamen (bijvoorbeeld www.overheid.nl) bereiken. Problemen metDNS leiden daarom in veel gevallen tot een webapplicatie die nog welbeschikbaar, 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 voorzaken als hijacking en spoofing (een client die zich voordoet als een andereclient). UDP maakt namelijk geen gebruik van de 3-way handshake van TCP (SYN-SYN/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 DNS-services 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 

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 16/116

•  Toestaan van zone transfers; informatie over servers in een bepaalddomein slaat DNS op in een zogenaamde zone. Via zone transfers kunnenclients alle DNS-informatie over een bepaalde zone opvragen. Deze zonetransfers zijn in principe bedoeld om primaire en secundaire DNS-serversgesynchroniseerd te houden. Wanneer willekeurige clients zone transferskunnen uitvoeren richting de DNS-server, betekent dit dat iedereen alleinformatie uit een zone kan opvragen. Een kwaadwillende kan dezeinformatie misbruiken om de omgeving waarin de webapplicatie zichbevindt 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 DNS-verzoeken moet verwerken, kan dit ertoe leiden dat de DNS-server nietmeer in staat is om te reageren op verzoeken.

•  DNS cache poisoining; DNS cache poisoining kan zich voordoen opservers die naast de eigen authoritieve domeinen7 ook andere (niet-authoritieve) domeinen ondersteunen (caching servers). De kwetsbaarheidbestaat eruit dat een kwaadwillende in staat is om foutieve DNS-informatiete injecteren in de cache van de DNS-server. Hierdoor kan het gebeurendat een gebruiker een foutief IP-adres geretourneerd krijgt bij het DNS-verzoek voor een bepaalde hostnaam. Het gevolg hiervan is dat de

gebruiker verbinding maakt met een verkeerde webserver. Eenkwaadwillende kan cache poisoining misbruiken om bijvoorbeeld phishing-aanvallen uit te voeren.

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

3.2 .4    Kwetsba re f i r ewa l l ( con f i gu ra t i e )

Firewalls vormen een essentieel component in de beveiliging tegen aanvallen opwebapplicaties. Door de belangrijke rol die een firewall vervult, is het ook gelijkeen kwetsbaar element in de beveiligingsketen. De volgende zaken vormen eenrisico bij het gebruik van firewalls:

•  De organisatie redeneert: “w e hebben een firewall, dus we zijn

veilig” . De redenering dat de inzet van een firewall de enigebeveiligingsmaatregel is die men vanuit beveiligingsoogpunt hoeft teimplementeren, is een verkeerde en kan leiden tot een misplaatst gevoelvan 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 zonefilebehorende 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’).

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 17/116

men niet los zien van andere beveiligingsmaatregelen.

•  De firewall is geconfigureerd als router. Op een firewall kan menzoveel verbindingen toestaan als men maar wil. Door een rulebase8 tecreëren die al het mogelijke verkeer toestaat, functioneert de firewall meerals router dan als firewall. Ook hier geldt dat de firewall in dit geval eenmisplaatst gevoel van veiligheid kan geven.

•  Men ziet door de bomen het bos niet meer. Aangezien firewalls eencentrale rol innemen binnen een infrastructuur kan het op een gegevenmoment gebeuren dat er zoveel verkeer door de firewall heen gaat dat

beheerders het overzicht kwijt raken. Wijzigingen doorvoeren op eendergelijke firewall is dan een vrijwel onmogelijke taak. In dit soort gevallenkan een medewerker geneigd zijn meer verbindingen toe te staan dandaadwerkelijk noodzakelijk is.

•  Kwetsbaarheden in firewalls. Ook firewalls kunnen kwetsbaarhedenbevatten. Een kritieke kwetsbaarheid op een firewall kan, door de veelalcentrale plaatsing van de firewall, ernstige gevolgen hebben.

•  Onduidelijke wensen. Projecten die tot doel hebben een bepaaldewebapplicatie te implementeren hebben niet altijd helder welke

verkeersstromen voor de specifieke webapplicatie door een firewallbenodigd zijn. Het kan daardoor gebeuren dat het project meerverkeersstromen aanvraagt dan daadwerkelijk noodzakelijk is.

3.3   Aanbevelingen

Deze paragraaf besteedt aandacht aan de maatregelen die een organisatie kantreffen om netwerkbeveiliging voor webapplicaties in te richten. Aangezien hetnetwerk een generiek ‘onderstel’ is voor alle mogelijke toepassingen zijn veelmaatregelen niet specifiek gericht op de beveiliging van webapplicaties maar meerop de algemene beveiliging van de infrastructuur rondom de webapplicatie.

3.3 .1   Bes teed vee l aandach t aan h e t DM Z-on tw erp  

Een Demilitarised Zone (DMZ) is een apart stuk netwerk dat specifiek bedoeld isom webapplicaties – en andere vanaf het internet bereikbare applicaties – inonder te brengen. De DMZ vormt de koppeling tussen het internet enerzijds enhet interne netwerk anderzijds. Een veilige inrichting van de DMZ is daarom vangroot belang om te voorkomen dat kwaadwillenden via internet toegang krijgentot 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.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 18/116

Een aantal verschillende overwegingen moeten als input dienen voor het ontwerpvan de DMZ. Enkele belangrijke overwegingen die hierbij een rol kunnen spelenzijn:

•  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 hierbijeen centrale ingang en een centrale uitgang. Daarnaast is te zien dat de DMZbestaat uit verschillende compartimenten die allen een andere gradatie (gekleurd

bolletje) hebben meegekregen. De komende paragrafen beschrijven dezeverschillende onderdelen in meer detail.

Figuur 3-2: inrichting DMZ

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 19/116

3.3 .2    Pas com par t im en te r i ng t oe  

Rondom de firewall(s) in de DMZ kan men segmenten of compartimenten creëren.Uitgangspunt kan hierbij zijn dat applicaties en toepassingen van een gelijkbeveiligingsniveau in één gezamenlijk segment terecht komen. Zo komenbijvoorbeeld web proxies in één segment, webservers voor internetsites in éénsegment, webservers voor extranetten in één segment, databases in éénsegment, etc… Door deze compartimentering toe te passen zorgt men ervoor datcompromittering van een server of applicatie in een compartiment geen directegevolgen hoeft te hebben voor servers of applicaties in een ander compartiment.Daarnaast kan men via deze compartimentering onderscheid maken in servers diewel rechtstreeks vanaf internet bereikbaar zijn (bijvoorbeeld webservers) enservers 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 debackoffice geplaatst zijn, vormen een zeer ernstig beveiligingsrisico. Webserversdienen daarom altijd via minimaal één firewall gescheiden te zijn van debackoffice.

3.3 .3    Leg r ou tepaden vas t  

De vastgestelde compartimentering van de DMZ vormt de basis voor het opstellenvan routepaden. Een routepad beschrijft een toegestane verkeersstroom door deDMZ. Figuur 3-2 geeft een voorbeeld van twee routepaden die de DMZ toestaat.Verkeer richting een internetsite verloopt hierbij altijd via internet (rood), eenproxy segment (rood/oranje), een tussensegment (oranje) en het websegment(groen). Verkeer richting een extranet volgt in grote lijnen dezelfde weg maarmaakt vanaf het tussensegment (oranje) eerst nog een afslag richting eenauthenticatie- en autorisatiesegment (oranje/groen) alvorens bij de webserver tegeraken.

Door routepaden vast te stellen verzekert men zich ervan dat het omzeilen vanverplichte beveiligingsmechanismen niet mogelijk is. Daarnaast beschrijft men op

deze manier tevens een soort ‘template rulebase’ die de opzet vanverkeersstromen bepaalt voor nieuwe webapplicaties.

3.3 .4    Bepaa l de t oegang t o t de w ebapp l i ca t i es vanu i t de backo f f i ce  

Veel van de webapplicaties die een organisatie ondersteunt, moeten ookbereikbaar zijn vanaf het interne netwerk. Om deze koppeling tot stand tebrengen heeft men de beschikking over grofweg twee alternatieven:

•  Routeer verkeer vanuit de backoffice via de internetkoppeling naarinternet en vervolgens weer terug naar de eigen DMZ. Bij dit alternatief 

komt het erop neer dat men de webapplicaties vanuit de backoffice opeenzelfde manier benadert als alle andere webapplicaties op internet. Eenargument dat tegen dit alternatief spreekt, is dat het onzinnig lijkt om

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 20/116

intern verkeer via het (externe) internet te routeren.

•  Routeer verkeer vanuit de backoffice rechtstreeks naar de webservers inde DMZ.

De keuze voor het tweede alternatief brengt een aantal beveiligingsrisico’s metzich mee. Doordat een rechtstreekse koppeling ontstaat tussen het internenetwerk en de DMZ, kan het gebeuren dat interne medewerkers mogelijkebeveiligingsbeperkingen die zijn opgelegd door componenten in de DMZ(onbedoeld) omzeilen. Aangezien aanvallen op webapplicaties zeker ook internhun oorsprong kunnen vinden, is het van belang om de vastgestelde routepaden

ook voor intern verkeer te bekrachtigen. Hierdoor zal intern verkeer in grote lijnendezelfde weg moeten volgen als internetverkeer met als gevolg dat intern verkeerop dezelfde plek de DMZ moet binnenkomen als regulier internetverkeer (op eenaparte tak op de buitenste firewall). Figuur 3-3 beschrijft de twee opties die indeze 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 hetinternet van elkaar scheiden. Wanneer de werkstations een rechtstreekseverbinding met de buitenste firewall zouden hebben, zou namelijk een nieuwbeveiligingsrisico kunnen ontstaan. In dit geval zou er zich namelijk maar éénfirewall bevinden tussen het internet en het interne netwerk waardoor eventuelekwetsbaarheden en configuratiefouten op deze firewall tot grotebeveiligingsproblemen zouden leiden.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 21/116

3.3 .5    Sche id beheer - en produc t iever keer  

In het DMZ-ontwerp van figuur 3-2 is een onderscheid gemaakt tussen een ‘productie’-gedeelte (oranje lijnen) en een beheergedeelte (grijze lijnen/zwartebolletjes). Het productiegedeelte is in feite het gedeelte van de DMZ waaropverkeer vanaf internet terecht komt. Het onderscheid is aangebracht om tevoorkomen dat beheer- en productieverkeer door elkaar heen gaan lopen. Beheerwerkt vaak via webinterfaces en door beheer toe te staan via hetproductiegedeelte loopt men het risico dat ook de bijbehorende webinterfaces enandere beheervoorzieningen te benaderen zijn vanaf het internet.

Scheiding van beheer en productie betekent dat servers minimaal tweenetwerkaansluitingen krijgen: één voor aansluiting op het productiegedeelte enéén voor aansluiting op het beheergedeelte.

OPMERKING Het is belangrijk dat de compartimentering die is aangebracht inhet productiegedeelte ook terugkomt in het beheergedeelte. Is dit niet het gevaldan kan een kwaadwillende via het beheergedeelte de compartimentering alsnogomzeilen.

Het beheernetwerk kan tijdens kantooruren ondersteuning bieden voor hetuitvoeren van reguliere beheerwerkzaamheden (bijvoorbeeld SSH-verbindingenopzetten met systemen). Aangezien beheerwerkzaamheden ’s nachts meestal niet

plaatsvinden, kan men buiten kantooruren over dit netwerkgedeelte back-upslaten lopen zonder daarbij het productieverkeer in de weg te zitten.

Een laatste belangrijk aandachtspunt is te bepalen hoe beheerders toegangkrijgen tot het beheergedeelte. Hiertoe bestaan verschillende mogelijkheden:

•  Implementeer beheerclients in het beheergedeelte die alleen te gebruikenzijn door er via een afgeschermde ruimte achter plaats te nemen. Beheerover de omgeving kan alleen plaatsvinden via deze fysiek afgeschermdebeheerclients.

•  Implementeer beheerclients in het beheergedeelte die op basis van een

remote interface (bijvoorbeeld Citrix of Microsoft RDP) te benaderen zijnvoor een beperkte groep werkstations in het backoffice LAN. Beheerdersmaken vanaf hun werkstation in het LAN een verbinding met debeheerclients en kunnen vervolgens via deze beheerclients het beheerover de omgeving uitvoeren.

•  Implementeer een apart beheer-LAN in het backoffice LAN en staverbindingen richting het beheergedeelte alleen toe vanuit dit beheer-LAN.

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

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 22/116

3.3 .6    Overw eeg de i nvoe r i ng van een dua l - vendo r concep t  

Door de centrale plaatsing van de firewall(s) kan een kwetsbaarheid op dezefirewall(s) grote gevolgen hebben (zie 3.2.4). Om de schade bij een dergelijkekwetsbaarheid te beperken kan men overwegen een dual-vendor concept teimplementeren. Het dual-vendor concept houdt in dat twee firewalls denetwerkbeveiliging in de DMZ uitvoeren en dat deze firewalls van verschillendemakelij zijn. In figuur 3-2 gebruikt het productiegedeelte van de DMZ tweeverschillende firewalls. Eén firewall is rechtstreeks aangesloten op internet, deandere op de backoffice. Zouden deze firewalls van dezelfde makelij zijn dan zaleen potentiële kwetsbaarheid ook op beide systemen aanwezig zijn. Eenkwaadwillende kan hierdoor, na het compromitteren van de eerste firewall, opeenzelfde manier mogelijk ook de tweede firewall compromitteren. Doorverschillende (merken) firewalls in te zetten voorkomt men dit.

OPMERKING Het toepassen van een dual-vendor concept hoeft niet automatischte betekenen dat men twee typen centrale firewalls in de omgeving plaatst. Ditconcept kan men bijvoorbeeld ook invullen door, naast de centraal geplaatstefirewalls, 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 overz ich t  

Het is belangrijk dat beheerders overzicht behouden over de verkeersstromen diede firewall toestaat. Bij nieuwe verkeersstromen moet de beheerder debijbehorende toegangsregels efficiënt inpassen in de bestaande rulebase.Projecten moeten daarnaast een helder en gefundeerd overzicht aanleveren vande verkeersstromen die de te implementeren webapplicatie nodig heeft. Hetgebruik van speciaal daartoe ontwikkelde ‘verkeersoverzichten’ kunnen hieraaneen bijdrage leveren. Een voorbeeld van een dergelijk verkeersoverzicht isweergegeven in figuur 3-4.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 23/116

Figuur 3-4: voorbeeld verkeersoverzicht

Het verkeersoverzicht bevat ten eerste alle firewalls en servers die betrokken zijnbij het aanbieden van de webapplicatie. Dit betekent dat naast de webserver ookandere servers waarvan de webapplicatie gebruik maakt (zoals databaseservers),onderdeel uitmaken van het verkeersoverzicht. Vervolgens tekent men deverkeersstromen tussen de componenten in. Hierdoor ontstaat een overzicht van

de regels die op de firewalls benodigd zijn om de webapplicatie te kunnen latenfunctioneren.

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 vaninfrastructurele wijzigingen. Het aanbrengen van bijvoorbeeld nieuweverbindingen tussen netwerkcomponenten kan ervoor zorgen dat routepaden encompartimenteringen plotseling (in negatieve zin) wijzigen.

3.3 .8    Breng fy s ieke sche id ing aan 

Door veel aandacht te besteden aan de inrichting van de DMZ (zie 3.3.1) ontstaateen logische scheiding van netwerksegmenten rondom de firewall(s). Dezelogische scheiding hoeft niet per definitie ook een fysieke scheiding vannetwerksegmenten te betekenen. Verschillende netwerkcomponenten, servers enandere apparatuur kunnen immers wel zijn aangesloten op dezelfde switch of hubwaardoor een fysieke koppeling ontstaat. Door deze fysieke koppeling tussencomponenten is het in sommige gevallen mogelijk om de logische segmenteringvan het netwerk via deze netwerkcomponenten te omzeilen.

Het risico dat kwaadwillenden in staat zijn om via fysieke (laag 2) koppelingen delogische (laag 3) segmentering te omzeilen, is in de praktijk vrij klein. Een kleine

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 24/116

ingreep op de belangrijkste ingangspunten van de DMZ voorkomt dit echter. Infiguur 3-5 is (rechts) een voorbeeld opgenomen van een fysieke scheiding tussentwee belangrijke segmenten. Daarnaast is in het figuur ook het verschilweergegeven 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 teplaatsen. Dit betekent dat de proxies twee interfaces krijgen: één interface voorde buitenkant en één interface voor de binnenkant. Al het verkeer van en naar dewebapplicatie is in dit geval verplicht om via de proxy te lopen. Het nadeel vaneen dergelijke plaatsing van een proxy is dat alle applicaties via deze proxymoeten verlopen waardoor men afhankelijk is van ondersteuning van de proxyvoor 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 typenapplicaties die de organisatie via de DMZ ontsluit. Meer details over (web) proxieskunt u terugvinden in het hoofdstuk over applicatiebeveiliging (hoofdstuk 5).

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

3.3 .9    I m p l e m e n t e e r m a a t r eg e le n t e g e n ( D ) D o S  

Het whitepaper “Aanbevelingen ter bescherming tegen Denial-of-Service-aanvallen” (DDoS-GOVCERT, 2005) beschrijft een aantal maatregelen die eenorganisatie 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:

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 25/116

o  Unicast Reverse-Path Forwarding (uRPF); URPF controleert op eeninterface of een IP-pakket afkomstig is van een source IP-adres datvolgens de routeringstabel bereikbaar is via de betreffende interface.

o  Bogon lists; via bogon lists kan men IP-adressen die nog niet doorIANA zijn uitgegeven blokkeren.

o  Access Control Lists (ACL); reguleren dataverkeer op basis vanbijvoorbeeld 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 (ex te rne ) DNS- i n f ras t ruc tuu r  

Door de vitale rol die DNS speelt in het bereikbaar houden van webapplicaties, ishet belangrijk dat het aspect beveiling bij de inrichting van DNS-services vooropstaat. 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 hiertoegerechtigd mogen zijn.

•  Sta via de firewall alleen verkeer toe richting 53/udp. Vrijwel alle DNS-verzoeken maken gebruik van UDP. Alleen bij zeer grote verzoeken enzone transfers zal DNS overschakelen op het gebruik van TCP. Door 53/tcpte blokkeren in de firewall, voorkomt men dat willekeurige IP-adressen instaat 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 kwaadwillendealleen extra informatie.

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

3.3 .11   Harden ook de res t van de i n f r as t ruc tuu r  

De vorige aanbeveling (3.3.10) beschreef de specifieke hardening van DNS-servers. Hardening is een begrip dat bij de inrichting van webomgevingen op elkcomponent van toepassing is. Daarom moeten ook firewalls, switches, routers en

andere netwerkcomponenten deel uitmaken van het hardeningsproces.Onderstaand volgen enkele voorbeelden van mogelijke hardeningsmaatregelen opnetwerkniveau:

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 26/116

•  Sluit beheermogelijkheden zoveel mogelijk af. Biedt webinterfaces alleenaan via beheersegmenten.

•  Maak alleen gebruik van versleutelde beheermechanismen. Maak dusbijvoorbeeld gebruik van Secure Shell (SSH) in plaats van Telnet enSecure 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 decomponenten.

•  Maak gebruik van logon banners. Een logon banner verschijnt op het

moment dat een gebruiker een beheersessie opstart met eennetwerkcomponent. Deze banner bevat een waarschuwing die detoegangsvoorwaarden tot het systeem beschrijft. De banner kan daarnaastwaarschuwen voor juridische acties wanneer de gebruiker misbruik vanhet systeem maakt.

•  Harden het onderliggende besturingssysteem. Veel leveranciers leverennetwerkcomponenten in de vorm appliances9 waarop weinig extrahardeningsmaatregelen mogelijk zijn. In de gevallen dat eennetwerkcomponent echter niet gebaseerd is op een appliance, is het vanbelang dat men het onderliggende systeem ‘hardent’. Meer hiervoor kunt uvinden in hoofdstuk 4: platformbeveiliging.

•  Besteed voldoende aandacht aan de beveiligingsconfiguratie vanveelgebruikte netwerkservices en -protocollen: Simple NetworkManagement Protocol (SNMP), Network Time Protocol (NTP), SYSLOG,Trivial FTP (TFTP), finger en routeringsprotocollen zoals Border GatewayProtocol (BGP) en Open Shortest Path First (OSPF).

•  Schakel alle ongebruikte protocollen, services en netwerkpoorten uit.Voorbeelden van protocollen die veelal standaard zijn aangeschakeld opnetwerkcomponenten maar in veel gevallen niet benodigd zijn, zijn CiscoDiscovery Protocol (CDP) en Spanning Tree Protocol (STP)

•  Maak op switches gebruik van Virtual LAN’s (VLAN) en beperk de toegangtot netwerkpoorten op basis van MAC-adres (port security).

MEER INFORMATI E Via internet zijn een groot aantal templates enhandleidingen te vinden die ingaan op het beveiligen van specifieke protocollen of services. Hieronder vindt u een kleine greep uit een aantal interessante artikelenop 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 

9 Een appliance is een deels voorgeconfigureerde machine met een specifieke functionaliteit (bijvoorbeeld

firewalling, routing, switching) en gelimiteerde toegang tot het besturingssysteem

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 27/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 besch ikbaarhe idvraags tukken 

Door de belangrijke rol die het netwerk speelt als ‘onderstel’ van dewebapplicaties is het van belang dat het netwerk te maken krijgt met eenminimum aan storingen. Het ontwerp van het netwerk dient daarom zodanig tezijn dat deze zo min mogelijk (liefst geen) Single Points-of-Failure (SPOF) bevat.Load balancing en redundantie zijn twee technieken die een organisatie kaninzetten om de beschikbaarheid van de infrastructuur te vergroten. De volgendetwee 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 verschillendegelijkwaardige componenten verdelen. Voor webapplicaties bestaan tweebelangrijke load balancing technieken:

•  Local Server Load Balancing (LSLB); een ‘LSLB load balancer’ verdeeltverkeer lokaal (dat wil zeggen binnen hetzelfde datacenter) over

verschillende webservers. Uitval van een webserver zal in dit geval nietper definitie leiden tot het niet meer beschikbaar zijn van de website.

•  Global Server Load Balancing (GSLB); een ‘GSLB load balancer’ is eenstuk complexer dan een ‘LSLB load balancer’ en heeft als doel om loadbalancing uit te voeren over geografisch gescheiden locaties. DNS-functionaliteit is een mechanisme om GSLB voor webapplicaties tebewerkstelligen. De ‘GSLB load balancer’ is hierbij autoritief voor de zonewaarin de webapplicatie zich bevindt en fungeert voor deze zone als DNS-server. Door verzoeken voor de zone te beantwoorden met steedswisselende IP-adressen komen gebruikers uit op de verschillende

geografisch gescheiden locaties. Deze aanpak verschilt van de standaardRound Robin (RR) functionaliteit in DNS omdat GSLB rekening houdt metde load die een bepaalde locatie op dat moment ondervindt en debeschikbaarheid van deze locatie. Valt een geografische locatiebijvoorbeeld uit dan zal de ‘GSLB load balancer’ de bijbehorende IP-adressen niet meer uitdelen. Bij gebruik van RR-DNS zal de DNS-serverhet IP-adres van de uitgevallen server gewoon blijven retourneren omdatde DNS-server geen middelen heeft om te achterhalen of de betreffendewebserver nog bereikbaar is.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 28/116

Figuur 3-6: voorbeeldinrichting GSLB

In figuur 3-6 is een voorbeeld opgenomen van de inrichting van een GSLB-oplossing. Hierbij is te zien dat de ‘GSLB load balancers’ status informatieover een locatie krijgen via lokale ‘LSLB load balancers’. Op basis van dezestatusinformatie en polling-gegevens besluit de GSLB load balancer omeen bepaald IP-adres te koppelen aan een DNS-verzoek van een client.

Door de afhankelijkheid van GSLB-oplossingen van DNS kan dit in depraktijk tot problemen leiden. Zo gebruiken GSLB-oplossingen een zeer

kleine Time-to-Live (TTL) voor DNS-records. De lengte van de TTL bepaalthoe 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 standaardTTL van 24 uur aan te houden. In dit soort gevallen werkt de oplossingniet goed voor klanten die zijn aangesloten via deze provider omdat dezeproviders DNS-records minimaal 24 uur cachen. Hierdoor duurt hetmogelijk 24 uur voordat een uitgevallen locatie niet meer wordtgeadverteerd richting clients. Bij de keuze voor een GSLB-oplossing is hetraadzaam 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 zijgeen Single Point-of-Failure (SPOF) vormen. Veel netwerkcomponenten biedenstandaard ondersteuning voor redundantie en bijbehorende statussynchronisatie.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 29/116

Componenten (op netwerkniveau) die met name in aanmerking komen voorredundante uitvoering zijn:

•  Communicatieverbindingen;•  Firewalls;•  Load balancers;•  Proxies;•  Routers;•  Switches.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 30/116

4  PLATFORMBEVEILIGING

Dit hoofdstuk beschrijft de beveiliging van de platformen waarvan dewebapplicatie afhankelijk is. Het platform waarop een webapplicatie draait, is inde regel een besturingssysteem als Windows Server of Linux-/Unix-varianten. Dithoofdstuk besteedt aandacht aan de kwetsbaarheden en bedreigingen die erbestaan op het gebied van platformen en zal tevens aanbevelingen doen tervoorkoming van deze kwetsbaarheden en bedreigingen.

4.1   Inleiding

Het platform (besturingssysteem) bevindt zich tussen het netwerk en dewebapplicatie. In sommige gevallen zijn de services die het platform aanbiedtrechtstreeks via internet te benaderen. Eventuele kwetsbaarheden die zichbevinden in het platform kunnen daarom direct de beveiliging van dewebapplicatie in gevaar brengen.

4.2   Mogelijke kwetsbaarheden en bedreigingen

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

4.2 .1   Kw etsbaarheden i n he t OS 

Leveranciers van besturingssystemen brengen met grote regelmaat patches uitvoor nieuwe kwetsbaarheden. Niet alle kwetsbaarheden hebben direct gevolgenvoor servers die in gebruik zijn door webapplicaties. Dit komt met name omdatwebservers in de regel slechts bereikbaar zijn op een beperkt aantal poorten (zie

hoofdstuk 3). Wanneer er echter een kwetsbaarheid in het besturingssysteemaanwezig is welke kwaadwillenden via de webserver kunnen misbruiken, dan kandit ernstige gevolgen hebben voor alle webapplicaties die van deze server gebruikmaken.

Een buffer overflow is een specifieke kwetsbaarheid. Buffer overflows in hetplatform kunnen ertoe leiden dat kwaadwillenden willekeurige code uitvoeren opde webserver wanneer de betreffende kwetsbare service bereikbaar is vanaf hetinternet. In sommige gevallen biedt een buffer overflow alleen mogelijkheden omde kwetsbare service te laten crashen. Het probleem bij een buffer overflow is dateen kwetsbare applicatie data wil opslaan buiten de geheugenbuffer die voor dezeapplicatie is gereserveerd. Het gevolg hiervan is dat de applicatie geheugen in

aanliggende geheugengebieden overschrijft. Hierdoor overschrijft het programmamogelijke andere buffers en data van andere programma’s.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 31/116

ACHTERGROND Een buffer overflow op het platform kan met name tot groteproblemen leiden wanneer deze zich bevindt in een centraal onderdeel van hetplatform dat bovendien moeilijk af te schermen is voor kwaadwillenden. Hierbijkan men denken aan een kwetsbaarheid in de implementatie van TCP/IP.

Uit een onderzoek van beveiligingsbedrijf Internet Security Systems (ISS) blijktdat de tijd die men heeft om bekende beveiligingslekken te patchen steeds verderafneemt. ISS evalueerde in totaal 4472 lekken die in 2005 bekend werdengemaakt. Bij 3,13% van deze lekken (140) bleek binnen 24 uur na hetverschijnen van het lek al exploitcode10 op internet beschikbaar te zijn. Na 48 uurwas al voor 9,38% van de lekken (420) exploitcode beschikbaar. Zeker voorlekken die op veel servers aanwezig zijn, en kunnen leiden tot het uitvoeren vanwillekeurige code, zullen kwaadwillenden veel moeite doen tot uitbuiting.

4.2 .2    Onve i l i g i nge r i ch te behee rm echan i sm en  

Het beheer van server in de hosting omgeving kan op verschillende manierenplaatsvinden. Enkele van de meest gebruikte beheermechanismen zijn:

•  Consoleverbindingen; een consoleverbinding kan men normaalgesproken alleen benaderen wanneer men een fysieke verbinding met deserver of het component kan opzetten. Hiervoor dient men dan ook fysieke

toegang te hebben tot de ruimte waarin de server zich bevindt. Tenbehoeve van beheer kan men consoleverbindingen ook via het netwerkbeschikbaar stellen. In dit geval sluit men de consoleverbindingen aan opeen netwerk-enabled component. Door een Telnet-verbinding op te zettenmet een dergelijk component kan men een consoleverbinding via hetnetwerk benaderen.

•  Telnet; via telnet kan men een command-line sessie openen met eenmachine. Telnet is een redelijk gedateerd mechanisme dat vanwegebeveiligingsredenen 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 wederzijdseauthenticatie te laten plaatsvinden. Via SSH kan men een command-linesessie openen met een server. Het is echter ook mogelijk om anderefunctionaliteiten (zoals het kopiëren van bestanden via Secure Copy) viaeen SSH-verbinding te tunnelen.

•  File Transfer Protocol (FTP ); via FTP kan men bestanden uitwisselentussen een client en een server. FTP maakt gebruik van authenticatie opbasis van een gebruikersnaam en wachtwoord. Deze gegevens verstuurt

de FTP-client in cleartext (in onversleutelde vorm) over het netwerk. Ditlaatste is één van de belangrijkste redenen dat het gebruik van FTP

10 Programmacode waarmee men een bekende kwetsbaarheid kan misbruiken

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 32/116

onveilig is.

•  Webinterface; veel systemen bieden tegenwoordig een webinterface viawelke men de belangrijkste beheeractiviteiten kan uitvoeren. Eendergelijke webinterface kan gebruik maken van bestaandebeveiligingsmechanismen op dit gebied zoals versleuteling via SSL,authenticatie op basis van X.509-certificaten, etc… Hoewel webinterfacesdus mogelijkheden bieden tot veilige inrichting hoeft dit niet per definitiete gebeuren. Wanneer men onvoldoende aandacht besteed aan hetgebruik van veilige mechanismen rondom een webinterface kan eenonveilige situatie ontstaan.

Afhankelijk van de inrichting van de infrastructuur rondom de hostingomgeving(zie hoofdstuk 3) kan het gebruik van bepaalde beheermechanismen eenbeveiligingsrisico met zich meebrengen. Het gaat hier met name ombeheermechanismen die geen gebruik maken van versleutelingen en diegebruikersnamen en wachtwoorden in cleartext over het netwerk versturen.Wanneer men dergelijke beheermechanismen toestaat over het internet, bestaatde kans dat kwaadwillenden deze authenticatiegegevens onderscheppen. Figuur4-1 geeft een voorbeeld van de informatie (gebruikersnaam ‘anonymous’ enwachtwoord ‘[email protected]’) die een kwaadwillende kan achterhalen door hetonderscheppen van FTP-verkeer.

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

4.2 .3    Onju i s te au t o r i sa t i es  

Het is van belang om de rechten die men toekent aan processen,bestandssysteem, register, etc… zoveel mogelijk in te perken. Op het moment datdit 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 demogelijkheid om rechten te koppelen aan bestanden, directories, etc… Richt men

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 33/116

de rechten op een webserver niet op een juiste manier in dan kunnen een grootaantal problemen ontstaan; enkele voorbeelden hiervan:

•  Er bevindt zich in een buffer overflow in een bepaalde HTTP-listener; doordeze buffer overflow te misbruiken kunnen kwaadwillenden willekeurige codeuitvoeren op de webserver. Wanneer de webserver draait onder de rechtenvan een ‘gelimiteerde’ gebruiker dan zijn de mogelijkheden die dekwaadwillende heeft nog enigszins beperkt. Draait de webserver echter ondereen gebruiker die veel meer rechten heeft (bijvoorbeeld ‘root’, ‘SYSTEM’,etc..), dan zijn de gevolgen van misbruik van deze buffer overflow veelverstrekkender.

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

•  Voor de verbinding tussen de webapplicatie en een database maakt dewebapplicatie gebruik van een Database Administrator (DBA) account. Dit iszo ontstaan tijdens de ontwikkeling van de webapplicatie. Er blijkt zich echtereen SQL injection kwetsbaarheid in de webapplicatie te bevinden. Deze SQL

injection kwetsbaarheid, gecombineerd met de maximale rechten op dedatabase, zorgt ervoor dat kwaadwillenden elke mogelijke actie op dedatabase kunnen uitvoeren (tot aan het verwijderen van de database toe).

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

4.2 .4    Onnod ige serv ices  

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 kankwetsbaarheden bevatten en vormt daarmee een potentieel lek. Zeker wanneereen service wel is geïnstalleerd op een systeem maar men geen aandacht heeftgeschonken aan de beveiliging ervan (omdat men bijvoorbeeld niet verwachttedat deze service werd geïnstalleerd), ontstaat een belangrijke bron vanbeveiligingsproblemen.

4.3   Aanbevelingen

Alle aanbevelingen uit deze paragraaf kan men scharen onder de noemer ‘hardening van het OS’. Hardening houdt in dat men het besturingssysteemzodanig inricht dat dit systeem beter bestand is tegen aanvallen vankwaadwillenden. De technische stappen die benodigd zijn om een

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 34/116

besturingssysteem te hardenen verschillen per type besturingssysteem. Delogische stappen verschillen echter veel minder. De aanbevelingen uit dezeparagraaf zijn dan ook vooral generiek van aard. Per aanbeveling is ook eenvoorbeeld opgenomen van hoe deze stap er op een specifiek typebesturingssysteem uit zou kunnen zien.

4.3 .1   Richt een so l ide updatem echan isme in  

Een solide updatemechanisme is essentieel om voldoende beschermd te zijn tegenbekende beveiligingsproblemen in software. Naast een technische implementatievan 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 metupdates: hoe snel implementeert de organisatie een kritieke patch, welke stadiamoet de patch doorlopen, wie draagt ervoor de verantwoordelijkheid, etc...?

VOORBEELD Microsoft biedt in zijn besturingssystemen standaard ondersteuningvoor een aantal verschillende updatemechanismen. Zo kunnen clients rechtstreeksupdates bij Microsoft ophalen via update.microsoft.com en via “AutomaticSoftware 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 mendenken 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 volgendeonderdelen:

•  Stap 1: vaststellen dat een patch beschikbaar is gekomen. Voordat deorganisatie beseft dat het een patch moet installeren, is het eerst zaak opde hoogte te zijn van het feit dát een patch beschikbaar is gekomen.Hiertoe kan de organisatie monitoringprocessen inregelen voor de meestgebruikte technologieën. De advisorydienst van GOVCERT.NL is eenmanier om op de hoogte te blijven van de laatst uitgebrachte patches van

leveranciers.

•  Stap 2: beoordeel de impact van de uitgebrachte patch en debijbehorende kwetsbaarheid. Mogelijk is de kwetsbaarheid technischgezien vrij ernstig maar bestaan er, gezien de inrichting van deinfrastructuur van de organisatie, verzachtende omstandigheden waardoorde kwetsbaarheid voor de organisatie minder ernstig is. Als de impact vanzowel kwetsbaarheid als patch bepaald is, kan de organisatie bepalen of ersprake 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 allegevallen via internet.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 35/116

•  Stap 4: test de patch in een test- of acceptatieomgeving. Bekijk of depatch geen negatieve effecten heeft op de bestaande programmatuur.Veelal is het niet mogelijk om alle negatieve effecten uit te sluiten. In ditsoort gevallen is het aan te raden om in ieder geval de werking vanessentiële programma’s te controleren.

•  Stap 5: rol de patch uit in de productieomgeving. Nadat uit de testen inde test- en acceptatieomgeving is gebleken dat de patch geen negatieveeffecten heeft, kan men besluiten om de patch uit te rollen op alleproductieservers.

•  Stap 6: monitoor eventuele berichtgeving rondom de patch. Nadat eenpatch is uitgebracht door een leverancier verschijnen in sommige gevallenberichten op internet waarin organisaties problemen met de patchbeschrijven. Deze problemen kunnen zich mogelijk ook voordoen in deeigen omgeving waardoor kennis hiervan van belang kan zijn.

4.3 .2    Verw i j de r onnod ige se rv i ces  

Bij het hardenen van het systeem is een belangrijke strategie om decommunicatiemogelijkheden van het systeem tot een minimum (het striktnoodzakelijke) te beperken. Eén van de manieren om dit te bereiken is door

onnodige services uit te schakelen. Door benodigde services in kaart te brengenen vervolgens de afhankelijkheden te bepalen komt men tot een minimale lijstvan services die het betreffende systeem dient te ondersteunen. Alle overigeservices kan men óf uitschakelen óf verwijderen.

VOORBEELD Debian biedt de tool rcconf (zie onderstaande schermafdruk) alshulpmiddel voor het bepalen van de services die het systeem moet starten tijdenshet booten van het systeem. De tool haalt een lijst van services op uit /etc/init.den kijkt vervolgens in de /etc/rc?.d directories om te bepalen of deze servicesautomatisch starten. Via de tool kan men de configuratie ook aanpassen.

Bedenk dat niet-actieve maar wel aanwezige services op een systeem uiteindelijktoch tot een kwetsbaar systeem kunnen leiden aangezien ‘lekke’ programmacode

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 36/116

op het systeem aanwezig is. Veiliger is het daarom om onnodige services volledigvan het systeem te verwijderen.

4.3 .3    Richt access cont r o ls s t r i k t i n  

Het beperken van rechten op een systeem voorkomt misbruik van dit systeem. Demanier waarop het systeem deze rechtenbeperking mogelijk maakt, hangt af vanhet gebruikte besturingssysteem. Hieronder volgen enkele aanwijzingen voor hetinperken van rechten op twee populaire typen besturingssystemen: Linux enMicrosoft Windows.

Linux:•  chmod (change mode) en chown (change owner) vormen de belangrijkste

mechanismen voor het beveiligen van bestanden en directories. chmod biedtmogelijkheden 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 viaumask een zeer strikte modus in te schakelen voorkomt men dat nieuwaangemaakte bestanden ‘per ongeluk’ toegankelijk zijn voor ongeautoriseerdegebruikers.

•  setuid (Set UserID) en setgid (Set GroupID) zijn vlaggen die men aanbestanden en directories op een Linux-systeem kan hangen. De vlaggenmaken het mogelijk om bepaalde bestanden met tijdelijk verhoogde

gebruikersrechten uit te voeren. Het is van belang deze privileges nauwgezette monitoren en deze selectief uit te delen.

•  Normaal gesproken geldt dat, wanneer een gebruiker schrijfrechten heeft opeen directory, deze gebruiker ook bestanden uit deze directory kanverwijderen. Dit kan zelfs wanneer de gebruiker niet de eigenaar is van dezebestanden. Door het plaatsen van een zogenaamd ‘sticky bit’ op de directoryvoorkomt men dit. Sticky bits kan men daarom toepassen om de toegang tothet bestandssysteem verder in te perken.

•  Via chattr kunnen verschillende attributen op bestanden en directoriesworden geplaatst. Enkele van deze attributen zijn bruikbaar vanuit hetoogpunt van beveiliging. Het gaat in het bijzonder om de volgende attributen:

 ‘a’-attribuut: gebruikers (en processen) kunnen een bestand met het ‘a’-attribuut alleen in ‘append’-mode openen voor schrijven. Dit betekent datde 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 mogelijkom links naar dit bestand op te nemen of inhoud naar het bestand teschrijven

o   ‘u’-attribuut: wanneer een gebruiker (of proces) een bestand met een ‘u’-attribuut verwijdert, slaat het besturingssysteem de inhoud van ditbestand op. Hierdoor biedt het besturingssysteem de mogelijkheid om deverwijdering van een bestand later ongedaan te maken.

•  Bovenstaande punten hadden allen betrekking op het inperken van rechten ophet niveau van het bestandssysteem. Het is in Linux ook mogelijk om derechten op het niveau van de kernel in te perken. Een handige tool voor het

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 37/116

administreren van deze rechten is lcap. Het bijzondere aan dezerechtenbeperking via de kernel is dat de beperking ook van toepassing is opde ‘root’-gebruiker. Zaken die de kernel kan beperken c.q. onmogelijk kanmaken zijn bijvoorbeeld het wijzigen van de GID en de UID en het ‘killen’ vanprocessen.

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 ActiveDirectory (AD) inregelen.

4.3 .4    Harden de im p lem en t a t i e van essen t i ë l e p ro toco l l en  

Door essentiële protocollen op een server te hardenen, voorkomt men misbruikvan deze protocollen en verhoogt men de stabiliteit van het systeem. Dit kanervoor zorgen dat een eventuele kwetsbaarheid in een dergelijk protocol nietdirect ernstige consequenties voor het systeem hoeft te hebben. Eén van deprotocollen die zich uitstekend leent voor hardening is TCP/IP. Zoals al inparagraaf 3.3.9 werd beschreven, kan het hardenen van de TCP/IP-stack ervoorzorgen dat het risico op een succesvolle DoS aanval vermindert. Voor elk typebesturingssysteem bestaan mogelijkheden om de configuratie van de TCP/IP-

stack zodanig te veranderen dat deze beter bestand is tegen aanvallen. Het is aante 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 ingerichtvoor het afhandelen van intranet verkeer. Wanneer een organisatie een WindowsServer 2003 machine aansluit op internet raadt Microsoft aan enkele wijzigingendoor te voeren in de configuratie van de TCP/IP-stack. Deze wijzigingen voertmen door, door de inhoud van bepaalde registersleutels aan te passen. Dezewijzigingen 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 eenDenial-of-Service-aanval op HTTP-niveau te voorkomen, kan men ervoor kiezenom de idle timeout van een HTTP-sessie te verkleinen en ‘session pooling’ tussen

een eventuele application-level firewall (hoofdstuk 5) en webservers aan teschakelen. ‘Session pooling’ verhoogt de performance van HTTP door de kostendie gepaard gaan met het steeds opnieuw opbouwen van een HTTP-sessie tevoorkomen. Zo kan een application-level firewall meerdere kleinere bestanden via

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 38/116

één HTTP-sessie ophalen bij een webserver. Naast dat dit leidt tot meer efficiëntieen betere responsetijden, helpt dit ook in het voorkomen van eerder genoemdeDoS-aanvallen.

4.3 .5    M aak geb ru i k van j a i l ing  

Een mechanisme dat voornamelijk bestaat op het Linux- en Unix-platform is jailing (sandboxing). Het is een zeer eenvoudige vorm van isolatie van eenproces. Een bekende implementatie hiervan is chroot. Het commando chroot wijzigt de root-directory voor een proces (change root). Door een proces viachroot te laten werken, kan het proces niet buiten zijn root-directory treden. Ditmechanisme kan men bijvoorbeeld inzetten om de Apache-server geïsoleerd te

laten draaien.

VOORBEELD Over het ‘chrooten’ van Apache zijn enkele goede ‘howto’-artikelenterug 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 zichmee kan brengen. Zo moet men eventuele bibliotheken en executables waarvanApache gebruik maakt, beschikbaar maken in de ‘chrooted’-omgeving. Om dezeproblemen zoveel mogelijk te voorkomen is ‘chroot’-functionaliteit ook ingebouwdin de ModSecurity application-level firewall (vanaf versie 1.6). Meer informatieover 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 omandere delen van het besturingssysteem af te schermen; voorbeelden zijn hetbeperken 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 gegevenmoment virtualisatie ontstaat. Toepassingen als VMware, QEMU, Xen en MicrosoftVirtual Server bieden bijvoorbeeld de mogelijkheid om volledig autonomebesturingssystemen naast elkaar te laten functioneren.

4.3 .6    Han tee r s t r i k t e O S-au then t i cat i e (m echan i sm en)

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 meergeneriek van aard en zijn van toepassing op vrijwel alle besturingssystemen:

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 39/116

•  Zorg ervoor dat het systeem niet toegankelijk is op basis van ‘anonieme’ accounts.

•  Overweeg de invoering van sterke authenticatiemechanismen voor detoegang tot systemen. Deze mechanismen kenmerken zich door hetgebruik van twee factoren voor authenticatie. Zie hoofdstuk 6 (‘Identiteit-en toegangsbeheer’) voor meer informatie over dergelijkeauthenticatiemechanismen.

•  Beperk de groepslidmaatschappen van gebruikers.•  Implementeer een strikte password policy. In een password policy legt

men zaken vast als minimale passwordlengte, lengte van depasswordhistorie, complexiteit van het wachtwoord, account lockouts,

etc…•  Verwijder ongebruikte accounts en standaard aanwezige accounts.•  Hernoem ‘bekende’ accounts (zoals bijvoorbeeld ‘administrator’).

4.3 .7    M aak g eb ru i k van ve i l i ge behee rm echan i sm en  

Voorkom zoveel mogelijk het gebruik van onveilige beheermechanismen. Gebruikdus bijvoorbeeld SSH in plaats van Telnet. Zorg er daarnaast voor datbeheerinterfaces alleen bereikbaar zijn vanaf een gescheiden beheernetwerk (ziehoofdstuk 3).

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

4.3 .8    M aak back -ups  

Back-ups vormen een laatste redmiddel in het geval de integriteit of beschikbaarheid van systemen of applicaties is aangetast. Om dit laatsteredmiddel te kunnen hanteren dient men de beschikking te hebben over recente

back-ups van deze systemen. Nog beter is het wanneer deze back-ups onderdeeluitmaken van een Disaster Recovery Plan (DRP). Tevens is het van belang datmen regelmatig test of de gemaakte back-ups de mogelijkheid bieden om eenverloren gegaan systeem opnieuw op te bouwen.

Frequente (veelal dagelijkse) back-ups van systemen zorgen ervoor dat menbeschikt over snapshots van het systeem op gezette tijden. Voor sommigedynamische componenten (zoals databases) is deze dagelijkse snapshot wellichtniet afdoende. Bij dergelijke componenten kan men overwegen om detransactielog van de database beschikbaar te stellen op een uitwijklocatie(‘remote journaling’). In het geval het component crasht, kan men een up-to-dateversie van het component creëren door de laatste back-up hiervan terug te zettenen hierop de transactielog toe te passen.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 40/116

4.3 .9    M aak geb ru i k van l oka le f i r ew a l l s  

In het vorige hoofdstuk werd beschreven hoe centraal geplaatste firewalls deomgeving kunnen beschermen tegen kwaadwillenden. Naast deze centralefirewalls is het ook mogelijk om decentraal, op de verschillende machines, eenaparte firewall te laten werken. Deze lokale (decentrale) firewalls vormendaarmee een extra laag in de beveiliging. Veel besturingssystemen bieden demogelijkheid tot het gebruik van een lokale firewall. Enkele voorbeelden van dezefirewalls zijn:

•  ipfw; FreeBSD packet filter. Het is daarnaast een standaard onderdeel vanApple Mac OS. Voor simpele regels biedt Apple daarnaast een eenvoudigegrafische gebruikersinterface.

•  pf; OpenBSD packet filter. Is de opvolger van ipfilter voor hetOpenBSD platform.

•  iptables; standaard onderdeel van veel Linux-distributies. Maakt gebruikvan netfilter.

•  ipfilter (ipf); onderdeel van Linux-distributies en Unix (onder andereSun Solaris 10).

•  Windows Firewall; onderdeel van Windows XP SP2 en Windows Server2003.

Lokale firewalls hebben als voordeel dat ze niet alleen op poortniveau controleskunnen uitvoeren maar ook procesniveau. Verder hebben lokale firewalls vaakmeer inzicht in het verkeer dat zich richting de machine begeeft omdat op demachine zelf ontsleuteling van eventuele versleutelde tunnels plaatsvindt.Daarnaast bevatten lokale firewalls vaak veel minder regels in de rulebasewaardoor 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 Linux-en Unix-gebaseerde firewalls leveren, is het ook mogelijk deze in te zetten alscentrale firewall. Wanneer een firewall wordt ingezet als een centrale firewallspreekt men ook wel van een perimeter firewall (pfw). Een lokale firewall noemtmen in dit verband ook wel een end-point firewall (epfw).

4.3 .10    Aud i t de w i j z i g i ngen op he t sys teem  

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 helpenin het opmerken van misbruik van de omgeving. Door op het platform tools in te

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 41/116

zetten die deze wijzigingen in kaart brengen en deze informatie beschikbaar testellen aan “Monitoring, auditing en alerting” (hoofstuk 9) kan men dezewijzigingen adequaat monitoren.

VOORBEELDEN Eén van de bekendste tools die men kan inzetten omwijzigingen op een systeem te detecteren is Tripwire. Er is zowel een commerciëleals een open-source versie van dit pakket beschikbaar. Tripwire houdt eendatabase bij waarin het een snapshot van het bestandssysteem opslaat. Via eenpolicy bepaalt Tripwire welke wijzigingen op dit snapshot mogelijk gevaarlijk zijn(bijvoorbeeld het toevoegen van een gebruiker of een ‘root’-gebruiker zonderwachtwoord).

Microsoft Windows kent ingebouwde functionaliteit om wijzigingen op bestandene.d. te auditen. Het is van belang dat men, bij toepassing hiervan, strikteauditregels opstelt aangezien anders de hoeveelheid auditdata extreme vormenkan aannemen.

4.3 .11   M aak geb r u i k van beve i li g i ngs tem p la tes  

Alle hardeningsmaatregelen die benodigd zijn voor servers kan een organisatieopnemen in beveiligingstemplates. Beveiligingstemplates kan men opstellen aande 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 mogelijkehardeningsmaatregelen eerst uit in een representatieve testomgeving zodat zekeris dat het betreffende systeem zonder probleem zal blijven functioneren zodra demaatregelen zijn geëffectueerd. Beveiligingstemplates bestaan in ieder geval uitdocumenten die de hardening beschrijven. Scripts, images,configuratiebestanden, etc… kunnen deze templates vervolgens technischondersteunen.

ACHTERGROND Er zijn op internet diverse handleidingen te vinden die menkan 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-0685-4d89-b655-521ea6c7b4db

•  The Threats and Countermeasures Guide (Microsoft): http://www.microsoft.com/downloads/details.aspx?FamilyID=1b6acf93-147a-4481-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/

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 42/116

5  APPLICATIEBEVEILIGING

5.1   Inleiding

Daar waar netwerkbeveiliging zich richt op het afschermen van het netwerk opbasis van te onderscheiden protocollen zal applicatiebeveiliging een niveau diepergaan en de inhoud van de protocollen willen bekijken. Een applicatiefilter heeft

kennis over het gebruikte protocol en kan bepalen of het gebruik van het protocolvoldoet aan eerder opgestelde policies en syntaxis. Door applicatie filtering toe tepassen 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 verschillendewebapplicaties. 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 demeest voorkomende kwetsbaarheden en bedreigingen op het gebied vanwebapplicaties. De problemen zoals geschetst in de “OWASP top 10” zijn in ditoverzicht verwerkt.

ACHTERGROND Een project genaamd ‘Common Weakness Enumeration’ (CWE) tracht een complete lijst van alle mogelijke kwetsbaarheden in softwaresamen te stellen. Deze zeer uitgebreide lijst bevat, naast de kwetsbaarhedenzoals beschreven in deze paragraaf, nog een groot aantal anderekwetsbaarheden. Hoewel de lijst niet specifiek is toegespitst op webapplicaties ishet 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 hierterug vinden: http://cve.mitre.org/cwe/

5.2 .1   Ongeva l ideerde input  

Het niet juist valideren van input blijkt één van de meest gemaakte fouten inwebapplicaties. Webapplicaties moeten er per definitie vanuit gaan dat alleinformatie die zij toegestuurd krijgen niet te vertrouwen is. Applicaties kunnenniet vertrouwen op eventuele controles die client-side scripts hebben uitgevoerdomdat deze scripts eenvoudig te omzeilen zijn. Het niet juist valideren van inputvan gebruikers ligt ten grondslag aan drie bekende webapplicatie-kwetsbaarheden; 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.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 43/116

5.2 .2    Cross-Si te Scr ipt ing ( XSS)

Cross-Site scripting (XSS11) houdt in dat een kwaadwillende kwaadaardige codeinjecteert in een link die verwijst naar een vertrouwde website. Hiertoe moet dekwaadwillende de beschikking hebben over een alom vertrouwde website diemogelijkheden biedt tot XSS.

In juni 2006 ondervond PayPal zulke XSS-problemen op zijn website. Het scenariodat kwaadwillenden konden gebruiken om deze kwetsbaarheid uit te buiten isgelijk aan dat van figuur 5-1. In figuur 5-1 is een legale, vertrouwde websiteopgenomen. Een gebruiker ontvangt via zijn e-mail een verzoek om verbindingmet deze website te maken (bijvoorbeeld met als reden dat er een specialereclame zou zijn). Wanneer de gebruiker de link volgt zal deze in eerste instantiewellicht niet achterdochtig worden: de gebruiker krijgt een volledig correcte SSL-verbinding met de betreffende website en het inloggen verloopt zonderproblemen. Echter, de kwaadwillende heeft in de URL een script verpakt dat wordtuitgevoerd zodra het slachtoffer verbinding heeft gemaakt met de vertrouwdewebsite. Doordat de website parameters in de URL niet goed afhandelt, stuurt dewebserver het script als opdracht terug naar het slachtoffer, waarna de client hetaldaar uitvoert. Het script dat de kwaadwillende heeft geïnjecteerd, zorgt ervoordat de client de inloggegevens van de gebruiker verstuurt naar een server van dekwaadwillende. Op deze manier kan deze kwaadwillende inloggegevens van eengroot 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.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 44/116

XSS is ook in andere varianten mogelijk. Denk bijvoorbeeld aan een forum waaropiedereen berichten kan plaatsen. Wanneer de applicatie geen goede inputvalidatieuitvoert, is het mogelijk dat XSS plaatsvindt via de inhoud van het forum. Dekwaadwillende hoeft dan alleen een specifiek stukje code te injecteren in deinhoud van het forum.

ACHTERGROND Een poging tot het uitvoeren van een XSS-aanval kan menin veel gevallen herkennen aan het sleutelwoord ‘script’ in een link; dit ziet erbijvoorbeeld 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 eenkwaadwillende de verzamelde gegevens nadien wel misbruiken om zichongeautoriseerde toegang te verschaffen tot de webapplicatie. De webapplicatiemoet voorkomen dat dergelijk misbruik via de website mogelijk is.

5.2 .3    SQL in ject ion 

SQL injection ontstaat, net als XSS, door onvoldoende controles op de invoer vangebruikersdata. De aanwezigheid van een SQL injection kwetsbaarheid betekent

dat een gebruiker op het internet in staat is om de SQL-verzoeken die eenwebapplicatie verstuurt naar de database, te manipuleren. De gevolgen van dezekwetsbaarheid zijn in grote mate afhankelijk van de programmalogica. Mogelijkegevolgen zijn:

•  Een kwaadwillende kan het authenticatiemechanisme van de webapplicatieomzeilen en op deze manier ongeautoriseerd ‘inloggen’ op dewebapplicatie;

•  Een kwaadwillende kan gegevens in de database wijzigen zonder dat deorganisatie 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 dewebapplicatie te verkrijgen en te behouden.

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

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 45/116

Figuur 5-2: voorbeeld van SQL injection

Zoals het proces in figuur 5-2 weergeeft, vertrouwt de webapplicatie de invoervan de gebruiker zonder meer en verwerkt de webapplicatie deze inputrechtstreeks in een SQL-verzoek richting de database. De programmalogica iszodanig gebouwd dat een gebruiker succesvol geauthenticeerd is wanneer dequery meer dan 0 resultaten genereert; het idee hierachter is dat het zoeken opeen combinatie van gebruikersnaam en wachtwoord alleen resultaten oplevert alsde gebruikersnaam en het bijbehorende wachtwoord voorkomen in de database.De webapplicatie construeert hiertoe de volgende query:

SELECT *

FROM gebruikers

WHERE gebruikersnaam = ‘<gebruikersnaamveld>’

  AND wachtwoord = ‘<wachtwoordveld>’

Door het wachtwoordveld te manipuleren kan de kwaadwillende bereiken dat dewebapplicatie aan de zoekopdracht de voorwaarde “OF 1=1” toevoegt. Dit bereiktde kwaadwillende door bij gebruikersnaam ‘1’ in te vullen en bij wachtwoord “x’ OR ‘1=1”. Hierdoor ontstaat de volgende query:

SELECT *

FROM gebruikers

WHERE gebruikersnaam = ‘1’  AND wachtwoord = ‘x’ OR ‘1=1’

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 46/116

Eén is vanzelfsprekend altijd gelijk aan één waardoor elk record uit degebruikerstabel voldoet aan dit zoekcriterium. Dientengevolge zal het uitvoerenvan het SQL-verzoek alle records uit de tabel als resultaat geven. Hierdoorconcludeert de programmalogica dat het gebruikersnaam met dit wachtwoordvoorkomt in de database en dat de gebruiker dus geautoriseerd is voor toegangtot de webapplicatie.

OPMERKING Wanneer de applicatie geen verbinding met een database maarmet een andere dataverzameling opzet, kan hetzelfde probleem zich ook op eenandere manier manifesteren. Denk hierbij bijvoorbeeld aan misbruik van eenverbinding tussen de webapplicatie en een LDAP server (LDAP injection). 

5.2 .4    Buf fe r ove r f l ows  

Buffer overflows kunnen zich voordoen in elk stuk softwarecode. Een bufferoverflow doet zich voor op het moment dat de applicatie meer data naar eengeheugenbuffer schrijft dan dat daar initieel voor was gereserveerd. Hierdoorkomt data op plekken in het geheugen terecht waar dit eigenlijk niet hadgemogen. Misbruik van een buffer overflow kan leiden tot het uitvoeren vanwillekeurige code op het systeem; hierdoor kan een kwaadwillende in heternstigste geval volledige controle over een server krijgen.

Buffer overflows zijn niet altijd eenvoudig te ontdekken en daarnaast blijkt hetvaak moeilijk om een gevonden buffer overflow te misbruiken. Van sommigeontdekte kwetsbaarheden publiceert de ontdekker Proof-of-Concept (PoC) code opinternet waardoor de kans op uitbuiting plotseling sterk toeneemt. In sommigegevallen publiceert de ontdekker zelfs code waarmee een kwaadwillende dekwetsbaarheid in zijn volledigheid kan uitbuiten (exploit).

ACHTERGROND Proof-of-Concept (PoC) code bewijst dat een bepaaldekwetsbaarheid aanwezig is binnen software. Een PoC buit deze kwetsbaarheidechter niet maximaal uit. Een exploit doet dit wel. Een voorbeeld is eenkwetsbaarheid in een browser waarbij men volledige controle kan krijgen over een

kwetsbaar systeem. Een PoC bewijst dat de kwetsbaarheid aanwezig is door viade code de browser te laten crashen, de exploit biedt de mogelijkheid om ookdaadwerkelijk controle over het kwetsbare systeem te krijgen. De code achter eenPoC en een exploit kan vrijwel overeen komen. 

5.2 .5    Lekken van i n fo rm a t i e  

Webservers en webapplicaties kunnen op allerlei manieren informatie over zichzelf  ‘lekken’. Deze informatie kan een kwaadwillende helpen om een goed beeld tekrijgen van de omgeving waarin de webapplicatie zich bevindt. Op basis van deinformatie kan de kwaadwillende bijvoorbeeld vaststellen dat de webapplicatie

gebruik maakt van kwetsbare software. Het vervolg van deze paragraaf beschrijftenkele van de meest voorkomende vormen van lekken van informatie doorwebapplicaties.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 47/116

5.2.5.1 Uitgebreide foutmeldingen

Fouten in webapplicaties zullen zich altijd voordoen. Wat van belang is, is hoe dewebapplicatie met deze fouten omgaat. Sommige webapplicaties leveren bij hetoptreden van een foutsituatie allerlei informatie aan over de achtergrond(en) vande 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 tekrijgen in de programmalogica van een webapplicatie. Een foutmelding verteltvaak iets over de gebruikte database, het uitgevoerde SQL-verzoek of hetaangeroepen bestand. Al deze informatie draagt bij aan kennisvorming van dekwaadwillende over de infrastructuur. Stel bijvoorbeeld dat een webapplicatie eenSQL-injection kwetsbaarheid (5.2.3) bevat. De mogelijkheden die dekwaadwillende heeft zijn mogelijk redelijk beperkt als deze geen inzicht heeft inde opbouw van de code en de database. Wanneer de kwaadwillende er echter inslaagt om een foutmelding te forceren met daarin de beschrijving van een SQL-verzoek dat mislukt, dan heeft deze op dat moment voldoende informatie om metandere (soortgelijke) SQL-verzoeken te gaan experimenteren. De kwaadwillendeheeft op dat moment bijvoorbeeld kennis van attribuutnamen, tabelnamen,databasenamen, etc…

OPMERKING Ook het ontstaan van foutmeldingen kan men deels wijten aan hetonvoldoende controleren op input van gebruikers. Een foutmelding ontstaatnamelijk in veel gevallen doordat er zich een uitzondering voordoet binnen deprogrammalogica. Deze uitzondering kan ontstaan uit het feit dat een verwachteverbinding richting een database niet beschikbaar is maar ook omdat de

webapplicatie niet goed weet om te gaan met ‘afwijkende’ input’: de applicatiekrijgt bijvoorbeeld een string te verwerken terwijl het een getal verwacht. 

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 48/116

5.2.5.2  Header-informatie

HTTP-headers kunnen veel informatie verschaffen over de webapplicatie en desoftware waarvan de webapplicatie gebruik maakt. Eén van de bekendste HTTP-headers die informatie vrijgeeft is de “Server”-header. In veel gevallen zal dewebserver via deze header informatie geven over het type webserverwaarvandaan de pagina afkomstig is. In sommige gevallen bevat deze headerechter nog veel meer informatie. Figuur 5-4 geeft een voorbeeld van eendergelijke header.

Figuur 5-4: voorbeeld van HTTP-header informatie 

In figuur 5-4 is een voorbeeld opgenomen van een antwoord dat een webservergeeft n.a.v. het opvragen van een webpagina. Zoals in dit voorbeeld is te zientoont de webserver niet alleen de gebruikte webserver-versie (Apache/1.3.27 opRed Hat Linux) maar bijvoorbeeld ook de gebruikte versies van OpenSSL en PHP.Op basis van deze informatie kan een kwaadwillende zeer gerichte aanvallenuitvoeren op de webserver. Informatiebronnen als Secunia, de NationalVulnerability Database (NVD) en SecurityFocus kunnen de kwaadwillende hierbijvoorzien van de laatste kwetsbaarheden die bekend zijn met de gebruiktesoftware.

5.2.5.3  Commentaarregels in scripts

Commentaarregels in code kunnen ongewild informatie vrijgeven aan deeindgebruiker. Met name HTML-code en client-side scripts (zoals Javascript)kunnen dit commentaar bevatten. Commentaarregels zijn niet altijdproblematisch; in sommige gevallen bevat commentaar echter ‘eengeheugensteuntje’ voor programmeurs en vergeten zij deze informatie teverwijderen zodra een webapplicatie in productie gaat. Figuur 5-5 geeft een zeereenvoudig voorbeeld van commentaar in Javascript - in een inlogpagina - dat eenkwaadwillende kan lezen en mogelijk misbruiken.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 49/116

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

5.2 .6    Onve i l i ge opslag van i n fo r m a t i e  

Een webapplicatie maakt vaak gebruik van grote hoeveelheden informatie. Vanbelang is op welke manier de webapplicatie deze informatie opslaat. Technisch

gezien kan de webapplicatie voor opslag van gegevens gebruik maken van lokalebestanden op de webserver en databases. Vaak vindt de opslag van gegevensonversleuteld plaats. Dit kan ernstige gevolgen hebben wanneer eenkwaadwillende erin slaagt om deze gegevens te benaderen. Onderstaand volgentwee voorbeelden van situaties waarin de onversleutelde opslag van gegevens totproblemen leidt.

Voorbeeld #1: opslag van adresgegevens in een lokaal tekstbestand

Een webapplicatie verzamelt adresgegevens van particulieren. De organisatiegebruikt 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 gingervan uit dat deze gegevens hier veilig stonden omdat de webapplicatie draaitvanuit ‘/webapp/wwwroot/’ (webroot). Een kwaadwillende vindt echter een fout ineen script binnen de webapplicatie waardoor deze erin slaagt buiten de webroot tetreden. Het volgende verzoek naar de webapplicatie levert de kwaadwillende deinhoud van het bestand op:

http://www.eenwebsite.nl/showfile.php?file=%2Fwebapp%2Fabonnees.txt

Hoewel het onversleutelde bestand normaal gesproken niet via internet tebekijken is, zorgt de kwetsbaarheid in een script (showfile.php) binnen dewebapplicatie ervoor dat het bestand toch te benaderen en te lezen is.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 50/116

Voorbeeld #2: opslag van inloggegevens in een database

Een webapplicatie slaat gebruikersnamen en wachtwoorden onversleuteld op ineen database. Dit leidt normaal gesproken niet tot problemen aangezien dewebapplicatie de inhoud van deze tabel op geen enkele manier toont. Eenkwaadwillende vindt echter een SQL-injection kwetsbaarheid in de webapplicatie.Via deze kwetsbaarheid kan hij een SQL-verzoek richting de database versturendie alle gebruikersnamen en wachtwoorden van gebruikers toont.

Ook wanneer de webapplicatie gegevens wel versleuteld opslaat hoeft dit niet perdefinitie te betekenen dat dit veilig is. Veel is afhankelijk van het gebruiktealgoritme voor versleuteling van gegevens. Kiest men bijvoorbeeld voor een zeer

zwak algoritme of een algoritme dat men zelf bedacht heeft, dan is de kansaanwezig dat een kwaadwillende dit algoritme in korte tijd kraakt.

5.2 .7    Onve i l i ge conf igura t ie  

De configuratie van de webapplicatie en het applicatieplatform spelen eenbelangrijke rol in de beveiliging van het geheel. Door een webapplicatie en/of applicatieplatform te installeren zonder daarbij aandacht te besteden aan deconfiguratie ervan kunnen zich een aantal verschillende beveiligingsproblemenvoordoen. Enkele voorbeelden hiervan:

•  Gebruik van standaardpaden voor de webroot; veel webserverskennen een standaardpad voor de installatie van de webroot. In het gevalvan Microsoft Internet Information Server (IIS) is dit bijvoorbeeldc:\inetpub\wwwroot. Gebruik van standaardpaden kan kwaadwillendenhelpen om de absolute locatie van bestanden te bepalen en dit temisbruiken in scripts.

•  Gebruik van standaard gebruikersnamen en wachtwoorden; voor detoegang tot verschillende onderdelen van een webomgeving kan mengebruik maken van standaard aanwezige gebruikersnamen enwachtwoorden. Richt men bijvoorbeeld een Oracle-database in voor de

opslag van gegevens voor de webapplicatie dan zijn standaard een aantalaccounts in de database aanwezig (bijvoorbeeld gebruiker ‘system’ metwachtwoord ‘manager’). Wanneer men deze standaard gebruikersnamenen wachtwoorden niet wijzigt, kan een kwaadwillende zich mogelijk metdeze gegevens toegang verschaffen tot databases en andere applicaties.

VOORBEELD Van veel producten publiceert men bekendegebruikersnamen en wachtwoorden op internet. Dat een kwaadwillendeniet bekend is met een bepaalde applicatie betekent dus niet dat hij hieropniet zal kunnen inloggen met bekende gebruikersnamen en wachtwoorden.Zie bijvoorbeeld de volgende lijst van standaard gebruikersnamen enwachtwoorden die op internet terug te vinden is:http://www.phenoelit.de/dpl/dpl.html

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 51/116

•  Aanwezigheid van standaard plug-ins; een ‘kaal’ geïnstalleerdewebserver kent over het algemeen al een aantal plug-ins diefunctionaliteiten binnen de webserver ondersteunen. Een webapplicatiehoeft niet per definitie gebruik te maken van deze plug-ins. Dit kan ertoeleiden dat een bepaalde plug-in wel aanwezig is op een webserver, maardat geen aandacht is besteed aan de beveiliging ervan. Hierdoor kan eenmogelijk beveiligingslek ontstaan.

•  Ontbreken van patches; wanneer men een applicatieplatform installeertvanaf een medium (bijvoorbeeld CD-ROM) is de kans aanwezig dat op ditmedium nog niet de laatste patches voor het applicatieplatform zijn

geplaatst. Wanneer men vergeet om deze patches na installatie van dewebserver te downloaden en te installeren, bevat de applicatie ongedichtelekken. Het spreekt voor zich dat kwaadwillenden deze lekken kunnenmisbruiken om zich toegang te verschaffen tot de webserver of webapplicatie.

•  Aangeschakelde ‘debugging ’ -opties; sommige applicatieplatformenondersteunen standaard een aantal ‘debugging’-opties. Debugging isbedoeld om het aantal bugs (fouten) in een applicatie te verminderen doorduidelijke foutmeldingen te genereren in het geval zich een probleemvoordoet. Deze foutmeldingen kan een kwaadwillende in zijn voordeel

gebruiken (zie 5.2.5.1).

5.2 .8    Kw etsba re aangekoch te app l i ca t i es  

Bij het nemen van beveiligmaatregelen rondom webapplicaties bestaat de kansdat de focus voornamelijk gericht is op intern ontwikkelde applicaties. ‘Externaangekochte applicaties zijn veilig’, neigt men soms te denken. Niets is minderwaar. Ook extern aangekochte applicaties zullen kwetsbaarheden bevatten. En juist omdat deze externe aangekochte applicaties in gebruik zijn door meerklanten is de kans groter dat kwaadwillenden hun pijlen op deze applicatiesrichten en bijvoorbeeld exploits voor deze producten publiceren. Producten waar

men in dit verband aan kan denken zijn bijvoorbeeld Content ManagementSystemen (CMS), fora, PHP-bibliotheken en webmail-applicaties.

VOORBEELD In beveilgingsadvies MS06-029 beschrijft Microsoft eenkwetsbaarheid in Microsoft Outlook Web Access (OWA). Dit product vormt eenstandaard onderdeel van Microsoft Exchange Server en biedt gebruikers demogelijkheid om via internet hun (zakelijke) e-mail en agenda te beheren(webmail). Door misbruik te maken van deze kwetsbaarheid (een XSS-kwetsbaarheid) kunnen kwaadwillenden inloggegevens van OWA-gebruikersachterhalen. Dit voorbeeld schetst dat ook standaard webapplicaties kwetsbaarkunnen en zullen zijn. Meer informatie over deze specifieke kwetsbaarheid kunt uvinden op de Microsoft website(http://www.microsoft.com/technet/security/Bulletin/MS06-029.mspx) en inGOVCERT.NL beveiligingadvies GOVCERT.NL-2006-133 (bijlage B).

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 52/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 viaeen application-level firewall kan implementeren.

5.3 .1   Overw eeg de i nvoe r i ng van een app l i cat i on - l eve l f i r ew a l l  

Een application-level firewall heeft specifieke kennis van een bepaald protocol. Inhet geval van webapplicaties dient de application-level firewall diepgaande kennis

te hebben van het HTTP-protocol. Daarnaast is ook kennis van de payloads vanHTTP-berichten (XML in het geval van webservices) van belang. Een application-level firewall kan een zeer sterke beveiliging bieden tegen zowel bekende als niet-bekende 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 eenmaakt in de meeste gevallen gebruik van applicatie-proxies. Deze applicatie-proxies zetten, voor de totstandkoming van een verbinding tussen client enserver, aparte sessies op met de client en met de server. Op deze manier kunnende applicatie-proxies al het verkeer dat client en server met elkaar uitwisselen

inspecteren en op deze manier verdacht verkeer tegen houden. Een applicatie-proxy heeft specifieke kennis van een bepaald protocol. Wanneer men spreektover een application-level firewall die ingezet wordt voor de beveiliging vanwebapplicaties (een web application-level firewall) dan betekent dit dat de firewallgebruik maakt van applicatie-proxies die specifieke kennis hebben van HTTP enaanverwante 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 deDMZ-infrastructuur. Binnen de infrastructuur fungeert de application-level firewallals een reverse proxy. Dit betekent dat de application-level firewall alle

verbindingen vanaf een client richting een webapplicatie afhandelt en dat dereverse proxy (de application-level firewall) zélf een verbinding opzet met deachterliggende webapplicatie. Dit is dus precies een omgekeerde (reverse)werking van een ‘normale’ proxy waarbij de proxy intern verkeer naar externeservers verstuurt. Figuur 5-6 geeft een overzicht van mogelijke manieren waaropmen de application-level firewall in de DMZ van hoofdstuk 3 kan plaatsen.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 53/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 eenlosstaand netwerkcomponent binnen de DMZ-infrastructuur. Er bestaan echterook een aantal oplossingen die niet als losstaand netwerkcomponent maar alsplug-in op de webserver fungeren. Deze situatie is weergegeven in optie (d) infiguur 5-6.

5.3.1.3 Functionaliteiten

De functionaliteiten die application-level firewalls bieden, verschillen vanleverancier tot leverancier. Er zijn echter een aantal functionaliteiten die in veelproducten terugkeren:

•  Caching: het tijdelijk cachen van opgevraagde content (zoals bijvoorbeeldplaatjes) teneinde de load op de achterliggende webservers teverminderen.

•  Beheer via een eigen grafische gebruikersinterface; veel application-level firewalls komen in de vorm van een appliance en zijn via een (HTTP-)gebruikersinterface te beheren.

•  Redirecten van gebruikers afhankelijk van de gekozen URL; eenapplication-level firewall kan gebruikersverzoeken doorsturen naarverschillende achterliggende webservers. De keuze baseert de application-

level firewall hierbij op de gebruikte URL. Op deze manier is het mogelijkdat de inhoud van één website afkomstig is van verschillende

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 54/116

achterliggende webservers.

•  Uitvoeren van inputvalidatie (zie 5.3.2): deze inputvalidatie betreftvalidatie van gebruikte URL’s, inhoud van invoervelden, inhoud van XML-berichten, inhoud van parameters, grootte van het bericht, etc…

•  Terminatie van SSL-verbindingen (zie 5.3.3); omdat de application-level firewall fungeert als proxy termineert deze SSL-verbindingen. Dithoudt in dat de application-level firewall sites authenticeert middelsserver-side SSL-certificaten en daarnaast gebruikersauthenticatie middelsclient-side SSL-certificaten kan toepassen.

•  Controle van digitale handtekeningen (hoofdstuk 6); wanneer op basisvan standaard protocollen digitale handtekeningen op uitgewisseldeinformatie zijn geïmplementeerd, kan de application-level firewall dezehandtekeningen controleren en verkeer alleen accepteren wanneer dedigitale handtekening in orde blijkt te zijn. Deze functionaliteit isvoornamelijk aanwezig bij het gebruik van webservices.

•  Bescherming tegen lekken van informatie (zie 5.3.5); door deuitgebreide controles die de application-level firewall kan uitvoeren op deverschillende onderdelen van een HTTP-antwoord, kan deze gevoelige

informatie uit het antwoord filteren en een gefilterd antwoord retournerenaan de gebruiker.

•  Normaliseren van HTTP-verzoeken (zie 5.3.6); voordat een application-level firewall een HTTP-verzoek valideert, zal deze het verzoek eerstnormaliseren. Hierdoor voorkomt men dat kwaadwillenden viageë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 opbekende aanvalspatronen. Wanneer een HTTP-verzoek overeen komt meteen bekend patroon (bijvoorbeeld een bekend verzoek van een worm) dankan de application-level firewall dit verzoek blokkeren.

•  Controle op HTTP-methoden (zie 5.3.8); hoewel HTTP vanuit de RFCondersteuning biedt voor een groot aantal verschillende HTTP-methoden,gebruiken webapplicaties in de praktijk slechts twee van deze methodenveelvuldig: GET en POST. De application-level firewall kan mogelijkonveilige HTTP-methoden blokkeren.

•  Controle op gebruikte HTTP-headers (zie 5.3.10); zowel HTTP-verzoeken als HTTP-antwoorden kunnen beveiligingsproblemen opleverenwanneer deze speciale HTTP-headers bevatten. Een application-level

firewall kan diepgaande filtering op deze headers toepassen.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 55/116

•  Voorkomen misbruik van cookies (zie 5.3.11); webapplicaties makenvaak gebruik van cookies om statusinformatie op te slaan. Misbruik vandeze cookies kan leiden tot het omzeilen van authenticatie- enautorisatiemechanismen of inbreuk op de integriteit van gegevens. Doorcontroles uit te voeren op uitgewisselde cookies, voorkomt men datkwaadwillenden 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 alleverzoeken blokkeert, tenzij expliciet toegestaan. Bij een negatief beveiligingsbeleid blokkeert de application-level firewall helemaal niets, tenzijexpliciet verboden. Application-level firewalls die een positief beveiligingsbeleidhanteren (of in ieder geval daartoe de mogelijkheid bieden) krijgen vanuit hetoogpunt van beveiliging de voorkeur boven application-level firewalls die eennegatief beveiligingsbeleid implementeren.

Een positief beveiligingsbeleid werkt met een syntax waaraan een HTTP-verzoekmoet voldoen vanuit een vooropgestelde configuratie. De application-level firewall

blokkeert verzoeken die niet aan deze syntax voldoen. Op deze manier is de kansklein dat kwaadwillenden nieuwe – onbekende – kwetsbaarheden kunnenuitbuiten. Een negatief beveiligingsbeleid werkt op basis van aanvalspatronen(handtekeningen van kwaadaardige verzoeken). Alleen wanneer een verzoek blijktte matchen met een aanvalspatroon zal de application-level firewall dit verzoekblokkeren. Dit betekent in de praktijk dat de application-level firewall alleenbekende aanvallen richting de webapplicatie zal blokkeren. Veel application-levelfirewalls implementeren een positief beveiligingsbeleid en bieden de mogelijkheidom verzoeken die op basis van het positieve beveiligingsbeleid zijn toegestaan,als laatste controle ook nog eens tegen de verzameling van aanvalspatronen tehouden (negatief beveiligingsbeleid).

ACHTERGROND Application-level firewalls kennen veel benamingen. Hetartikel “Web Application Firewalls Primer” (INSECURE, 2006) geeft een overzichtvan 22 van deze benamingen. Enkele van de meest in het oogspringende zijn:Web Application Firewall, Application Level Gateway, Web Application Proxy, WebIntrusion Prevention System en Web Security Proxy. In dit document zullen weechter de term Application-level firewall hanteren.

Een application-level firewall werkt, zoals al eerder werd beschreven, in veelgevallen als een reverse proxy. Dit betekent dat de client nooit een rechtstreekseverbinding kan opzetten met de webserver; zodra een client een webpaginaopvraagt ontstaan in ieder geval twee verbindingen op IP-niveau: één tussen declient en de application-level firewall en één tussen de application-level firewall ende webserver. Een webserver logt normaliter bij alle verzoeken die het krijgt teverwerken ook het IP-adres van waaraf dit verzoek afkomstig is. In het geval men

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 56/116

gebruik maakt van een reverse proxy zal dit IP-adres dus altijd het IP-adres vande application-level firewall zijn via welke de client een verbinding krijgt. Omdatop deze manier waardevolle informatie verloren gaat, moet men eenconfiguratiewijziging doorvoeren op zowel de appliction-level firewall als dewebserver. Deze configuratiewijziging bestaat eruit dat de application-levelfirewall 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 vande application-level firewall in het requestlog plaatst, maar het IP-adres uit deeerder genoemde HTTP-header.

5.3.1.5  Voordelen

Één van de belangrijkste voordelen van de inzet van een application-level firewallis dat deze bescherming kan bieden tegen bekende én nieuwe (0-day)kwetsbaarheden. Door uit te gaan van een positief beveiligingsbeleid zal deapplication-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 leveranciersnieuwe kwetsbaarheden bekend maken en patches ter beschikking stellen is denoodzaak tot het installeren van deze patches wellicht iets minder dringend.Zolang de application-level firewall verzoeken blokkeert die de kwetsbaarheiduitbuiten, loopt de webserver/webapplicatie minder gevaar. Uiteraard is het nogsteeds 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 striktpositief beveiligingsbeleid, dwingen tot webapplicaties die voldoen aan strengevereisten op het gebied van beveiliging. Een strikt positief beveiligingsbeleid zorgter namelijk voor dat de application-level firewall veel verzoeken richting deapplicatie blokkeert zodra ze gebruik maken van vreemde karakters, vreemdeheaders, lange strings, relatieve paden, etc… Op deze manier dwingt deapplication-level firewall ontwikkelaars ertoe goed na te denken over de opbouwvan de applicatie. Uiteraard is het wel van belang dat systeemontwikkelaars op dehoogte zijn van het standaard beveiligingsbeleid zodat zij weten aan welkevoorwaarden een webapplicatie moet voldoen om zonder problemen te kunnenfunctioneren achter de application-level firewall.

OPMERKING Vrijwel alle application-level firewalls bieden mogelijkheden omaparte policies te definiëren op URL-basis. Dat betekent dat in theorie elkewebapplicatie een apart beveiligingsbeleid kan hanteren. Dit kan echter leiden toteen onoverzichtelijk geheel waarin zich beveiligingsproblemen voordoen. Het isdaarom aan te raden altijd te werken met een standaard positief beveiligingsbeleid en hier alleen in specifieke gevallen een uitzondering op temaken.

5.3.1.6  Voorbeelden

Application-level firewalls zijn in steeds grotere getale beschikbaar. Onderstaandvolgt – in alfabetische volgorde - een overzicht van enkele producten die veel vande functionaliteiten uit dit hoofdstuk implementeren. Het bestuderen van

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 57/116

informatie over deze producten kan bijdragen aan de kennisvorming over deproducten en de mogelijkheden ervan. Er is bij het overzicht onderscheid gemaakttussen application-level firewalls die zich voornamelijk richten op het controlerenvan HTTP/HTML-verkeer en application-level firewalls die zich voornamelijk richtenop 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 eenSSL-VPN ontsluit men interne applicaties via een SSL-interface. Op deze manierkunnen medewerkers van een organisatie bijvoorbeeld bestanden bekijken, e-mailraadplegen, verbinding maken met een Citrix-server, verbinding maken met eenSSH-service, etc… via een webinterface. SSL-VPN appliances lenen zich met namevoor toepassing in thuiswerken en extranetten. Een SSL-VPN biedt ookmogelijkheden om policies toe te passen op het verkeer dat eindgebruiker eninterne server met elkaar uitwisselen. Enkele voorbeelden van SSL-VPNappliances 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.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 58/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 EvaluationCriteria’. In dit document is een verzameling algemene criteria opgenomen dievan belang zijn bij het selecteren van een web application firewall voor eenorganisatie. Het document kunt u downloaden vanaf http://www.webappsec.org/projects/wafec/

5.3 .2    Voer i npu t va l i da t i e u i t  

Inputvalidatie is essentieel voor het afdoende kunnen beschermen van eenwebapplicatie tegen een verscheidenheid aan aanvallen. Cross-site scripting(5.2.2) en SQL injection (5.2.3) zijn bekende aanvallen die misbruik maken vanhet ontbreken van gedegen inputvalidatie. Inputvalidatie moet plaatsvinden opalle onderdelen van een HTTP-verzoek. Voordat inputvalidatie plaatsvindt op eenverzoek 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 bijvoorbeeldmaximaal 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 deaanwezigheid van speciale karakters. Bij SQL injection makenkwaadwillenden bijvoorbeeld veel gebruik van quotes (‘) en dubbelemintekens (‘--‘) om SQL-commando’s te kunnen injecteren. Dezekarakters horen veelal niet thuis in reguliere invoer en dient de applicatiedaarom uit te filteren.

•  Controle op sleutelwoorden. Door invoer te controleren op de

aanwezigheid van specifieke sleutelwoorden voorkomt men veel gebruikteaanvallen. Sleutelwoorden als ‘<script>’, ‘DELETE FROM’, ‘SELECT’, ‘INSERT’ en ‘DROP’ horen niet thuis in invoervelden, waardoor deapplicatie verzoeken waarin deze sleutelwoorden voorkomen vaak zonderproblemen kan blokkeren.

•  Controle op lengte en type van attachments. Sommige websitesbieden de mogelijkheid om bestanden te uploaden. Denk hierbij aan onlinefotoalbums e.d. Belangrijk is in dit geval te controleren of het typeattachment 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 deschijven van de webserver laten vollopen en extreem veel resources(bandbreedte, CPU, etc…) gebruiken.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 59/116

•  Controle tegen een vooropgesteld XML-template. XML-berichten diemen uitwisselt via webservices zijn vrijwel altijd gebaseerd op XML-templates. Deze XML-templates nemen vaak de vorm aan van een WebService Description Language (WSDL) bestand. Het WSDL-bestandbeschrijft welke namespaces de webservice gebruikt, welke methoden dewebservice ondersteunt, welke attributen de webservice verwacht (of verplicht stelt) en hoe deze attributen moeten zijn opgebouwd. Door eenaangeboden XML-bericht te controleren tegen het XML-template, kan menvaststellen of het XML-bericht voldoet aan datgene wat de webapplicatieverwacht. Afwijkingen van het XML-template duiden mogelijk op eenpoging tot misbruik.

Figuur 5-7 geeft een voorbeeld van een definitie uit een WSDL-bestand. Indit voorbeeld is te zien dat de WSDL beschrijft welke data-typen deapplicatie verwacht en hoe vaak een bepaald type moet en magvoorkomen in een ‘sequence’.

Figuur 5-7: definitie uit een WSDL-bestand 

Alle bovenstaande controles dient men uit te voeren op alle onderdelen van hetHTTP-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 HTTP-verzoek vanaf een client met daarin de onderdelen waarop de applicatie controleskan uitvoeren.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 60/116

Figuur 5-8: onderdelen van een HTTP-verzoek

Inputvalidatie past men in sommige gevallen al toe op de client. Zo kan menbijvoorbeeld in webformulieren een maximale lengte van het invoerveld bepalen

(via het MAXLENGTH attribuut). Deze controles aan de clientkant voorkomen datreguliere gebruikers verkeerde invoer versturen. Het voorkomt echter niet datkwaadwillenden verkeerde invoer versturen. Het is immers eenvoudig om debeperkingen van een formulier te omzeilen door buiten de webbrowser om eenverzoek richting de webapplicatie te versturen. Inputvalidatie via de browser kandus helpen om de invoer van een reguliere gebruiker te sturen maar mag nooit alsbeveiligingsmiddel 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 opde vraag hoe de applicatie kan voorkomen dat deze onbedoeld informatie ontsluitrichting clients.

5.3 .3    M aak (ex t e rn ) geb ru i k van SSL-ve rb i nd ingen  

HTTP biedt standaard ondersteuning om een versleutelde verbinding op te zettentussen de client en server. Voor de versleuteling maakt HTTP gebruik van hetSecure Sockets Layer protocol (SSL) of de opvolger daarvan: het Transport LayerSecurity (TLS) protocol. Door de verbinding richting de webapplicatie teversleutelen middels SSL of TLS voorkomt men dat kwaadwillenden eenvoudig deverkeersstromen tussen client en server kunnen inzien. Men moet zich bij hetgebruik van SSL en TLS wel beseffen dat het hier versleuteling op transportniveaubetreft. Op de server zorgt het webserverproces voor ontsleuteling van deinformatie waarna de webapplicatie met onversleutelde informatie aan de slaggaat. Om informatie ook versleuteld op te slaan in bestanden en databases aanserverzijde dient men aparte maatregelen te treffen (zie 5.3.12).

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 61/116

Bij de inzet van een application-level firewall handelt niet de webserver maar deapplication-level firewall de SSL-verbinding af. Zodra de SSL-verbinding tot standis gekomen, zal de application-level firewall de verbinding doorproxien naar deachterliggende webserver. De verbinding tussen de application-level firewall en deachterliggende webserver hoeft niet per definitie op basis van SSL of TLS teworden gerealiseerd. Aangezien deze laatste verbinding zich vrijwel altijd in eenvertrouwde en afgeschermde omgeving bevindt (de DMZ van de organisatie), kanmen er ook voor kiezen deze verbinding te baseren op het onversleutelde HTTP.Het voordeel van een dergelijke aanpak is dat de achterliggende webserver nietwordt belast met SSL-versleuteling en dat daarnaast de mogelijkheid bestaat omhet verkeer te laten bekijken door eventueel aanwezige Intrusion Detection

Systemen (IDS). Daar waar een IDS normaal gesproken het verkeer richting eenSSL-beveiligde webapplicatie niet kan monitoren, kan dit door de inzet van eenapplication-level firewall in combinatie met een HTTP-verbinding tussen deapplication-level firewall en de webapplicatie plotseling wel. Zie hoofdstuk 9 voormeer informatie over de inzet van een IDS. Figuur 5-9 illustreert het hierbovenbeschreven 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 vanHTTP richting de achterliggende webservers communiceert (zoals in figuur 5-9),betekent dit wel dat de achterliggende webservers niet de beschikking krijgenover de SSL-authenticatieinformatie in het geval de application-level firewall hetgebruik van clientcertificaten heeft afgedwongen. Mocht de webapplicatie dezeinformatie wel nodig hebben, dan kan de application-level firewall deze informatie

veelal doorgeven via (door de application-level firewall) ingevoegde HTTP-headersof toegevoegde parameters bij een URL-aanroep. Dit is een functionaliteit die deaandacht krijgt in de laag beveiligingsintegratie (hoofdstuk 8).

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 62/116

OPMERKING Het centraliseren van SSL-terminatie op een application-levelfirewall heeft ook als voordeel dat alle “SSL-rekenkracht” aan dit component kanworden toegevoegd. Zo kan men de application-level gateway uitrusten met eenhardware accelerator die het ver- en ontsleutelen van SSL-gegevens versnelt eneventueel veilige opslag van het privé-gedeelte van sleutelparen mogelijk maakt.Wanneer elke webserver afzonderlijk SSL zou moeten ondersteunen, betekent ditdat hergebruik van deze hardware accelarators voor verschillende webapplicatiesniet mogelijk is.

Bij gebruik van SSL heeft men de keuze tussen verschillendeversleutelingsprotocollen voor (1) het uitwisselen van sleutels, (2) hetauthenticeren 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 SSL-beveiliging breken.

VOORBEELD Apache, een bekende webserver, biedt standaard de mogelijkheidom alleen sterke protocollen toe te staan voor SSL. Door het opnemen van deregel ‘SSLCipherSuite HIGH:MEDIUM’ in het Apache configuratiebestand dwingtApache af dat de webserver alleen sterkere protocollen ondersteunt. Wanneer eengebruiker een verbinding opzet en verzoekt om het gebruik van een zwakker

protocol dan zal de webserver deze verbinding niet accepteren.

5.3 .4    V oo r k o m h e t l e k k e n v a n i n f o r m a t i e  

Het lekken van informatie richting een kwaadwillende moet men zoveel mogelijkvoorkomen. De volgende aanbevelingen beschrijven de belangrijkste manierenwaarop de applicatie dit kan voorkomen:

•  Retourneer alleen standaard HTTP-headers. Alleen headers die voorhet functioneren van HTTP van belang zijn, dient men te retourneren aangebruikers (RFC 261612 voor HTTP/1.1, RFC 194513 voor HTTP/1.0). Alle

overige HTTP-headers kan de applicatie in de regel zonder gevolgen uiteen HTTP-antwoord verwijderen (zie ook 5.3.9).

•  Beperk informatie in de standaard HTTP-headers. Het is voor eenclient bijvoorbeeld niet van belang om te weten welk type webserverantwoord heeft gegeven op het HTTP-verzoek. Daarom kan men ervoorkiezen om bijvoorbeeld de “Server”-header uit het antwoord teverwijderen of deze te voorzien van een nietszeggende inhoud als “Server:WebServer 1.0”.

12 Zie: http://rfc.net/rfc2616.html13 Zie: http://rfc.net/rfc1945.html

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 63/116

•  Voorkom het lekken van gedetailleerde foutmeldingen. Op hetmoment dat er zich een probleem voordoet binnen een webapplicatie zalde webserver veelal een statuscode “500 Internal Server Error” retourneren. Deze statuscode wijst erop dat er zich een exceptie heeftvoorgedaan en dat de webserver mogelijk gevoelige informatie m.b.t. deapplicatielogica openbaart (databasenamen, gebruikersnamen,bestandsnamen, interne IP-adressen, etc…). In het geval een application-level firewall een dergelijke statuscode detecteert kan deze een standaardfoutmelding (bijvoorbeeld “Er heeft zich een onbekende fout voorgedaan.”)retourneren aan de client en het gedetailleerde antwoord van dewebserver 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 elkewebapplicatie dient men zich af te vragen welke codes legitiem voor dezewebapplicatie zijn en welke niet. Zo kunnen ook codes als “501 NotImplemented”, “405 Method Not Allowed” en “414 Request-URI Too Long” ongewenst zijn en de kwaadwillende helpen in het footprinten van deapplicatie. Bedenk goed hoe de webapplicatie met deze verschillendecodes om moet gaan en welk antwoord de webapplicatie (of deapplication-level firewall) in een dergelijk geval moet retourneren aan deeindgebruiker.

•  Voorkom de aanwezigheid van commentaarregels in scripts.Voordat men code vanuit een acceptatie- of testomgeving in productieplaatst, moet men eerst een scan uitvoeren op de aanwezigheid vancommentaarregels in scripts. Dit is veelal vrij eenvoudig te realiserenomdat 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   

Norm al i seer HTTP-verzoeken HTTP-verzoeken kunnen allerlei ‘vreemde’ onderdelen bevatten. Er kunnen in hetverzoek speciale karakters geencodeerd zijn, de URL kan ‘backslashes’ in plaatsvan ‘forward slashes’ bevatten, etc… Al deze afwijkingen kunnen wijzen op eenkwaadwillende die de webapplicatie op één of andere manier wil misbruiken en debeveiliging, die de application-level firewall biedt, wil omzeilen. Daarom is hetbelangrijk om HTTP-verzoeken eerst te normaliseren ofwel ‘normaal te maken’.Policies e.d. past men het beste toe op een genormaliseerd verzoek in plaats vanop een ruw verzoek teneinde foute beslissingen te voorkomen. Normaliseren vanHTTP-verzoeken houdt in dat men in ieder geval de volgende acties uitvoert opdeze verzoeken:

•  URL decodering; URL encodering is ooit ontstaan uit het feit dat niet allesoorten karakters zijn toegestaan in een URL. Om dit probleem teomzeilen bedacht men het concept van geencodeerde karakters. De

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 64/116

encodering bestaat eruit dat de client niet het karakter, maar dehexadecimale waarde van het karakter in de URL plaatst. Een spatie komtop deze manier als ‘%20’ in een URL terecht en een komma als ‘%2C’.URL encodering kan men voor alle mogelijke karakters uitvoeren. Hierdoorkan het gebeuren dat een kwaadwillende speciale karakters of karakterreeksen niet direct opneemt in een URL, maar deze encodeert. Opdeze manier hoopt de kwaadwillende controles te omzeilen. Daarom is hetbelangrijk dat een applicatie een HTTP-verzoek eerst decodeert alvorenshiermee 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 HTMLkarakters te encoderen zoals ampersand tekens (‘&amp;’), groter-dantekens (‘&gt;’), kleiner-dan tekens (‘&lt;’), etc… De applicatie moet dezegeencodeerde karakters decoderen alvorens met de verwerking van deinvoer te starten.

•  Pad normalisatie; pad normalisatie betekent dat een applicatie allerelatieve padverwijzingen uit een URL filtert en een absolute URLsamenstelt. 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 niettoegestaan omdat de uiteindelijke – genormaliseerde – directory buiten dewebroot valt). Ook invoervelden waarvan een webapplicatie gebruiktmaakt, dient de applicatie te controleren op genormaliseerde paden.

•  Converteren backslashes naar forward slashes; het web maaktgebruik van forward slashes (‘/’) in plaats van backslashes (‘\’). Deaanwezigheid van backslashes kan duiden op een poging tot misbruik vaneen op Windows-gebaseerd systeem. Aangezien backslashes nietthuishoren in HTTP-verzoeken moet de applicatie deze backslashes ‘vertalen’ naar forward slashes.

5.3 .6    Sta a l leen benod igde HTTP-met hoden t oe  

HTTP ondersteunt verschillende methoden (zie tabel 5-1). In de praktijk gebruikteen webapplicatie alleen de methoden GET en POST. Voor veel scripts en objectenop een webserver geldt zelfs dat alleen de GET-methode benodigd is. Methodenanders dan GET en POST zijn vrijwel nooit benodigd en vormen alleen een extrabeveiligingsrisico. Niet benodigde methoden kan men daarom via configuratie vande webserver of via de application-level firewall blokkeren.

Methode Omschrijving

CONNECT Een methode die aangeeft dat een tussenliggende proxy hetverzoek niet mag aanpassen c.q. onderzoeken en simpelweg moet

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 65/116

Methode Omschrijving

doorsturenDELETE Verwijderen van het object op de webserver onder de gedefinieerde

URLGET Opvragen van informatie betreffende het objectHEAD Idem aan GET met het verschil dat bij HEAD de webserver niet de

body van het bericht retourneertOPTIONS Biedt de mogelijkheid om te achterhalen welke HTTP-methoden een

specifiek object ondersteuntPOST Versturen van gegevens richting de webserver om verwerkt te

worden door het objectPUT Plaatsen van een nieuw object op de webserver onder de

gedefinieerde URLTRACE Bedoeld om te zien hoe het HTTP-verzoek terecht komt op de

webserver en daarom vooral geschikt voor het uitvoeren testen enhet verkrijgen van diagnostische informatie

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

VOORBEELD Veel webservers bieden de mogelijkheid om alleen selectief HTTP-methoden toe te staan. Lotus Domino, een webserver van IBM, biedt dezemogelijkheid ook. In onderstaande afbeelding is een Lotus Domino website te zien

die alleen de methoden GET, HEAD, POST, OPTIONS en TRACE toestaat. Zie voormeer informatie over het configureren van deze methoden onder Lotus Domino,zie: http://www-1.ibm.com/support/docview.wss?uid=swg21201202

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 66/116

5.3 .7    Sta beperk t b es tandsex t ens ies toe  

De bestandsextensie is meestal het gedeelte achter de laatste ‘.’ in een URL. Debestandsextensie bepaalt welk type bestand de client bevraagt. Naast standaardbestandsextensies (.html, .htm, .jpeg, .jpg, etc…) ondersteunen veel webserversook minder generieke bestandsextensies (bijvoorbeeld .aspx voor Microsoft .NETwebservers, .jar voor Websphere servers, etc…). Vaak ondersteunt een webservermeer extensies dan daadwerkelijk benodigd is voor het goed functioneren van dewebapplicatie. In dit soort gevallen is het aan te raden om deze extensiesonschadelijk te maken omdat elke extensie een mogelijke nieuwe ingang is totmisbruik van de webserver. Niet gebruikte bestandsextensies kunnen op devolgende manieren onschadelijk worden gemaakt:

•  Door het uitvoeren van een controle op de bestandsextensie op

een application-level firewall. Een application-level firewall kan eenHTTP-verzoek ontleden en bepalen welke bestandsextensie isaangeroepen. Alleen wanneer de bestandsextensie voldoet aan een de lijstmet standaard toegestane extensies zal deze het verzoek doorlatenrichting de webapplicatie. In alle andere gevallen blokkeert de application-level firewall het verzoek. Zelfs wanneer de webserver een bepaaldegevaarlijke bestandsextensie ondersteunt (bijvoorbeeld .exe) zal dekwaadwillende er, bij een strikte configuratie van de application-levelfirewall, niet in slagen om bestanden met deze extensie aan te roepen op

de webserver.

•  Door het hardenen van de webserver . Na installatie van eenwebserver ondersteunt deze out-of-the-box een verzameling extensieswaarvan de webapplicatie zeer waarschijnlijk maar een gedeeltedaadwerkelijk gebruikt. Door de configuratie van de server te veranderen(bijvoorbeeld het verwijderen van ISAPI-filters op een Microsoft IIS-server) voorkomt men dat de webserver bepaalde extensies ‘begrijpt’ enverwerkt.

Bij het gebruik van een application-level firewall hoeft men het blokkeren van

bestandsextensies slechts op te nemen in het standaard beveiligingsbeleid waarnade application-level firewall dit voor elke webapplicatie bekrachtigt. Kiest menervoor om bestandsextensies te blokkeren door het hardenen van webservers,dan zal men elke webserver (en mogelijk ook elke virtuele website op dezewebserver) apart moeten configureren.

VOORBEELD Een voorbeeld van een zeer gevaarlijke bestandsextensie bijuitstek is de .exe bestandsextensie op Windows-servers. Op het moment dat eenkwaadwillende erin slaagt om bijvoorbeeld de cmd.exe executable aan te roepenop 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 misbruikop deze manier. De alom bekende Nimda-worm maakt bijvoorbeeld misbruik vande cmd.exe executable (via een verzoek als ‘GET

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 67/116

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

5.3 .8    Cont ro leer verzoeken tegen bekende aanva lspat ronen 

Application-level firewalls bieden doorgaans de mogelijkheid om HTTP-verzoekente controleren tegen een lijst van bekende aanvalspatronen. Deze vorm vannegatief beveiligingsbeleid past men in de regel alleen toe als laatste controle opeen HTTP-verzoek. Op het moment dat een applicatie het HTTP-verzoekcontroleert tegen de lijst met aanvalspatronen moeten de syntactische controlesvanuit het positieve beveiligingsbeleid al zijn uitgevoerd zonder (negatief)resultaat. Door te controleren tegen bekende aanvalspatronen voorkomt men dataanvallen die syntactisch volledig in orde zijn toch de webapplicatie bereiken.

Een negatief beveiligingsbeleid vereist wel dat de application-level firewall continuwordt voorzien de laatste signatures. Verzuimt men deze nieuwe signaturesbeschikbaar te stellen aan de application-level firewall dan zal ook het negatievebeveiligingsbeleid geen beveiliging kunnen bieden tegen recente exploits, wormenen virussen.

5.3 .9    Cont ro leer de inh oud v an HTTP-headers  

Ook HTTP-headers bieden kwaadwillenden de mogelijkheid om misbruik van eenwebapplicatie te maken. Controle op de inhoud van deze HTTP-headers is daaromook belangrijk. Een controle op deze headers moet zowel plaatsvinden op hetHTTP-verzoek als op het HTTP-antwoord. In het geval een application-levelfirewall een HTTP-header detecteert die niet voldoet aan de policy kan het devolgende beslissingen nemen:

•  De inhoud van de header aanpassen en deze aangepaste headerdoorlaten;

•  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-headersen de oplossing die filtering van deze headers in dit geval biedt.

Voorbeeld #1: ongewenste authenticatie Een bepaalde webapplicatie is alleen bedoeld voor gebruik door anoniemegebruikers. Dit betekent dat gebruikers zich in geen enkel geval hoeven teauthenticeren tegen de webapplicatie. De anonieme gebruiker heeft minimalerechten op het bestandssysteem van de webserver. Op de webserver is ook een

 ‘administrator’-account aanwezig dat uiteraard veel uitgebreidere rechten heeftdan de anonieme gebruiker. Een kwaadwillende wil proberen om een verbindingmet de webapplicatie te krijgen om vervolgens te gaan werken onder het

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 68/116

 ‘administrator’-account in plaats van het anonieme account. Hiertoe voegt dekwaadwillende een ‘Authorization’ header toe aan het HTTP-verzoek:

 Authorization: Basic YWRtaW46YWRtaW4=

Hoewel de webserver geen authenticatie afdwingt accepteert deze deAuthorization-header wel en zal de webserver proberen om de gebruiker teauthenticeren op basis van de meegestuurde authenticatiegegevens(admin:admin in dit geval). Indien dit succesvol is, krijgt de kwaadwillende debeschikking over een verbinding op basis van uitgebreidere toegangsrechten.

In de application-level firewall configureert men dat het hier gaat om een publiekewebapplicatie zonder authenticatie. Daarom filtert de application-level firewallHTTP-headers die bedoeld zijn voor authenticatie uit het bericht, waardoor hetgefilterde verzoek zonder de ‘Authorization’ header terecht komt bij dewebapplicatie. De kwaadwillende slaagt er hierdoor niet in om zich tegen dewebserver authenticeren en onder het ‘administrator’-account een verbinding metde webapplicatie op te zetten.

Voorbeeld #2: ongewenst lekken van informatie

Een webserver lekt via HTTP-headers allerlei informatie over de gebruiktesoftware op de webserver. De application-level firewall zorgt ervoor dat deze

informatie niet terecht komt bij de eindgebruiker door bepaalde HTTP-headers uitte filteren en de inhoud van andere HTTP-headers te wijzigen. Figuur 5-5 geefteen voorbeeld van de werking van een application-level firewall als het gaat omhet 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 aantalHTTP-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 clientzonder daarbij ongewenst informatie over de webserver te lekken.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 69/116

5.3 .10    Con t r o l eer h e t geb ru i k van cook ies  

Cookies vormen een veelgebruikt middel om statusinformatie vast te leggen. Eenwebserver verstuurt een cookie richting de client via een ‘Set-Cookie’ HTTPresponseheader; een client biedt een cookie aan een webapplicatie aan via een ‘Cookie’ HTTP requestheader. Kwaadwillenden kunnen het cookiemechanismemisbruiken om bijvoorbeeld sessies te ‘spoofen’ om op die manierongeautoriseerd toegang te verkrijgen tot een webapplicatie. Door aan deserverkant actief te controleren op het gebruik van deze cookies kan men de kansop misbruik hiervan verminderen. Een application-level firewall kan wederom een

rol spelen in het blokkeren van verzoeken met ongeldige cookies. Een mogelijkproces 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 dewebserver via een ‘Set-Cookie’ HTTP-header (1). De application-level firewallregistreert de uitgifte van dit cookie in een eigen database (2). Naast de inhoudvan het cookie registreert de application-level firewall bijvoorbeeld ook een IP-adres waarnaar deze het cookie zal versturen en de webapplicatie die het cookieheeft 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 ditzelfdecookie te gebruiken om ook toegang tot de webapplicatie te verkrijgen (4). Dekwaadwillende heeft bijvoorbeeld opgemerkt dat het sessie-ID voorspelbaar is en

probeert daarom, via een ‘gespoofed’ sessie-ID in een cookie, een sessie met dewebserver op te bouwen. De application-level firewall controleert vervolgens deinhoud van het aangeboden cookie tegen de database met uitgegeven cookies

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 70/116

(5). De application-level firewall zal vervolgens vaststellen dat het betreffendecookie nooit is uitgegeven of niet is uitgegeven aan de betreffende client. Deapplication-level firewall zal het verzoek daarom blokkeren en niet doorsturennaar de webserver waardoor misbruik van het cookiemechanisme is voorkomen.

OPMERKING Ook wanneer men geen gebruik maakt van een application-levelfirewall kan men deze controle op cookies uitvoeren. De webapplicatie zal dezefunctionaliteit in dit geval moeten bieden. Dit betekent een extra inspanning ophet gebied van systeemontwikkeling.

5.3 .11   Richt een so l ide updatem echan isme in  

Een solide updatemechanisme is essentieel om voldoende beschermd te zijn tegenbekende beveiligingsproblemen in software. Deze aanbeveling vond u eerder alterug in hoofdstuk 4 (Platformbeveiliging). Een updatemechanisme voor alleapplicatieplatformen, applicaties, databases, etc… die bovenop dit platformdraaien is minstens zo belangrijk. Zorg er daarom voor dat de verschillendestappen uit patch management (vaststellen, beoordelen, verkrijgen, testen,uitrollen en monitoren) ook zijn ingeregeld voor dit soort applicaties.

5.3 .12    Schake l ‘d i rec tory l i s t ings ’ u i t  

Via een zogenaamde ‘directory listing’ kan een gebruiker via internet de inhoudvan een directory bekijken. Het opvragen van een ‘directory listing’ via internetkomt overeen met het lokaal uitvoeren van een dir-commando onder Windows of een ls-commando onder Unix/Linux. Zodra een webserver de mogelijkheid biedtom ‘directory listings’ uit te voeren, bestaat de mogelijkheid dat eenkwaadwillende de inhoud van ‘vertrouwelijke’ directories raadpleegt (zoals de ‘/etc/’-directory onder Unix-/Linux-systemen). De toegang tot bestanden indirectories moet altijd verlopen via de webapplicatie: de webapplicatie geeftabsolute paden door voor bestanden die de gebruiker rechtstreeks magbenaderen (bijvoorbeeld afbeeldingen) en fungeert als medium voor bestandendie de gebruiker niet rechtstreeks mag benaderen (bijvoorbeeld

gegevensbestanden).

5.3 .13    Hanteer sa fe cod ing techn ieken 

Veel van de maatregelen die dit hoofdstuk voorstelt, hebben te maken met veiligprogrammeren (safe coding). Het is van belang om tijdens het ontwikkelen vaneen applicatie het aspect beveiliging continu in het achterhoofd te houden. Erbestaan enkele vuistregels die kunnen helpen om de veiligheid van code tevergroten. De belangrijkste vuistregels vindt u hieronder. Ten overvloede merkenwe hierbij op dat enkele vuistregels al eerder de revue passeerden of onderdeeluitmaakten van een andere maatregel. Het gaat om de volgende vuistregels:

•  Valideer alle invoer van een gebruiker (5.3.2).

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 71/116

•  Zorg voor een veilige beëindiging van een programma. Ongeacht de redenwaarom de uitvoer van een programma stopt, moet dit op een veiligemanier gebeuren. Dit betekent dat het programma alle mogelijkefoutsituaties (bijvoorbeeld ongeldige invoer, database niet beschikbaar,onvoldoende rechten bij het schrijven naar een bestand, etc…) correctafhandelt. In theorie betekent dit dat een webapplicatie nooit en tenimmer een statuscode 500 (Internal Server Error) retourneert.

•  Normaliseer alle invoer alvorens deze te verwerken (5.3.5). Zorg ervoordat geencodeerde strings e.d. uit de invoer zijn verdwenen alvorens hierverdere 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 hetafhandelen van gevoelige informatie in code op welke manier de applicatiedeze informatie zo veilig mogelijk kan behandelen.

•  Maak hackers niet wijzer dan ze al zijn. Dit komt er in het kort op neer datmen geen gevoelige informatie via de code zou moeten lekken; specifiekvoor webapplicaties gaat het om het lekken van informatie via HTTP-headers, foutmeldingen en commentaar in code (5.3.4).

•  Repareer niet alleen fouten, bestudeer ze aandachtig. Zelfs bijprofessionele software komt het voor dat de leverancier eenkwetsbaarheid in functie A verhelpt en exact dezelfde kwetsbaarheid in

functie B over het hoofd ziet. Hierdoor is het programma na het verhelpenvan de fout nog steeds kwetsbaar. Belangrijk is daarom om bij hetverhelpen van een fout te bedenken of deze fout zich ook op andereplekken kan manifesteren en of men alleen de aanvalsvector heeftweggenomen of daadwerkelijk het probleem heeft opgelost.

5.3 .14    Voer een (geau tom a t i see rde ) code rev i ew u i t  

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 dergelijkeblackbox test (dynamische analyse) zal echter niet in alle gevallen alle potentiële

problemen in een webapplicatie detecteren. Daarom is het verstandig dat menook een code review uitvoert (statische analyse); bij een code review scant eenpersoon (anders dan de ontwikkelaar) of een programma de programmacode opmogelijke kwetsbaarheden. Deze whitebox aanpak kan problemen aan het lichtbrengen die men via een blackbox aanpak niet zal kunnen zien. Daarnaast kanmen de geautomatiseerde code review in verschillende stadia van hetontwikkelproces uitvoeren teneinde fouten in een vroeg stadium te kunnenverhelpen. Nadeel is echter dat een code review meer inspanning kan vergen alseen blackbox test.

Tools voor het uitvoeren van geautomatiseerde code reviews bestaan er in velesoorten en maten, van open source software tot prijzige commerciëletoepassingen. Onderstaande - niet uitputtende - lijst geeft enkele punten weerwaarop een geautomatiseerde tool kan controleren:

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 72/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 a l le maat rege len op a l le app l i ca t ies toe  

Zorg ervoor dat alle voorgaande maatregelen worden toegepast op alle in gebruikzijnde webapplicaties binnen de organisatie. De maatregelen moeten dus, waar

mogelijk, van toepassing zijn op zowel intern ontwikkelde applicaties als externaangekochte applicaties.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 73/116

6  IDENTITEIT- EN TOEGANGSBEHEER

Identiteitbeheer en toegangsbeheer zijn onlosmakelijk met elkaar verbonden.Toegangsbeheer is niet mogelijk zonder dat een correcte invulling is gegeven aanidentiteitbeheer. Dit hoofdstuk behandelt daarom deze twee lagen uit het RBWgezamenlijk.

6.1   Inleiding

Van Dale definieert een identiteit als ‘iets wat eigen is aan een persoon’. In meertechnische zin bestaat een identiteit uit een identifier, een authenticator en eenprofiel. 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 denkenaan een gebruikersnaam of een persoonsnummer als identifier. De identifier isuniek binnen een bepaald domein: zo is een gebruikersnaam (identifier) uniekbinnen een applicatie (domein) en is een persoonsnummer (identifier) uniekbinnen Nederland (domein). Daarnaast is de identifier over het algemeen nietonderhevig aan een lifecycle. De gebruikersnaam van een medewerker voor eenbepaalde applicatie wijzigt bijvoorbeeld vrijwel nooit en het persoonsnummer dateen inwoner van Nederland bij geboorte krijgt verandert nooit meer tot zijn/haar

dood.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 74/116

De authenticator is datgene dat een persoon gebruikt om de identifier te ‘bewijzen’. Om te bewijzen dat een gebruikersnaam een valide identifier is, moeteen gebruiker ook zijn wachtwoord (authenticator) opgeven. Om te bewijzen dathet persoonsnummer inderdaad een bepaalde persoon toebehoort, moet dezepersoon zijn paspoort (authenticator) tonen. Authenticatoren verschillen veelal insterkte. Zo vormt een wachtwoord van drie letters een stuk minder sterkeauthenticator dan een certificaat dat is opgeslagen op een smartcard. Daarnaastdient men de authenticator beveiligd op te slaan. Een paspoort hoort normaalgesproken in de kluis, een wachtwoord in het hoofd (en in de kluis). Doordat eengebruiker zijn wachtwoord bijvoorbeeld kan opschrijven op een ‘geeltje’ is dezeauthenticator een stuk minder sterk. Tot slot is een authenticator onderhevig aan

een lifecycle. Een wachtwoord zou men bijvoorbeeld elke maand moetenveranderen, een paspoort moet men elke 10 jaar vernieuwen.

Het profiel bevat tot slot bepaalde kenmerken (attributen, rollen en data) dietoebehoren aan de identiteit. Hierbij moet men denken aan de rol die eenmedewerker vervult (bijvoorbeeld manager) of de datum waarop een medewerkerin dienst is getreden. De gegevens uit het profiel slaan applicaties veelal inverschillende repositories op (bijvoorbeeld in een personeelssysteem en op hetintranet). Daarnaast kunnen de gegevens uit het profiel regelmatig wijzigen en isde informatie uit het profiel vaak privacy gevoelig.

De identifier en/of het profiel bepaalt vervolgens welke autorisaties een gebruikerkrijgt binnen de webapplicatie. Er bestaan verschillende autorisatiemechanismenom deze autorisatie op te baseren. Enkele van de meest bekendeautorisatiemechanismen zijn:

•  Role-based Access Control; toegang tot (onderdelen van) dewebapplicatie is afgeschermd door het toekennen van rollen aangebruikers en het toekennen van rechten aan rollen.

•  Rule-based Access Control; beschrijft specifieke regels waaraan eengebruiker moet voldoen (bijvoorbeeld attribuut x >= 1) voordat dezetoegang krijgt op basis van gegevens uit zijn/haar profiel. Bij rule-basedaccess control hoeft het controlerende mechanisme alleen attributen vaneen gebruiker te controleren. Daarom kan rule-based access controlperformancevoordelen geven boven control mechanismen waarbij deserver bijvoorbeeld een grote groep moet nalopen op een mogelijklidmaatschap van een bepaalde gebruiker.

•  Mandatory Access Control (MAC); bij dit model baseert men deautorisaties op classificaties of labels aan een object gecombineerd methet classificatieniveau of labels van de gebruiker.

•  Discretionary Access Control (DAC); toegang tot bestanden wordt

bepaald door de rechten die een gebruiker heeft toegewezen gekregen. Deeigenaar van het bestand kan vervolgens zelf weer rechten uitdelen aanandere gebruikers.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 75/116

OPMERKING Onder identiteitbeheer verstaat dit hoofdstuk alle activiteiten dienodig zijn in het kader van identiteiten. Het gaat hier dus om het toevoegen,verwijderen en wijzigen van identiteiten maar zeker ook om het authenticeren vanidentiteiten op basis van hun authenticator. Op eenzelfde manier betrefttoegangsbeheer alle activiteiten die applicaties moeten uitvoeren om deautorisaties 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 zichvoor kunnen doen op het gebied van identiteit- en toegangsbeheer.

6.2 .1   Fou t i eve im p lem en ta t i e van au th en t i ca t i e en  

sess iemanagement  

Zoals eerder in dit document al werd beschreven, kent HTTP standaard geenmechanisme om de status van een sessie te behouden. Wanneer een gebruikerzich heeft geauthenticeerd tot een webapplicatie, is het uiteraard wenselijk dat dewebapplicatie onthoudt dat de gebruiker zich inmiddels succesvol heeftgeauthenticeerd. Zou dit niet zo zijn dan zou de gebruiker zich bij elk volgend

verzoek opnieuw moeten authenticeren en gaat de historie van zijn acties binnende webapplicatie verloren.

Om de sessie tussen een gebruiker en een webapplicatie te ‘fixeren’ staan desysteemontwikkelaar ruwweg de volgende mechanismen ter beschikking:

•  Sessie-fixatie op basis van argumenten in de URL; hierbij zorgt dewebapplicatie ervoor dat de client het sessie-ID als argument toevoegt aanelk verzoek richting de webapplicatie. Hierdoor ontstaat een URL alshttp://www.eenwebsite.nl/aanroep.asp?sessieid=123 .

•  Sessie-fixatie op basis van verborgen velden; invoervelden in HTMLkunnen zowel zichtbaar als onzichtbaar zijn. Webapplicaties maken vaakdankbaar gebruik van onzichtbare velden om informatie over de sessie inop te slaan. Elke keer wanneer de gebruiker informatie uit zichtbarevelden verstuurt naar de webapplicatie verstuurt deze daarmee in ditgeval ook de informatie uit de onzichtbare velden. Onzichtbaar is hierbijechter een relatief begrip. De velden zijn niet direct zichtbaar vanuit eenwebbrowser. Onzichtbare velden maakt men echter op eenvoudige wijzezichtbaar door de broncode van een pagina te bekijken of via een snifferde uitwisseling van gegevens te bestuderen. Kiest een ontwikkelaar ervoorom de velden van een formulieren via een GET-actie te versturen naar de

webapplicatie dan verschijnen de ‘verborgen’ velden automatisch alsargument in de URL (zie vorige punt). Kiest de ontwikkelaar ervoor om deinhoud van een formulier via een POST-actie te versturen naar dewebapplicatie dan geeft de webbrowser deze waarden door via de body

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 76/116

van het bericht.

•  Sessie-fixatie op basis van cookies; sessie-fixatie op basis van cookies isde meest populaire manier om sessie-fixatie te bereiken. Hierbij verstuurtde server een klein stukje informatie richting de webbrowser via een een ‘Set-Cookie’ HTTP-header. De webbrowser slaat deze informatievervolgens op in het geheugen of in een bestand op de harde schijf. Ophet moment dat de gebruiker naar een website surft waarvoor het eencookie bezit zal de webbrowser dit cookie automatisch aanbieden aan dewebapplicatie.

OPMERKING Het is van belang het verschil te kennen tussen cookies diede webbrowser alleen in het geheugen opslaat en cookies die de browserin de vorm van een klein bestand op de computer opslaat. Het eerste typecookie (ook wel verwarrend ‘server-side’ cookie genaamd) verdwijnt zodrade gebruiker zijn webbrowser afsluit. Het tweede type cookie (ook wel ‘client-side’ of persistent cookie genaamd) blijft op de computer aanwezigen zal zelfs na een herstart van de computer nog aanwezig zijn. Vanuit hetoogpunt 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 hetverborgen veld genaamd ‘userid’. Bij het initieel benaderen van dewebapplicatie is de inhoud van dit verborgen veld leeg. Nadat dekwaadwillende probeert in te loggen met een standaard gebruikersnaamen wachtwoord blijkt dit niet te lukken en het ‘userid’ veld blijft leeg. Dekwaadwillende probeert vervolgens om het inlogscherm te omzeilen eneen verzoek aan de webapplicatie te richten waarin hij het verborgen veld ‘userid’ de waarde ‘Blackhat’ geeft. Nadat hij dit gedaan heeft krijgt hij demelding ‘Welkom Blackhat’ en kan hij gebruik maken van de webapplicatiezonder 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 webapplicatieen ziet vervolgens dat in de URL continu de parameter ‘sessieid=9001’ terug te vinden is. De gebruiker vraagt zich af of hij deze parameter kanmisbruiken door een andere waarde op te geven voor de sessieid. Nadathij de waarde van de parameter verandert in ‘sessieid=9000’ blijkt hij nogsteeds geauthenticeerd te zijn en krijgt hij de gegevens te zien van eenvolledig ander persoon die op dat moment ook is ingelogd. Dewebapplicatie blijkt gebruik te maken van oplopende sessie ID’s die zeereenvoudig te voorspellen zijn.

Authenticatie- en sessiemanagement blijkt aldus een zeer lastig onderdeel vaneen webapplicatie. Niet alleen het fixeren van een sessie kan lastig blijken. Ookhet uiteindelijk ‘ontmantelen’ van een sessie kan problemen met zich

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 77/116

meebrengen. De volgende vraag doet zich in dit kader voor: hoe zorgen weervoor dat de webapplicatie een sessie uiteindelijk ook weer afsluit? Sessieskunnen immers niet oneindig lang open blijven staan. De aanwezigheid van eensessie zorgt aan de ene kant voor onnodig resourcegebruik op de server (deserver moet alle sessies op één of andere manier administreren en hiervoorgeheugen reserveren) en daarnaast voor een beveiligingslek. Hoe meer sessieseen webserver op enig moment open heeft staan, hoe groter de kans dat eenkwaadwillende erin slaagt één van deze sessies te kraken. En ook: hoe langer eensessie actief blijft, hoe langer eventueel onderschepte sessiegegevens bruikbaarblijven voor een kwaadwillende (denk bijvoorbeeld aan misbruik van een cookievia een internetcafé).

6.2 .2    Fou t i eve im p lem en ta t i e van t oegangsbeheer  

Vergelijkbare problemen als bij authenticatie en sessiemanagement (vorigeparagraaf) kunnen zich ook voordoen bij toegangsbeheer. Toegangsbeheer volgtop authenticatie en houdt in dat de webapplicatie controleert of een gebruikergerechtigd is om bepaalde acties uit te voeren. Denk hierbij aan het al dan nietmogen uitvoeren van een bepaalde transactie of het al dan niet mogen bekijkenvan 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 alleengeregistreerde gebruikers toegang hebben. Binnen de applicatie is vastgelegd datvoor alle verzoeken naar ‘/protected/*’ een speciale autorisatievlag benodigd is.De volgende voorbeelden illustreren implementatiefouten die ertoe kunnen leidendat de webapplicatie deze autorisaties niet goed afhandelt:

•  De applicatie voert geen normalisatie van het verzoek vanaf de gebruikeruit (zie 5.3.5). Een kwaadwillende kan dit misbruiken door geen verzoek tedoen naar ‘/protected/insidernews.aspx’ maar naar

 ‘/./protected/insidernews.aspx’. Logischer wijs zijn deze tweeverzoeken identiek. Toch past de webapplicatie bij het laatste verzoekgeen autorisaties toe aangezien het verzoek niet start met ‘/protected/’.De kwaadwillende kan op deze manier de autorisaties op de betreffendedirectory eenvoudig omzeilen.

•  De applicatie baseert de toegang tot de beveiligde directory op basis vaneen cookie. Een kwaadwillende bekijkt het verkeer dat zijn webbrowseruitwisselt met de webapplicatie en ziet dat de webapplicatie gebruik maaktvan het cookie ‘ProtectedAccess’ met als waarde ‘0’. De kwaadwillendeverandert dit in ‘ProtectedAccess=1’ waarna hij zonder problemen toegangkrijgt tot de beveiligde inhoud. Het blijkt dat de webapplicatie zijnbeslissing om toegang te verlenen baseert op de inhoud van hetbetreffende cookie.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 78/116

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

Bovenstaande voorbeelden dienen slechts ter illustratie. Het geeft aan dat er veleimplementatiefouten binnen een webapplicatie kunnen bestaan die ertoe kunnenleiden dat kwaadwillenden autorisaties omzeilen.

6.2 .3    Onve i l i ge au then t i ca t i em echan i sm en  

Niet alle authenticatiemechanismen die een webapplicatie kan gebruiken, zijneven veilig. Een belangrijk gevaar dat verbonden is aan het gebruik vanauthenticatiemechanismen is de mogelijkheid tot het achterhalen c.q.onderscheppen hiervan. Op het moment dat een kwaadwillende erin slaagt omauthenticatiegegevens te achterhalen, kan deze zich er vervolgens zelf mee gaanauthenticeren tegen de webapplicatie. Voor het onderscheppen vanauthenticatiegegevens staan de kwaadwillende een aantal mogelijkheden terbeschikking:

•  Phishing: hierbij achterhaalt een kwaadwillende authenticatiegegevens(en mogelijke andere informatie) door gebruikers te verleiden om naar eennamaak website te surfen en daar deze (authenticatie-)gegevens in telaten vullen.

•  Social engineering: social engineering bestaat eruitauthenticatiegegevens te achterhalen door gebruikers over te halen dezete onthullen. Social engineering speelt ook een belangrijke rol bij phishing.Social engineering is echter breder (het kan hier bijvoorbeeld ook gaan omhet opbellen van personen om op die manier authenticatie- of anderewaardevolle gegevens te achterhalen).

•  Sniffing: bij sniffing probeert een kwaadwillende door het opvangen vannetwerkverkeer authenticatiegegevens te verkrijgen. Door deze passievevorm van aanvallen zal een gebruiker normaal gesproken niet merken datzijn authenticatiegegevens zijn onderschept.

Ook authenticatiemechanismen die op het oog veilig lijken hoeven niet perdefinitie veilig te zijn. Neem bijvoorbeeld authenticatie op basis van het ‘basicauthentication’ mechanisme, een standaard – en veel gebruikt – mechanismebinnen HTTP om gebruikers te authenticeren. Een typische HTTP-header bijgebruik van ‘basic authentication’ ziet er als volgt uit:

 Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 79/116

Op het eerste oog lijkt het erop dat de authenticatiegegevens versleuteld zijnaangezien deze niet direct uit de inhoud van de HTTP-header af te leiden zijn. Hetblijkt echter dat ‘basic authentication’ gebruik maakt van ‘base64 encoding’.Strings die middels base64 geencodeerd zijn, kan men ook eenvoudig weerdecoderen. 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 ishet 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 trachtenkwaadwillenden sterke authenticatiemechanismen (zoals tokens e.d.) te omzeilen.Het verschil met een 'normale' phishingaanval is dat de server van dekwaadwillende de authenticatiegegevens van de gebruiker direct doorspeelt aande 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. Dezespecifieke phishingaanval was gericht op Citibank maar het ligt voor de hand datook andere organisaties slachtoffer kunnen worden van een dergelijke aanval. Zievoor meer informatie over deze aanval: http://blog.washingtonpost.com/

securityfix/2006/07/citibank_phish_spoofs_2factor_1.html

6.2 .4    Disc repan t i e t u ssen au then t i ca t i em echan i sm e en  

beve i l i g ingsbe le id  

Bij veel projecten besteedt men, als gevolg van bijvoorbeeld tijdsdruk,onvoldoende aandacht aan het projecteren van het beveiligingsbeleid van deorganisatie op de webapplicatie en de bijbehorende data. Gevolg: de authenticatieis veel te ‘zwaar’ voor de data die de applicatie gebruikt, of de authenticatie isveel te ‘zwak’. In geen van de gevallen is er sprake van een ideale situatie. In hettweede geval is zelfs sprake van een beveiligingsrisico omdat data onvoldoende

beschermd bereikbaar is via internet.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 80/116

Discrepantie tussen het authenticatiemechanisme en het beveiligingsbeleid kanook gedurende de levenscyclus van een applicatie ontstaan. Op het moment dateen nieuwe applicatie het levenslicht ziet, voert de organisatie bijvoorbeeld eenrisicoanalyse uit waaruit voortvloeit dat de applicatie voldoende beschermd is opbasis van gebruikersnaam/wachtwoord authenticatie. De applicatie groeitvervolgens een aantal jaren door waarbij de organisatie steeds meerfunctionaliteiten en data aan de webapplicatie toevoegt. Wat men nalaat isregelmatig opnieuw een risicoanalyse uit te voeren op de applicatie. Hierdoorblijkt op een gegeven moment het gebruikte authenticatiemechanisme niet meerte voldoen voor de gestaag doorgegroeide applicatie.

6.2 .5    Het w ie l opn ieuw u i t v i nden  

De implementatie van authenticatie- en toegangsmechanismen is niet altijd eventriviaal. Zeker wanneer het gaat om complexe authenticatiemechanismen (digitalecertificaten, tokens) en complexe toegangsmatrices (veel rollen, veel resources)kan implementatie ervan veel tijd en moeite in beslag nemen. Het gevaar is datelke webapplicatie opnieuw ‘het wiel uitvindt’. En elke keer dat een applicatie hetwiel opnieuw uitvindt, bestaat er de kans op (beveiligings-)fouten, moet menbeheermechanismen inregelen, moeten diepgaande testen worden uitgevoerd,etc…

De kans dat men een authenticatiemechanisme meerdere malen uitvindt, is zekerook aanwezig als verschillende webapplicaties op verschillende manieren ontslotenworden en gebruik maken van verschillende protocollen en technologieën. Stelbijvoorbeeld dat een organisatie start met een webapplicatie die gebruikersbenaderen via hun webbrowser (op basis van HTML). De webapplicatie isbeschermd middels een gebruikersnaam en een wachtwoord. Vervolgens besluitde organisatie om delen van de webapplicatie ook beschikbaar te stellen via eenwebservice (op basis van XML). Ook deze webservice wil men beschermen opbasis van een gebruikersnaam en een wachtwoord. In veel gevallen zal men voordeze webservice een nieuw authenticatieproces inrichten. Dit terwijl het grootstegedeelte van het bestaande authenticatiemechanisme in veel gevallen herbruikt

kan worden.

6.2 .6    I ncom pa t i be le au then t i ca t i em echan i sm en  

Wanneer men het wiel voor elke webapplicatie opnieuw uitvindt (6.2.5), bestaatde kans dat webapplicaties een groot aantal verschillendeauthenticatiemechanismen implementeren om deze te beschermen. Dezeincompatibiliteit kan tot verschillende problemen leiden. Enkele van de meestvoorkomende zijn:

•  Bij het ‘in elkaar schuiven’ van verschillende applicaties (bijvoorbeeldverschillende bestaande webapplicaties achter een nieuw te ontwikkelenportaal) ontstaan problemen omdat de verschillendeauthenticatiemechanismen ervoor zorgen dat gebruikers op elkeafzonderlijke applicatie opnieuw moeten inloggen. Het is, met andere

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 81/116

woorden, niet mogelijk om via één account toegang te verkrijgen tot deafzonderlijke webapplicaties (Single Sign-On).

ACHTERGROND Dit probleem doet zich bijvoorbeeld ook voorwanneer twee voorheen afzonderlijke organisaties intensiever met elkaarmoeten samenwerken of fuseren. Het is niet ondenkbaar dat beideorganisaties vergelijkbare systemen bezitten die naar elkaar toe moetengroeien en uiteindelijk in elkaar moeten opgaan. Gebruikers die voorheenklant waren van beide organisaties bezitten hierdoor twee identiteiten. Hetbereiken van SSO-functionaliteit is in dit soort gevallen vaak alleenmogelijk via complexe synchronisatiemechanismen tussen de twee

applicaties of via een “big-bang” aanpak (het lanceren van een volledignieuw systeem als vervanging voor de twee oudere systemen).

•  De beheermechanismen rondom het ene authenticatiemechanisme zijnniet toepasbaar op het andere authenticatiemechanisme. Gevolg hiervan isdat 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 eengebruiker. Wanneer persoon A account A1 in applicatie 1 krijgt en account

A2 in applicatie 2, zijn deze twee identiteiten veelal niet met elkaar tecombineren of moeten hiervoor onevenredig veel activiteiten wordenondernomen. Hierdoor kan men geen geheel omvattend profiel van dezepersoon opmaken en moeten applicaties overlappende gegevens iederapart bijhouden (denk hierbij bijvoorbeeld aan een adreswijziging die elkeapplicatie 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 hoofdte bieden.

6.3 .1   Bepaa l de p lek van ident i te i t - en toegangsbeheer  

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

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 82/116

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

Het overzicht van figuur 6-3 toont vijf verschillende applicaties (A-E) die allen eenandere invulling hebben gegeven aan identiteitbeheer en toegangsbeheer. Bij deeerste applicatie (applicatie A) is alles op dit gebied in de applicatie zelf ingebouwd. De applicatie kan geheel zelfstandig functioneren maar maakt geengebruik van bestaande mechanismen. Applicatie E daarentegen heeft totaal geeningebouwde logica voor identiteit- en toegangsbeheer. Deze applicatie vertrouwtvolledig op centraal belegde functionaliteiten op dit gebied. Voordeel van deaanpak 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. Ooktussenvormen zijn uiteraard mogelijk. Zo neemt applicatie D alle zaken op hetgebied van identiteitbeheer centraal af, maar geeft het een eigen invulling aantoegangsbeheer. M.a.w.: het vaststellen van de identiteit vertrouwt de applicatietoe aan een centraal mechanisme, maar het uitdelen van rechten aan dezeidentiteit is voorbehouden aan de applicatie.

6.3 .2    Overw eeg de i nvoe r i ng van I &AM too l i ng  

Op het moment dat men besloten heeft waar taken op het gebied van identiteit-

en toegangsbeheer worden belegd kan men vervolgens de keuze overwegentooling op op dit gebied te implementeren: I&AM (Identity & Access Management)tooling. Uiteraard is een keuze voor dergelijke tooling alleen relevant wanneermen de intentie heeft om in ieder geval bepaalde delen van identiteit- entoegangsbeheer buiten de applicatie te plaatsen (applicatie B-E uit het overzichtvan figuur 6-3).

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 83/116

6.3.2.1  Omschrijving

I&AM tooling kan bijvoorbeeld de authenticatie uitvoeren voor een verzamelingvan webapplicaties. Net als bij de application-level firewall kan deze toolingwerken op basis van een reverse proxy oplossing of via een plug-in op dewebserver. Figuur 6-4 beschrijft een voorbeeld van een mogelijke implementatievan 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 eencentrale server. Deze server ondersteunt meerdere authenticatiemechanismen en

heeft bovendien verschillende servers tot zijn beschikking voor het controlerenvan authenticatiegegevens en autorisaties. Voor de achterliggende webapplicaties(applicatie A, B en C) is het gehele authenticatie- en autorisatieproces geheeltransparant. De webapplicatie krijgt een identifier aangeleverd en eventueel eenaantal autorisaties en attributen die van toepassing zijn op de identifier. Demanier waarop dit plaatsvindt, is afhankelijk van de gekozen strategie voorbeveiligingsintegratie (hoofdstuk 8). Vanuit het oogpunt van de webapplicatie ishet zeer eenvoudig om het authenticatiemechanisme te wijzigen: of de centraleserver nu authenticeert op basis van een gebruikersnaam/wachtwoord combinatieof op basis van een digitaal certificaat maakt voor de webapplicatie niet uitaangezien deze alleen werkt op basis van een identifier en dus

 ‘authenticatoronafhankelijk’ is.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 84/116

6.3.2.2  Voordelen

Een belangrijk voordeel van het gebruik van I&AM tooling is dat de complexiteitvan het authenticeren en autoriseren van gebruikers uit de webapplicatie wordtgetrokken. Hierdoor vermindert de complexiteit van de webapplicatie en kunnenontwikkelaars zich in het geheel richten op het verwerken van functionaliteit in dewebapplicatie. Dit betekent dat de ontwikkeling van webapplicaties sneller zalkunnen verlopen en een bewezen oplossing de authenticatie en autorisatie vangebruikers afhandelt.

Door daarnaast de authenticatie los te trekken van de webapplicatie, is het

eenvoudiger om in de toekomst andere authenticatoren in te zetten voor hetbeveiligen van de webapplicatie. Start men bijvoorbeeld met een webapplicatiedie beveiliging vereist op basis van een gebruikersnaam/wachtwoord en blijkt ditlater niet meer voldoende te zijn (i.v.m. de classificering van de data die dewebapplicatie aanbiedt), dan is het redelijk eenvoudig om de gebruikteauthenticator te wijzigen. Hiertoe voert men wijzigingen door in de I&AM toolingen hoeft de achterliggende webapplicatie hier in principe niets van te merken.

Ook de integratie van verschillende afzonderlijke webapplicaties achter éénportaal 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 degebruiker vervolgens toegang geven tot een verscheidenheid aan webapplicaties.De I&AM tooling speelt de inloggegevens van de gebruiker hierbij door aan deachterliggende webapplicatie (Single Sign-On). Eventueel kan de I&AM toolingverschillende mechanismen gebruiken voor het doorspelen van deze gegevensaan verschillende achterliggende webapplicaties; hierdoor is de impact voor dezewebapplicaties 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 vanidentiteit- en toegangsbeheer voor webapplicaties bieden. Onderstaand vindt ueen – alfabetisch – overzicht van producten die (geheel of gedeeltelijk) invullinggeven 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    M aak een ge fun dee rde keuze voo r au then t i cat i em echan i sm e  

Er bestaan een groot aantal authenticatiemechanismen die een organisatie kaninzetten voor de bescherming van een webapplicatie. Het is van belang dat menop basis van een (korte) risicoanalyse bekijkt welk authenticatiemechanisme het

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 85/116

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

Iets dat je bent

-Biometrischekenmerken

Iets dat je hebt

-Token

-Smartcard

-Mobiele telefoon

Iets dat je weet

-Wachtwoord

-Passphrase

-PIN-code

Iets dat je bent

-Biometrischekenmerken

Iets dat je hebt

-Token

-Smartcard

-Mobiele telefoon

Iets dat je weet

-Wachtwoord

-Passphrase

-PIN-code

 Figuur 6-5: Overzicht van authenticatiemechanismen en voorbeelden14 

Authenticatie kan men baseren op verschillende ‘factoren’. Een factor beschrijft opwelke 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 degebruiker weet of heeft) het meest voor de hand. Gebruik van biometrischekenmerken voor authenticatie tot webapplicaties kan zeer complex en kostbaarzijn en is nog geen gemeengoed.

Om de kans op het omzeilen van het authenticatiemechanisme te voorkomen, ishet 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

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 86/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 n ie t a l leen aan in loggen 

Bij het authenticeren van gebruikers besteedt men over het algemeen veelaandacht aan het inloggen van gebruikers. Wat men echter vaak vergeet is datgebruikers op een gegeven moment ook weer de kans moeten krijgen om uit teloggen. Tijdens het uitloggen van een gebruiker wordt zijn/haar sessie onklaargemaakt en kan een kwaadwillende met eventuele onderschepte sessiegegevensgeen verbinding meer opzetten.

OPMERKING Uitloggen is ook een belangrijk aandachtspunt bij de implementatievan Single Sign-On (SSO) mechanismen. Op het moment dat een gebruikeraangeeft uit te willen loggen dient op dat moment een Single Sign-Out plaats tevinden waarbij het mechanisme de authenticatie richting alle betrokken systemenweer ongedaan maakt. 

Verder is het zaak aandacht te besteden aan de idle time per sessie. Hoe langmag een gebruiker verbonden (geauthenticeerd) blijven als er geen activiteitvanaf 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 maniervermindert men bijvoorbeeld het risico dat een kwaadwillende een webapplicatieongeautoriseerd vanuit een internetcafé kan benaderen doordat een vorigegebruiker vergeten is uit te loggen. Daarnaast minimaliseert deze aanpak hetgebruik van resources op de webserver.

6.3 .5    Zorg voo r un i f o rm e en f l ex i be le au then t i cat i em echan i sm en  

Zoals in paragraaf 6.2.5 al werd beschreven is het van belang dat applicatieszoveel 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 verschillendetechnologieën en protocollen. Om dit te bereiken is het belangrijk rekening tehouden met de volgende overwegingen:

•  Zorg ervoor dat gebruikersgegevens zoveel mogelijk in dezelfdedataverzamelingen terecht komen. Creëer geen aparte databases metgebruikers voor verschillende applicaties maar consolideer deze zoveelmogelijk in één database. Hierdoor vermindert de beheerlast, voorkomtmen dat authenticatiemechanismen gerepliceerd en gesynchroniseerddienen te worden en verhoogt men de mogelijkheid tot de invoering vanSingle Sign-On (SSO) en Single Sign-Out.

•  Zorg ervoor dat ontwikkelde authenticatiemechismen eenvoudigingebouwd kunnen worden in verschillende technologieën en protocollen.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 87/116

Hierbij is ook een rol weg gelegd voor eventueel ingezette I&AM tooling;deze tooling moet eenvoudig overweg kunnen gaan met zowel HTML- alsXML-applicaties zonder dat daarvoor grote inspanningen benodigd zijn.Denk hierbij bijvoorbeeld aan de implementatie van authenticatie op basisvan digitale (X.509-)certificaten: wanneer men dit gehele proces heeftingericht voor een webapplicatie op basis van HTML, moet het geheleauthenticatiemechanisme eenvoudig te porteren zijn naar een webserviceop basis van XML.

•  Wees erop voorbereid dat aankomende technologieën eenvoudig kunnenworden ingepast. Denk hierbij aan zaken als Federated Identity, SAML,

WS-Trust, etc…

ACHTERGROND De SAML-standaard is een relatief nieuwe standaarddie staat voor Secure Assertion Markup Language. De standaard definieerteen raamwerk voor het uitwisselen van beveiligingsinformatie tussenverschillende (online) organisaties. Via SAML kunnen deze organisaties opbasis van XML ‘assertions’ aanmaken, opvragen en uitwisselen. Hierdoorkan op een gegeven moment een vorm van inter-organisationele SingleSign-On ontstaan: een gebruiker authenticeert zich bij organisatie Awaarna organisatie A ‘assertions’ beschikbaar stelt aan andere organisatiesdie hierdoor niet opnieuw de gebruiker hoeven te authenticeren.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 88/116

7  VERTROUWELIJKHEID ENONWEERLEGBAARHEID

Vertrouwelijkheid en onweerlegbaarheid zijn twee zaken die nauw aan elkaarverbonden zijn. In het geval men gebruik maakt van asymmetrische versleuteling(verschillende sleutels voor versleuteling en ontsleuteling), dient het publieke deelvan 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 gaatdieper in op de begrippen vertrouwelijkheid en onweerlegbaarheid in het kadervan 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 namesterk afhankelijk van de inrichting van identiteitbeheer. Voor het kunnenversleutelen van gegevens en het vaststellen van onweerlegbaarheid is het

namelijk van belang dat er wederzijdse authenticatie heeft plaatsgevonden. Dithoofdstuk gaat eerst in op kwetsbaarheden en bedreigingen op dit gebied omvervolgens een aantal aanbevelingen te beschrijven.

7.2   Mogelijke kwetsbaarheden en bedreigingen

De belangrijkste kwetsbaarheden en bedreigingen op het gebied vanvertrouwelijkheid en onweerlegbaarheid zijn de twee tegenpolen van dezebegrippen: lekken van informatie en weerlegbaarheid. De komende tweeparagrafen beschrijven deze begrippen in meer detail.

7.2 .1   Lekken van i n fo rm a t i e  

Van lekken van informatie is in ieder geval sprake wanneer vertrouwelijkeinformatie onbedoeld terecht komt bij ongeautoriseerde personen. Het lekken vaninformatie kan men ook nauwer definiëren: het onnodig verstrekken vaninformatie. Dit hoeft dus niet per se vertrouwelijke informatie te zijn. De volgendevoorbeelden schetsen een aantal gevallen waarin de applicatie onnodig informatieverstrekt (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.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 89/116

Zaken zoals hierboven beschreven, zijn redelijk basaal en kwamen al eerder aande orde in de voorgaande hoofdstukken. Waar dit hoofdstuk zich op concentreertis het lekken van gevoelige informatie richting ongeautoriseerde personen. Dit kanbijvoorbeeld gebeuren op het moment dat:

•  Een kwaadwillende erin slaagt vertrouwelijke gegevens uit de databasevan de webapplicatie op te halen;

•  Een kwaadwillende erin slaagt bestanden met vertrouwelijke informatie(bijvoorbeeld Word-documenten en tekstbestanden) op de webserver tebenaderen;

•  Een kwaadwillende erin slaagt bestanden met vertrouwelijke informatie uitde backoffice te benaderen terwijl deze bestanden niet bedoeld zijn voorontsluiting via de webapplicatie.

7.2 .2    Weer legbaarhe id  

Er is sprake van weerlegbaarheid op het moment dat de applicatie geenmogelijkheden biedt om belangrijke zaken rondom een transactie te bewijzen. Devolgende 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 heeftplaatsgevonden.

•  De ontvangst van een transactie; een ontvangende partij kanontkennen 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 inhoudbevatte. Een klassiek voorbeeld hiervan is een bedrag dat zich in eentransactie bevindt. Het is belangrijk dat onweerlegbaar is welk bedrag zichin een transactie bevindt.

7.3   Aanbevelingen

De komende paragrafen beschrijven aanbevelingen die ervoor moeten zorgen datbij transacties via webapplicaties geen gegevens uitlekken en dat daarnaastzender en ontvanger niet kunnen twisten over het feit dat deze transactieshebben plaatsgevonden.

7.3 .1   Versl eu te l ve r t r ouw e l i j ke i n fo rm a t i e  

Door de inzet van SSL/TLS zorgt men ervoor dat informatie tijdens transportversleuteld is. Deze versleuteling stopt echter op het moment dat dewebapplicatie met de gegevens aan de slag gaat. Op het moment dat dewebapplicatie deze gegevens onversleuteld opslaat in een bestand of database

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 90/116

loopt de organisatie het risico dat deze informatie op één-of-andere manier inhanden van kwaadwillenden komt. Daarom is het aan te raden om vertrouwelijkeinformatie op te slaan in versleutelde vorm.

Er zijn een groot aantal standaard bibliotheken beschikbaar die een ontwikkelaarvan een webapplicatie kan gebruiken om versleuteling van gegevens te bereiken.Het is aan te raden dergelijke standaard bibliotheken te gebruiken boven eigenontwikkelde bibliotheken om versleuteling toe te passen. Deze standaardbibliotheken zijn veelal ver uitontwikkeld, zijn door de internetgemeenschapuitgebreid onderzocht en beproefd en bieden een maximale performance.

Bovenop (of in plaats van) transportversleuteling via SSL/TLS kan men er ookvoor kiezen om specifieke onderdelen van het bericht te versleutelen. Hiermeevoorkomt men dat een kwaadwillende via een man-in-the-middle aanval deSSL/TLS-sessie onderbreekt en daarmee toegang krijgt tot de inhoud van HTML-en XML-berichten. Voor het versleutelen van specifieke onderdelen uit een XML-bericht bestaan inmiddels al een aantal standaarden; voor HTML-berichten is datniet het geval. De XML-Encryption standaard is een voorbeeld van een standaarddie men kan toepassen om versleuteling van gegevens in een XML-bestand tebereiken. Via deze standaard is het mogelijk om een gedeelte van het XML-berichtte versleutelen en sleutelinformatie te versturen.

ACHTERGROND Meer informatie over het versleutelen van gegevens in XMLkunt u terugvinden in de ‘WS-Security Core Specification’ van de Organization forthe Advancement of Structured Information Standard (OASIS). Dit document kuntu 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 bijarchitecturen waarbij de webapplicatie niet direct communiceert met deeindgebruiker maar via een message broker. Een message broker ontvangtberichten 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 vertrouwelijkegegevens. Figuur 7-1 geeft deze situatie weer. In de situatie van figuur 7-1wisselen een client en een server informatie uit via een broker. De informatiebetreft een drietal velden: A, B en C. De communicatieverbindingen tussen client-broker en broker-server realiseert men op basis van SSL/TLS waardoortransportversleuteling ontstaat. Client en server hebben vastgesteld dat voor develden A en B versleuteling op basis van SSL/TLS voldoende is. De waarde vanveld C is echter zeer vertrouwelijk. Het is niet de bedoeling dat de broker inzichtkrijgt in de waarde van dit veld. Aangezien de broker de SSL-sessie met de clienttermineert is versleuteling van SSL/TLS voor het beschermen van de inhoud vanveld C in dit geval niet voldoende. Daarom versleutelt de client de inhoud van veldC nog eens extra door gebruik van XML-Encryption. De broker kan hierdoor wel deinhoud van de velden A en B bekijken maar niet van veld C omdat deze nietbeschikt over de benodigde sleutel (de privé-sleutel in dit geval).

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 91/116

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

Figuur 7-1: versleuteling van gegevens

7.3 .2    Vers leu te l cook ies  

Cookies bevatten doorgaans informatie over de sessie die een gebruiker heeft meteen bepaalde webapplicatie en mogelijk ook authenticatiegegevens. Door tijdenshet bezoek aan een webapplicatie continu het cookie aan de webapplicatie tetonen, weet de webapplicatie dat een gebruiker al geauthenticeerd is en dat ditniet opnieuw hoeft te gebeuren. Misbruik van informatie uit de cookies kan ertoeleiden dat kwaadwillenden zich ongeautoriseerd toegang verschaffen tot eenwebapplicatie. Dit kan gebeuren op het moment dat een kwaadwillende eencookie 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 menvoorkomen door het cookie te versleutelen of door extra controles uit te voerenop cookies (zie hoofdstuk 5). Het versleutelen van het cookie dient te gebeurenmet een sleutel die alleen bekend is bij de webapplicatie. De gebruiker kanhierdoor vrijwel niets met het cookie (hij beschikt immers niet over de geheimesleutel) 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 inhoudervan kunnen lezen en aanpassen. Hierdoor zijn vertrouwelijkheid en integriteit

van de inhoud van het cookie geborgd. Wat echter een restrisico blijft, is dat eenkwaadwillende zich op basis van het cookie toegang verschaft tot de webapplicatie(authentication replay). Om dit restrisico te vermijden kan de webapplicatie

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 92/116

werken met dynamische sleutels. Door bijvoorbeeld elke 2 minuten een nieuwesleutel te generen blijft het cookie op het werkstation ook maar 2 minuten geldig.Zolang de gebruiker ingelogd blijft op de webapplicatie ontvangt deze elke 2minuten een nieuw cookie; de inhoud (na ontsleutelen) van het cookie blijft hierbijwellicht onveranderd maar door de keuze voor een andere sleutel is deversleutelde inhoud (de uiteindelijke inhoud van het cookie die de eindgebruikerte zien krijgt en moet aanbieden) verschillend. Op het moment dat eenkwaadwillende een dergelijk cookie in handen krijgt is de geldigheid van de sleutelnaar alle waarschijnlijkheid al verlopen en kan deze niets meer met dit cookieaanvangen.

7.3 .3    M aak geb ru i k van d i g i t a l e hand teken ingen  

In sommige gevallen kan het benodigd zijn dat transacties – en de inhoudhiervan - onweerlegbaar zijn. In dit soort gevallen ontkomt men er vrijwel nietaan om te gaan werken met digitale handtekeningen. Bij een digitalehandtekening maakt de ondertekenaar gebruik van een ‘geheim’ dat alleen bijdeze gebruiker bekend is. Dit kan bijvoorbeeld een code of een privé-sleutel zijn.De eerste implementatie van een digitale handtekening maakte gebruik van PublicKey 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 Ben onweerlegbaarheid bereiken. Hiertoe voert gebruiker A de volgende stappenuit: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 ditbericht alleen door gebruiker B te lezen. Bij ontvangst van het bericht voertgebruiker 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 inorde is en dat de inhoud daadwerkelijk afkomstig is van gebruiker A.

Er bestaan verschillende mogelijkheden om een digitale handtekening teimplementeren. Voor een belangrijk gedeelte is de technische oplossing ookafhankelijk van het gebruikte ‘transportprotocol’: XML of HTML. Voor XML bestaaninmiddels standaarden waarmee men een digitale handtekening op de inhoud van

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 93/116

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

Figuur 7-2: voorbeeld digitale handtekening 

Bij op HTML-gebaseerde applicaties moet men over het algemeen meerinspanningen verrichten om gebruik te kunnen maken van digitalehandtekeningen. Er bestaan geen standaard mechanismen om dit te bereiken. Inveel gevallen zal een plug-in in de webbrowser benodigd zijn om functionaliteitenop het gebied van digitale handtekeningen te kunnen implementeren.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 94/116

8  BEVEILIGINGSINTEGRATIE

De beveiligingsintegratielaag is vooral bedoeld om functionaliteit te bieden. Het isdaarnaast ook een virtuele laag: er bestaan geen specifieke producten diebeveiligingsintegratie met beveiligingscomponenten (en beveiligingscomponentenonderling) mogelijk maken. Het is een ingebouwde functionaliteit vanbeveiligingscomponenten die webapplicaties (en andere beveiligingscomponenten)kunnen aanroepen c.q. raadplegen. Dit hoofdstuk gaat in op de manier waaropbeveiligingsintegratie tussen webapplicaties en beveiligingsapplicaties (en

beveiligingscomponenten onderling) tot stand kan komen.

8.1   Inleiding

Beveiligingsintegratie houdt in dat een webapplicatie de beschikking krijgt overinformatie die aanwezig is binnen de beveiligingscomponenten. Hierdoor kan eenbeveiligingsoplossing als generiek onderdeel binnen een webomgeving fungerenen hoeven ontwikkelaars de betreffende functionaliteit niet in elke applicatieafzonderlijk in te bouwen. Een voorbeeld hiervan is het scheiden vanfunctionaliteiten op het gebied van autorisatie- en toegangsbeheer tussen de

webapplicatie en generieke beveiligingscomponenten (zie hoofdstuk 6, figuur 6-2). Enkele voorbeelden van beveiligingsintegratie die een webapplicatie kanwensen zijn:

•  Een webapplicatie wil de gebruikersnaam achterhalen van een gebruikerdie door de I&AM tooling is geauthenticeerd;

•  Een webapplicatie wil de rollen c.q. autorisaties achterhalen van eengebruiker die door de I&AM tooling is geauthenticeerd (en mogelijkgeautoriseerd);

•  De I&AM tooling wil de certificaatgegevens achterhalen van een SSL-sessiedie de application-level firewall met de eindgebruiker heeft;

•  Een webapplicatie wil een load balancer opdracht geven geen verkeermeer richting een specifieke webserver te versturen (omdat erbijvoorbeeld onderhoud op deze webserver gaat plaatsvinden).

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

8.2   Mechanismen

In hoofdlijnen bestaan er twee mechanismen om beveiligingsintegratie tebereiken: passief en actief. Passieve beveiligingsintegratie betekent dat een

beveiligingscomponent bepaalde informatie bij voorbaat aanbiedt aan deachterliggende webapplicatie zonder dat de webapplicatie hier specifiek omvraagt. De webapplicatie hoeft deze informatie niet te gebruiken. Actieve

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 95/116

beveiligingsintegratie houdt in dat de webapplicatie actief contact legt met hetbeveiligingscomponent om informatie op te vragen of opdrachten te geven. Hetvervolg van deze paragraaf bespreekt passieve en actieve beveiligingsintegratie inmeer detail.

8.2 .1   Pass ieve beve i l i g ings in t egra t ie  

Passieve beveiligingsintegratie is op verschillende manieren te implementeren.Drie generieke stappen doorlopen gebruikers, beveiligingscomponent en applicatiealtijd 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 achterliggendecomponenten. De mogelijkheid bestaat dat achterliggende componentengeen 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 plaatsthet beveiligingscomponent beveiligingsgegevens (bijvoorbeeldauthenticatie- of autorisatiegegevens) in een database. Achterliggendeapplicaties die deze gegevens willen gebruiken, kunnen de gegevensvervolgens weer uit de database halen. In feite is deze manier vanbeveiligingsintegratie een combinatie van passieve (beveilgingscomponentplaatst de gegevens altijd in de database) en actieve integratie (de

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 96/116

achterliggende applicatie moet de gegevens zelf weer actief uit dedatabase halen).

2.  Doorgeven van waarden via een querystring; bij deze oplossing plakt hetbeveiligingscomponent belangrijke gegevens achter de gebruikte URL in devorm van een querystring. De achterliggende applicatie kan de gegevensuit de querystring vervolgens gebruiken in de eigen programmalogica.

3.  Doorgeven van waarden via HTTP-headers; de informatie die hetbeveiligingscomponent in voorgaand punt verwerkt in een querystring kandit beveiligingscomponent ook aanbieden via HTTP-headers. Deachterliggende applicatie kan besluiten om de gegevens uit deze headersop te halen en te verwerken in de eigen programmalogica.

VOORBEELD Passieve beveiligingsintegratie kan van groot nut zijn wanneer menbijvoorbeeld in zeer korte tijd Single Sign-On moet inregelen voor twee(voorheen) volledig losstaande applicaties. Applicatie A dwingt authenticatie af opbasis van een eigen inlogformulier en Applicatie B dwingt authenticatie af op basisvan basic authentication. Door I&AM tooling voor deze applicaties in te zetten enenkele specifieke wijzigingen in deze tooling door te voeren, bereikt men ditrelatief eenvoudig zonder hiervoor ook maar één wijziging door te voeren in detwee 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&AMtooling een POST-request waarin het de gebruikersnaam en het wachtwoordvan de gebruiker verwerkt. De I&AM tooling simuleert hiermee het inloggenvan 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 hetde 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 hetwachtwoord van de gebruiker in base64 encoding opneemt. Deze HTTP-headervoegt de I&AM tooling toe aan elk verzoek dat de gebruiker verstuurt naarApplicatie B. Applicatie B merkt hierdoor niet dat niet de gebruiker maar deI&AM tooling inlogt op de applicatie. Wederom biedt de I&AM tooling hierdoorde mogelijkheid om de bestaande applicatie te blijven gebruiken zonderhiervoor aanpassingen door te voeren.

5.  Gedurende de sessie die de gebruiker heeft met de I&AM tooling kan degebruiker zonder problemen ‘switchen’ tussen de verschillende applicatieszonder dat hij/zij zich daarvoor opnieuw moet authenticeren. Voor degebruiker kan het dus om één applicatie lijken te gaan terwijl hij/zij inwerkelijkheid wordt bediend door twee losstaande applicaties.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 97/116

8.2 .2    Act ieve beve i l i g ings in tegra t ie  

Bij actieve beveiligingsintegratie bevraagt een webapplicatie actief eenbeveiligingscomponent om informatie over uitgevoerde beveiligingsacties teachterhalen óf om een nieuwe beveiligingsactie uit te laten voeren. Bij actievebeveiligingsintegratie hoeft het beveiligingscomponent dus niet inline (d.w.z.tussen de client en achterliggende applicatie) geplaatst te zijn. Figuur 8-2 schetstdeze twee alternatieven.

Figuur 8-2: actieve beveiligingsintegratie

Bij inline plaatsing zal het beveiligingscomponent het verzoek van de gebruikervalideren en, indien akkoord bevonden, doorsturen naar de achterliggendewebapplicatie. Bij het doorsturen van verzoek zal het beveiligingscomponent geengegevens over de sessie met de gebruiker naar de applicatie meesturen (zoals bijpassieve beveiligingsintegratie). Bij het ontvangen van het verzoek zal deapplicatie zelf actief contact gaan leggen met het beveiligingscomponent om

informatie over uitgevoerde beveiligingsacties door het beveiligingscomponent teachterhalen.

Ook wanneer het beveiligingscomponent niet inline geplaatst is, kan deachterliggende webapplicatie actief contact leggen met het beveiligingscomponentom beveiligingsinformatie op te vragen. Zo kan de webapplicatie bijvoorbeeld aanhet beveiligingscomponent vragen om een bepaalde gebruikersnaam/wachtwoordcombinatie te valideren en het resultaat te retourneren.

Een voor de hand liggende methode voor het bereiken van actievebeveiligingsintegratie is de toepassing van webservices.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 98/116

VOORBEELD F5, leverancier van netwerk- en beveiligigingsapparatuur, biedtmogelijkheden tot het bevragen van deze apparatuur via een mechanismegenaamd iControl. iControl is een Application Programming Interface (API) opbasis van SOAP/XML (webservices) en CORBA. Vooralsnog kan de iControlfunctionaliteit voornamelijk worden aangeroepen om load balancing functionaliteitin 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 testellen:

•  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 alsinput voor een productieselectie. Door bij elk nieuw of te vervangenbeveiligingscomponent deze vereisten in ogenschouw te nemen, ontstaat eenomgeving van nauw verwante componenten die moeiteloos met elkaar kunnen

integreren.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 99/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 verschillendetechnologieën die zich binnen de RBW-lagen bevinden hieraan een invulling

geven. Heel belangrijk is dat men monitoring, auditing en alerting niet los op elkelaag beschouwt, maar dat (causale) verbanden kunnen worden gelegd tussen deafzonderlijke logging- en monitoringmechanismen. Dit soort denken is m.n. vanbelang door de steeds verder voortschrijdende ketenintegratie waarbijcomponenten aan elkaar gekoppeld worden en de sterkte van de keten bepaaldwordt door de zwakste schakel. Ketenintegratie vereist tevens dat verschillendecompetenties binnen een organisatie (bijvoorbeeld netwerkbeheer ensysteemontwikkeling) nauwer met elkaar gaan samenwerken.

Vindt er bijvoorbeeld een aanval plaats op een applicatie binnen het RBW, dandient men de logging events op de verschillende lagen van het RBW te kunnen

combineren om zodoende een duidelijk aanvalspatroon (met bijbehorendbewijsmateriaal) te kunnen verzamelen. Door op deze manier te werk te gaan,kan men bijvoorbeeld bepalen welke actie op een specifiek tijdstip werduitgevoerd (applicatiebeveiliging), wie deze actie uitvoerde (identiteitbeheer) envanaf welke plek deze actie afkomstig was (netwerkbeveiliging).

Voor monitoring geldt eenzelfde soort redenering; hoewel het hierbij belangrijk isdat men afzonderlijke componenten monitoort is het tevens belangrijk om deverschillende componenten in een ‘monitoringketen’ te plaatsen. Op het momentdat één component uit de keten niet meer goed blijkt te functioneren, heeft ditgevolgen 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 gebiedvan monitoring, auditing en logging kan onderscheiden.

9.2 .1   Ontb r eken van t oez i ch t  

Wanneer een kwaadwillende een webapplicatie - of de infrastructuur hieromheen -probeert aan te vallen kan dit kwalijke gevolgen hebben. Op het moment dat deorganisatie 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

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 100/116

mechanismen juist zijn geconfigureerd. Door verschillende oorzaken kan hetorganisaties 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 geenmedewerker beschikbaar om deze logging door te nemen.

•  De monitoringcomponenten verzamelen wel continu data maar degebeurtenissen vanaf deze componenten zijn op geen enkele manier aan

elkaar te koppelen doordat de tijdstippen op de componenten uit elkaarlopen. Zelfs een afwijking van enkele seconden kan er al voor zorgen datgebeurtenissen op verschillende componenten niet meer aan elkaarvallen te relateren.

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

9.2 .2    I m p a ct : o n b e k en d  

Wanneer een component een losstaande gebeurtenis rapporteert, helpt dit in het

bepalen van de technische impact: het component is bijvoorbeeld tijdelijk nietmeer beschikbaar of de performance is tijdelijk verlaagd. Maar wat betekent ditnu 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 deeindgebruiker? Om de impact van een gebeurtenis te kunnen bepalen, moet mende gebeurtenis in een groter geheel (de keten) bekijken. Dit is niet mogelijkwanneer men de omgeving beschouwt als een verzameling van losstaandecomponenten. De beschouwing van de omgeving als een keten van nauwsamenwerkende componenten is in dit geval de enige juiste. Inzicht in deverbanden die zich tussen de componenten bevinden is hierbij essentieel. Opbasis 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ö rd ina t i e en sam enw erk i ng  

De componenten die logging genereren vallen vaak onder verschillendecompetenties binnen een organisatie. Een netwerkbeheer team beheert denetwerkcomponenten, een applicatiebeheerteam de webapplicaties, eenautorisatiebeheerteam de autorisaties, etc… Het analyseren van complexegebeurtenissen binnen de omgeving vereist dat deze verschillende competentiesnauw met elkaar samenwerken. Als de verschillende teams binnen de organisatiesfunctioneren als ‘eilandjes’ zal deze samenwerking in veel gevallen niet tot standkomen. Door dit gebrek aan samenwerking – en het gebrek aan coördinatietussen deze verschillende partijen – zal een complexe gebeurtenis daarom nooitvolledig geanalyseerd kunnen worden.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 101/116

9.3   Aanbevelingen

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

9.3 .1   M aak geb ru i k van I n t ru s i on De tect i on Sys tem en ( I DS)

Intrusion Detection Systemen (IDS) kunnen helpen bij het detecteren vanaanvallen op webapplicaties. IDS’en monitoren continu het verkeer dat zich doorde 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 plaatstmen als losstaand component in het netwerk waarna deze vervolgensnetwerkverkeer opvangt door de interface in promiscious mode teplaatsen. Promiscious mode houdt in dat de interface niet alleen verkeeropvangt dat specifiek voor deze interface bedoeld is, maar dat de interfaceal het verkeer dat het voorbij ziet komen (dus ook het verkeer dat niet aande interface is gericht) verwerkt. De voordelen van een NIDS zijn dat éénNIDS een groot netwerk met verschillende componenten kan monitoren endat het NIDS geen negatieve effecten heeft op de werking van de

infrastructuur. Nadelen van een NIDS zijn dat bij grote drukte niet al hetnetwerkverkeer kan worden geanalyseerd waardoor mogelijk aanvallenniet gedetecteerd worden en dat versleuteld verkeer (zoals bijvoorbeeldHTTPS) niet kan worden bekeken. Daarnaast vereist een NIDS dat men deaansluiting hiervan op de infrastructuur zodanig inregelt dat al het verkeerbeschikbaar komt voor het NIDS. In het geval de organisatie gebruikmaakt van switches kan dit betekenen dat men de switch zodanig moetconfigureren dat de switch al het verkeer ook kopieert naar hetaansluitpunt van het NIDS (span port) of dat het IDS dit verkeer ontvangtvia speciale ‘vampire taps’ (onderbrekingen in de kabelverbinding).

• Host-based Intrusion Detection Systems (HIDS); een HIDS installeertmen op een server waarna het HIDS continu de activiteiten op deze servermonitoort. Het HIDS kijkt hierbij niet alleen naar het netwerkverkeer(zoals het NIDS) maar vooral ook naar logging en andere lokalewijzigingen. Voordelen van de inzet van een HIDS zijn dat het meeraanvallen zal detecteren als het NIDS en dat het bovendien in staat is omversleutelde informatie te bekijken. Nadelen zijn dat het HIDS negatieveeffecten kan hebben op de werking van het system en het netwerk(performance-impact) en dat het onderhouden van alle lokaalgeïnstalleerde HIDS-systemen veel beheerlast met zich mee kan brengen.

•  Application-based IDS; een application-based IDS wordt specifiekingezet voor het monitoren van misbruik van een specifieke applicatie. Ditis de minst gangbare vorm van een IDS.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 102/116

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

NIDS HIDS

•  Monitoort het gehele netwerk •  Monitoort alleen een specifiek systeem•  Kan alle aanvallen op een omgeving

vastleggen•  Kan alleen die aanvallen vastleggen die

door de filteringmechanismen zijndoorgelaten

•  Reageert direct op afwijkendnetwerkverkeer (real time); de

aanvaller kan zijn sporen moeilijkverbergen

•  Reageert veelal pas op het moment dateen bepaalde regel in een log

verschijnt; de aanvaller heeft hierdoorde mogelijkheid om zijn sporenonzichtbaar te maken

•  Kan niet bepalen of eengedetecteerde aanval succesvol is

•  Kan uit de logging opmaken of eengedetecteerde aanval ook succesvol is

•  Geen impact op de performance vande omgeving

•  Levert een mogelijke vertraging op inde werking van het systeem

•  Redelijk eenvoudig op te zetten •  Mogelijk complexe setup bij veel hosts•  Bekijkt de header van pakketten en

kan daarom bepaalde aanvallen (IPDoS en teardrop attacks) detecteren

•  Bekijkt de header van pakketten niet

•  Onafhankelijk van eenbesturingssysteem

•  Aparte implementaties voorverschillende besturingssystemen

•  Vereist de aanschaf van nieuwehardware

•  Wordt geïnstalleerd op bestaandehardware

Tabel 9-1: NIDS versus HIDS

In de inleiding van deze paragraaf stelden we al dat het detecteren van aanvallenveelal gebeurt op basis van bekende aanvalspatronen. Deze systemen noemt menook wel signature-based aangezien deze systemen op basis van bekende ‘handtekeningen’ van aanvallen detectie uitvoeren. Het nadeel van deze werkwijzeis dat het IDS alleen bekende aanvallen herkent en nieuwe aanvallen

onopgemerkt laat. Tegenover de signature-based IDS’en staan de anomaly-basedsystemen. Deze systemen werken niet op basis van handtekeningen, maar opbasis van afwijkingen (anomalieën). Deze systemen vereisen eerst eeninleerperiode waarin zij bekijken wat ‘normaal’ gedrag is. Vervolgens kan hetsysteem afwijkingen op dit normale gedrag herkennen en dit rapporteren als eenmogelijke aanval. Voordeel van deze werkwijze is dat een dergelijk IDS nieuwe –onbekende – aanvallen hoogst waarschijnlijk zal detecteren. Nadeel is dat hetsysteem veel false positives kan opleveren: een alarm zonder dat er iets aan dehand blijkt te zijn. Dit is met name het geval op het moment dat de organisatieeen nieuwe applicatie in de omgeving uitrolt of een nieuwe versie van eenbestaande applicatie introduceert.

Van alle soorten IDS’en is de network-based variant (NIDS) met signatures demeest gebruikte en meest bekende vorm. Bij het inrichten van een NIDS is hetzaak goed te bekijken welke meetpunten interessant zijn voor het NIDS. In figuur

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 103/116

9-1 is een voorbeeld opgenomen van mogelijk interessante meetpunten aan dehand 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), ééntussen de twee (dual-vendor) firewalls (2) en één tussen de DMZ en debackoffice. Op punt (1) kan het IDS alle aanvallen die gericht zijn op de omgevingdetecteren omdat hier nog geen filtering van netwerkverkeer heeftplaatsgevonden. De gegevens van dit meetpunt zijn dan ook vooral vanstatistische waarde en leiden niet per definitie tot een alarm. Op punt (2) heeft alenige filtering plaatsgevonden (van een firewall en mogelijk van een proxy).

Verkeer op dit punt zal zeer waarschijnlijk de servers aan de achterste firewallgaan bereiken. Op het moment dat het IDS hier een aanval detecteert dient diteen hogere prioriteit te krijgen als bij punt (1). Tenslotte monitoort het IDS oppunt (3) het verkeer tussen de DMZ en de backoffice. Dit is met name eeninteressant meetpunt aangezien de meest vertrouwelijke informatie zich perdefinitie zal bevinden in de backoffice en de toegang tot deze vertrouwelijkeinformatie nauwkeurig moet worden gemonitoord.

ACHTERGROND Door het aantal geregistreerde gebeurtenissen op punt 1 enpunt 2 met elkaar te vergelijken ontstaat ook inzicht in de effectiviteit van defilteringsmechanismen binnen de omgeving. Dit kan een organisatie helpen in hetopstellen van bijvoorbeeld een return-on-investment analyse voorbeveiligingscomponenten.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 104/116

Naast het verzamelen van al deze informatie is het ook van belang dat men deinrichting van het NIDS verder goed inregelt. Enkele aandachtspunten die hierbijvan belang zijn:

•  Zorg ervoor dat signature-based systemen regelmatig worden voorzienvan de nieuwste aanvalspatronen.

•  Zorg ervoor dat databases voldoende ruimte bieden om de grotehoeveelheid gegevens die een NIDS produceert, in onder te kunnenonderbrengen. Men dient ook na te denken over de duur die logging moetworden opgeslagen en de manier waarop de logging zal worden

gearchiveerd.

•  Zorg ervoor dat de alarmering van het NIDS goed getuned wordt. EenNIDS dat continu alarmen uitzendt, zullen beheerders niet meer serieusnemen.

•  Regel een goede beheerprocedure rondom het NIDS. Een medewerker vande organisatie zal de logging van het NIDS regelmatig (bijvoorbeeld elkeochtend) moeten bekijken. Het is belangrijk dat binnen de organisatie isbelegd wie dit doet. Daarnaast is het, ter verbetering van de leesbaarheidvan de logging, aan te raden filters op de logging te plaatsen.

•  Onderschat de hoeveelheid mankracht die benodigd is voor het monitorenen onderzoeken van anomalieën en false positives niet. Het kan een zeerintensieve klus blijken te zijn om de filters van het IDS optomaal in terichten.

9.3 .2    Breng l ogg ing op één pun t sam en  

In de praktijk blijkt een organisatie er vaak niet aan te kunnen ontkomen omverschillende loggingmechanismen naast elkaar te gebruiken. Zo ondersteunt hetene systeem alleen logging op basis van SYSLOG, maakt een ander systeem

alleen lokaal logbestanden aan en stelt weer een ander systeem loggingbeschikbaar via SNMP. Al deze verschillende loggingmechanismen zorgen ervoordat logging versnipperd raakt en men het overzicht over alle gebeurtenissenmogelijk snel kwijtraakt. Om beveilingsissues efficiënt te kunnen detecteren is hetvan belang deze logging op één centraal punt weer bijeen te brengen.

OPMERKING Hoewel een organisatie er in de praktijk niet aan ontkomt omverschillende loggingmechanismen in te zetten is het altijd aan te raden om dediversiteit 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 verschillendelagen van het RBW. Dit kan uiteindelijk resulteren in een situatie zoalsweergegeven in figuur 9-2.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 105/116

Figuur 9-2: inrichting centrale logging

In een centrale loggingdatabase komt de logginginformatie uit verschillendeonderdelen van het RBW samen. Denk hierbij aan de volgende typen informatie:

•  Logging op het niveau van netwerkbeveiliging: bijvoorbeeld logging vangeweigerde netwerkverbindingen (mogelijk poortscans) door een firewall,

gedetecteerde aanvallen door een intrusion detection systeem, statistiekenvan een honeypot, etc…•  Logging op het niveau van platformbeveiliging: logging van

ongeautoriseerde bestandstoegang, potentieel gevaarlijkeconfiguratiewijzigingen, toevoeging van nieuwe gebruikersaccounts, etc…

•  Logging op het niveau van applicatiebeveiliging: logging vanuitgefilterde HTTP-headers, geblokkeerde URL’s, geblokkeerd lekken vaninformatie, etc…

•  Logging op het niveau van identiteitbeheer: logging van foutieveinlogpogingen op de webapplicatie, accounts die ‘locked-out’ raken,sessiemisbruik, etc…

•  Logging op het niveau van autorisatiebeheer: logging van

autorisatiemisbruik, uitgedeelde autorisaties (met mogelijk uitgebreiderechten), etc…

•  Logging op het niveau van vertrouwelijkheid en onweerlegbaarheid:logging van onweerlegbare transacties, foutieve handtekeningen, etc…

OPMERKING Dit document schaart monitoringgegevens ook onder de noemerlogging. Het verzamelen van informatie via SNMP zullen sommige organisatiesbijvoorbeeld meer zien als monitoringgegevens dan logginggegevens. Beide typeninformatie geven echter informatie over de status c.q. gezondheid van eensysteem: monitoringgegevens over het beveiligingsniveau op een specifiektijdstip, logging over acties die het beveiligingsniveau kunnen aantasten.

De centraal opgeslagen informatie kan zeer interessant zijn voor kwaadwillendenaangezien ze 1) hier veel van kunnen leren v.w.b. de opbouw van de

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 106/116

infrastructuur en de gebruikte componenten hierin en 2) ze via deze centrale plekeventuele sporen van misbruik kunnen wissen. Daarom is het van belang veelaandacht te besteden aan de beveiliging van deze centrale database zodatonbevoegden hiertoe geen toegang hebben (vertrouwelijkheid) en hierin geenwijzigingen kunnen aanbrengen (integriteit).

OPMERKING SNMP kan slechts in beperkte mate beveiligd worden. Daarnaastkan het via SNMP mogelijk zijn om configuratiewijzigingen op een component doorte voeren. Dit laatste verhoogt de noodzaak tot het afschermen van SNMPaanzienlijk.

9.3 .3    Breng cor r e la t ies aan 

Nadat alle logginginformatie m.b.t. webapplicaties bijeen gebracht is (9.3.2),bestaat de volgende stap uit het aanbrengen van correlaties tussen deverschillende logging gebeurtenissen. De uitdaging hierbij is om allegebeurtenissen op de verschillende niveau’s aan elkaar en aan een specifiekewebapplicatie te correleren. Op deze manier kan men het pad dat eenkwaadwillende heeft doorlopen achterhalen en tevens inzicht krijgen in deaanvallen die gedurende een bepaalde periode op een webapplicatie zijnuitgevoerd. Figuur 9-3 geeft een voorbeeld van correlaties die er kunnen bestaantussen een applicatie en de aanwezige componenten (blauwe lijn) en de

correlaties (afhankelijkheden – rode lijnen) tussen componenten onderling.

Figuur 9-3: monitoringafhankelijkheden

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 107/116

Het leggen van correlaties blijkt in de praktijk geen eenvoudige klus en kan eenorganisatie alleen bereiken door alle competenties rondom webapplicaties bijeente brengen. Een goed ingerichte Configuration Management Database (CMDB) kanhet leggen van correlaties voor een belangrijk gedeelte vereenvoudigen.

9.3 .4    Richt NTP cor rec t in  

Om gebeurtenissen binnen verschillende componenten aan elkaar te kunnenrelateren is het van belang dat de timestamps van deze gebeurtenissen overeenkomen. Deze timestamps zijn afhankelijk van een juiste instelling van de tijd opde betreffende componenten. Correcte inzet van het Network Time Protocol (NTP)

kan ervoor zorgen dat de tijdstippen op alle servers en andere componentenovereen komen. Vrijwel alle besturingssystemen ondersteunen het gebruik vanNTP.

9.3 .5    Aud i t de u i t gedee lde au to r i sa t i es rege lm a t i g  

Autorisaties zijn aan veranderingen onderhevig. Medewerkers komen en gaan enhetzelfde geldt voor klanten. Hierdoor zullen de autorisaties op webapplicatiescontinu wijzigen. Niet alleen moet men nieuwe autorisaties uitdelen, ookbestaande autorisaties zal men wellicht moeten verwijderen of inperken. Daaromis het van belang dat ‘applicatieverantwoordelijken’ uitgedeelde autorisaties

regelmatig onder de loep nemen. Hiertoe moeten zij een overzicht toegestuurdkrijgen met de huidige stand van zaken rondom autorisaties voor de webapplicatiewaarvoor deze persoon autorisatieverantwoordelijk is. Deapplicatieverantwoordelijke zal vervolgens moeten bekijken of er autorisatiesbestaan die niet meer nodig zijn of gewijzigd dienen te worden. Belangrijk is weldat het overzicht te behappen is voor een applicatieverantwoordelijke. Wanneerhet autorisatieoverzicht bijvoorbeeld 100 pagina’s omvat, zal deapplicatieverantwoordelijke door de bomen het bos niet meer zien en geenserieuze aandacht meer (kunnen) besteden aan dit overzicht.

9.3 .6    Bepaa l wa t t e doen b i j he t u i t va l l en van l ogg ingm echan i sm en  Het gebruik van centrale loggingmechanismen brengt een belangrijk vraagstukmet zich mee: wat doen we op het moment dat dit centrale loggingmechanismeuitvalt? Op het moment dat een component zijn logging niet meer kwijt kan,bestaat de kans dat deze logging verloren gaat. Dit zou kunnen betekenen datcomponenten, aanvallen van kwaadwillenden niet meer registreren of dattransacties niet meer onweerlegbaar zijn. Het is daarom belangrijk om opvoorhand te bepalen welke actie een component moet nemen op het moment dathet centrale loggingmechanisme niet meer beschikbaar is. Er bestaan op ditgebied grofweg de volgende mogelijke acties:

• Het component normaal door laten functioneren terwijl deze de loggingniet kan opslaan. Dit betekent dat logging verloren gaat.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 108/116

•  Het component normaal door laten functioneren en de logging lokaal latenqueuen. Veel componenten beschikken over een lokaal mechanisme omlogging tijdelijk te queuen. Op het moment dat het centrale loggingmechanisme weer beschikbaar komt, sluist het component de verzameldelogging alsnog door. Dit voorkomt dat het component niet meerbeschikbaar is en voorkomt tevens dat logging verloren gaat. Dit is echterwel een tijdelijke oplossing. Op het moment dat de lokale queue vol looptmoet opnieuw besloten worden wat het component hierna doet (doorfunctioneren – zie bovenstaande optie – of stoppen met functioneren – zievolgende optie).

•  Het component acuut laten stoppen met functioneren. Dit betekent datgebruikers hoogst waarschijnlijk niet meer kunnen doorwerken. Hetvoorkomt wel dat het component mogelijk malafide acties niet meer kanregistreren.

Vanuit het oogpunt van beveiliging en beschikbaarheid heeft het de voorkeurcomponenten eerst lokaal gebeurtenissen te laten queuen om vervolgens hetcomponent te laten stoppen met functioneren zodra deze queue vol is. Bij deselectie van een nieuw beveiligingscomponent is het daarom zaak goed teevalueren of deze voldoet aan de vereisten op het gebied van logging en tijdelijkequeueing van logging.

9.3 .7    Ste l bew aar te rm i j nen van l ogg ing vas t  

Intensieve logging binnen een hostingomgeving kan leiden tot vele megabytes totgigabytes aan logging per dag. De organisatie zal moeten bepalen hoe lang dezelogging online en offline beschikbaar moet en mag zijn. Online beschikbaarheidvan logging kan essentieel blijken in het efficiënt verhelpen vanbeveiligingsincidenten. De duur van offline beschikbaarheid kan beperkt wordendoor wet- en regelgeving (zie bijvoorbeeld ook de tekst bij ‘Achtergrond’). Voordateen organisatie besluit om gebeurtenissen binnen een hostingomgeving te loggenis het daarom van belang dat men bepaalt hoe lang en hoe logging beschikbaar

moet blijven. Een beslissing op dit gebied bepaalt vervolgens welke mediabenodigd zijn en hoeveel capaciteit men voor de logging moet reserveren.

ACHTERGROND Bij het vaststellen van bewaartermijnen van logging moetmen ook rekening houden met privacywetgeving. Vrijwel elkbeveiligingscomponent zal in zijn logging het IP-adres opnemen van de machinevan waaraf deze verkeer heeft geregistreerd. Dit IP-adres moet volgens de wet inveel gevallen beschouwd worden als een persoonsgegeven en ook als zodanigworden behandeld (privacy wetgeving). Dit is een belangrijk gegeven om in hetachterhoofd te houden bij het vaststellen van de bewaartermijnen van (enomgang met) logging. Zie voor meer informatie het artikel “Een IP-adres is nietaltijd een persoonsgegeven” op http://www.cbpweb.nl/documenten/uit_z2000-0340.stm

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 109/116

9.3 .8    Voer ac t i e f con t ro l es u i t op l ogg ing  

Het is belangrijk dat een organisatie actief controles uitvoert op de verzameldelogging. Alleen op die manier kan een organisatie misbruik van de omgeving eninbraakpogingen detecteren. Controle van de logging moet hiertoe onderdeeluitmaken van procedures waardoor taken en verantwoordelijkheden op dit gebiedduidelijk belegd zijn. De verantwoordelijke moet in zijn taak ondersteund wordendoor een deugdelijke filtering op de logging. Alleen bij een deugdelijke filtering ishet mogelijk om aanvallen te detecteren uit de grote hoeveelheid logging dieverschillende componenten op een dag zullen genereren. Filtering van de loggingzal dynamisch zijn; door het filter continu aan te passen ontstaat een behapbaaren bruikbaar overzicht van gebeurtenissen die zich in de omgeving hebbenvoorgedaan.

9.3 .9    Coörd inee r en bevo rde r sam enw erk i ng  

Doordat bij het samenbrengen van logging verschillende disciplines bijeenkomenkan het handig zijn om in bepaalde gevallen deze disciplines met elkaar in contactte brengen. Dit kan bijvoorbeeld nodig zijn op het moment dat een IDS eenaanval detecteert en op verschillende beveiligingslagen bekeken moet worden watover deze aanval kan worden teruggevonden. Ook bij onduidelijkheden rondomgebeurtenissen is het handig dat verschillende disciplines elkaar snel weten tevinden om op die manier problemen te verhelpen. Hoe een organisatie een

dergelijke samenwerking kan bevorderen is zeer afhankelijk van deorganisatiestructuur. In kleinere organisaties vindt samenwerking wellicht alinformeel plaats, in grotere organisaties kan men bijvoorbeeld gebruik maken vanvirtuele teams.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 110/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. INSECUREMagazine maart 2006. Beschikbaar:http://www.insecuremagazine.com/INSECURE-Mag-5.pdf (online)

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 111/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 : Outlook Web Access (OWA) kwetsbaar voor script-injectie

  Advisory ID : GOVCERT.NL-2006-133

Versie : 1.0

Risico : medium

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

Schade : high

Mogelijkheid tot cross-site scripting

Omzeilen van restricties

  Auteur :

Uitgiftedatum : 20060613

Toepassing : Microsoft Exchange

Versie(s) : Exchange Server 2000 Post-SP3

Exchange Server 2003 SP1

Exchange Server 2003 SP2

Platform(s) : Microsoft Windows 2000Microsoft 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.

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 112/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

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 113/116

C AFKORTINGEN EN DEFINITIES

Afkorting Omschrijving

ACL Access Control ListAD Active DirectoryAPI Application Programming InterfaceBGP Border Gateway ProtocolCDP Cisco Discovery Protocol

CMDB Configuration Management DatabaseCMS Content Management SystemCSI Computer Security InstituteCWE Common Weakness EnumerationDBA Database Administrator(D)DoS (Distributed) Denial-of-ServiceDMZ Demilitarised ZoneDNS Domain Name ServicesEPFW End-Point FirewallFBI Federal Bureau of InvestigationFTP File Transfer Protocol

GPO Group Policy ObjectGSLB Global Server Load BalancingHIDS Host-based Intrusion Detection SystemHTML HyperText Markup LanguageHTTP(S) HyperText Transfer Protocol (Secure)I&AM Identity and Access ManagementIDS Intrusion Detection SystemIIS Internet Information ServicesIP Internet ProtocolISAPI Internet Server Application Program InterfaceISP Internet Service Provider

ISS Internet Security SystemsLAN Local Area NetworkLDAP Lightweight Directory Access ProtocolLSLB Local Server Load BalancingMTU Message Transfer UnitNAT Network Address TranslationNIDS Network-based Intrusion Detection SystemNTP Network Time ProtocolNVD National Vulnerability DatabaseOS Operating SystemOSPF Open Shortest Path FirstOWA Outlook Web Access

OWASP Open Web Application Security ProjectPFW Perimeter FirewallPKI Public Key Cryptography

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 114/116

Afkorting Omschrijving

PoC Proof-of-ConceptRBW Raamwerk Beveiliging WebapplicatiesRDP Remote Desktop ProtocolRFC Request For CommentRSS 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)SAML Security Assertion Markup LanguageSCP Secure CopySIRT Security Incident Response Team

SMTP Simple Mail Transfer ProtocolSNMP Simple Network Management ProtocolSPOF Single Point-of-FailureSQL Structured Query LanguageSSH Secure ShellSSL Secure Sockets LayerSSO Single Sign-On / Single Sign-OutSTP Spanning Tree ProtocolTCP Transport Control ProtocolTFTP Trivial File Transfer ProtocolTLS Transport Layer Security

TTL Time-To-LiveUDP User Datagram ProtocolURL Uniform Resource LocatoruRPF Unicast Reverse-Path-ForwardingVLAN Virtual LANWSDL Web Service Description LanguageWSUS Windows Server Update ServicesXML eXtensible Markup LanguageXSS Cross-Site Scripting

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 115/116

D HOOFDPUNTEN BEVEILIGING

Deze bijlage geeft een overzicht van de kwetsbaarheden, dreigingen enmaatregelen die in dit document aan bod komen.

D.1 Kwetsbaarheden en dreigingen

Netwerk•  (Distributed) Denial-of-Service §3.2.1•  Server hopping §3.2.2•  Kwetsbare DNS(configuratie) §3.2.3•  Kwetsbare firewall(configuratie) §3.2.4

Platform•  Kwetsbaarheden in het OS §4.2.1•  Onveilige ingerichte beheermechanismen §4.2.2•  Onjuiste autorisaties §4.2.3•  Onnodige services §4.2.4

Applicatie

•  Ongevalideerde input §5.2.1•  Cross-Site Scripting (XSS) §5.2.2•  SQL injection §5.2.3•  Buffer overflows §5.2.4•  Lekken van informatie §5.2.5•  Onveilige opslag van informatie §5.2.6•  Onveilige configuratie §5.2.7•  Kwetsbare aangekochte applicaties §5.2.8

Identiteit- en toegangsbeheer•  Foutieve implementatie van authenticatie en sessiemanagement §6.2.1•  Foutieve implementatie van toegangsbeheer §6.2.2•  Onveilige authenticatiemechanismen §6.2.3•  Discrepantie tussen authenticatiemechanisme en beveiligingsbeleid §6.2.4•  Het wiel opnieuw uitvinden §6.2.5•  Incompatibele authenticatiemechanismen §6.2.6

Vertrouwelijkheid en onweerlegbaarheid•  Lekken van informatie §7.2.1•  Weerlegbaarheid §7.2.2

Monitoring, auditing en alerting• 

Ontbreken van toezicht §9.2.1•  Impact: onbekend §9.2.2•  Gebrek aan coördinatie en samenwerking §9.2.3

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 116/116

D.2 Maatregelen

Netwerk•  Besteed veel aandacht aan het DMZ-ontwerp §3.3.1•  Pas compartimentering toe §3.3.2•  Leg routepaden vast §3.3.3•  Bepaal de toegang tot de webapplicaties vanuit de backoffice §3.3.4•  Scheid beheer- en productieverkeer §3.3.5•  Overweeg de invoering van een dual-vendor concept §3.3.6•  Behoud overzicht §3.3.7•  Breng fysieke scheiding aan §3.3.8•  Implementeer maatregelen tegen (D)DoS §3.3.9•  Harden de (externe) DNS-infrastructuur §3.3.10•  Harden ook de rest van de infrastructuur §3.3.11•  Besteed aandacht aan beschikbaarheidvraagstukken §3.3.12

Platform•  Richt een solide updatemechanisme in §4.3.1•  Verwijder onnodige services §4.3.2•  Richt access controls strikt in §4.3.3•  Harden de implementatie van essentiële protocollen §4.3.4•  Maak gebruik van jailing §4.3.5•  Hanteer strikte OS-authenticatie(mechanismen) §4.3.6•  Maak gebruik van veilige beheermechanismen §4.3.7•  Maak back-ups §4.3.8•  Maak gebruik van lokale firewalls §4.3.9•  Audit de wijzigingen op het systeem §4.3.10•  Maak gebruik van beveiligingstemplates §4.3.11

Applicatie•  Overweeg de invoering van een application-level firewall §5.3.1•  Voer inputvalidatie uit §5.3.2•  Maak (extern) gebruik van SSL-verbindingen §5.3.3•  Voorkom het lekken van informatie §5.3.4•  Normaliseer HTTP-verzoeken §5.3.5•  Sta alleen benodigde HTTP-methoden toe §5.3.6•  Sta beperkt bestandsextensies toe §5.3.7•  Controleer verzoeken tegen bekende aanvalspatronen §5.3.8•  Controleer de inhoud van HTTP-headers §5.3.9•  Controleer het gebruik van cookies §5.3.10•  Richt een solide updatemechanisme in §5.3.11•  Schakel ‘directory listings’ uit §5.3.12•  Hanteer safe coding technieken §5.3.13•  Voer een (geautomatiseerde) code review uit §5.3.14•  Pas alle maatregelen op alle applicaties toe §5.3.15

5/10/2018 31476268 Dutch Raamwerk Beveiliging Webapplicaties Govcert - slidepdf.com

http://slidepdf.com/reader/full/31476268-dutch-raamwerk-beveiliging-webapplicaties-govcert

 

Identiteit- en toegangsbeheer•  Bepaal de plek van identiteit- en toegangsbeheer §6.3.1•  Overweeg de invoering van I&AM tooling §6.3.2•  Maak een gefundeerde keuze voor authenticatiemechanismen §6.3.3•  Denk niet alleen aan inloggen §6.3.4•  Zorg voor uniforme en flexibele authenticatiemechanismen §6.3.5

Vertrouwelijkheid en onweerlegbaarheid•  Versleutel vertrouwelijke informatie §7.3.1•  Versleutel cookies §7.3.2•  Maak gebruik van digitale handtekeningen §7.3.3

Monitoring, auditing en alerting•  Maak gebruik van Intrusion Detection Systemen (IDS) §9.3.1•  Breng logging op één punt samen §9.3.2•  Breng correlaties aan §9.3.3•  Richt NTP correct in §9.3.4•  Audit de uitgedeelte autorisaties regelmatig §9.3.5•  Bepaal wat te doen bij het uitvallen van loggingmechanismen §9.3.6•  Stel bewaartermijnen van logging vast §9.3.7•  Voer actief controles uit op logging §9.3.8•  Coördineer en bevorder samenwerking §9.3.9