(Dutch) Raamwerk Beveiliging Webapplicaties, Govcert

WWW.GOVCERT.
NL
RAAMWERK
BEVEILIGING POSTADRES
WEBAPPLICATIES Postbus 84011

2508 AA Den Haag
BEZOEKADRES
Wilhelmina van Pruisenweg 104

2595 AN Den Haag
TELEFOON
070 888 75 55
FAX
070 888 75 50
E-MAIL
info@govcert.nl
Auteur(s) : GOVCERT.NL
1.3
Versie : 27.10.2006
Den Haag : Publieke uitgave: 30.07.2009
GOVCERT.NL
is het Computer Emergency Response
Team van en voor de Nederlandse overheid.
Zij ondersteunt overheidsorganisaties in het
Voorkomen en afhandelen van ICT-gerelateerde
veiligheidsincidenten, 24 uur per dag, 7 dagen
per week. Advies en preventie, waarschuwing,
incidentafhandeling en kennisdeling
zijn hierbij sleutelwoorden.
GBO.OVERHEID
is de Gemeenschappelijke Beheer Organisatie
waar GOVCERT.NL sinds 1 januari 2006 deel
van uit maakt. Zij is verantwoordelijk voor
beheer en verdere ontwikkeling van een aantal
overheidsbrede ICT-voorzieningen.
Gebruik:
Dit werk is gepubliceerd onder de voorwaarden beschreven in

de Creative Commons Naamsvermelding-Niet-commercieel-
Gelijk delen 3.0 Nederland licentie. Kijk voor meer informatie
op http://creativecommons.org/licenses/by-nc-sa/3.0/nl/
INHOUD
English Summary .........................................................................................................1
1 Inleiding..........................................................................................................2
1.1 Leeswijzer ....................................................................................................... 2
2 Raamwerk Beveiliging Webapplicaties ............................................................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 Netwerkbeveiliging .......................................................................................13
3.1 Inleiding........................................................................................................ 13
3.2 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 13
3.3 Aanbevelingen ............................................................................................... 17
4 Platformbeveiliging .......................................................................................30
4.1 Inleiding........................................................................................................ 30
4.3 Aanbevelingen ............................................................................................... 33
5 Applicatiebeveiliging .....................................................................................42
5.1 Inleiding........................................................................................................ 42
5.3 Aanbevelingen ............................................................................................... 52
6 Identiteit- en Toegangsbeheer ......................................................................73

6.1 Inleiding........................................................................................................ 73
6.3 Aanbevelingen ............................................................................................... 81
7 Vertrouwelijkheid en onweerlegbaarheid ......................................................88

7.1 Inleiding........................................................................................................ 88
7.3 Aanbevelingen ............................................................................................... 89
8 Beveiligingsintegratie....................................................................................94
8.1 Inleiding........................................................................................................ 94
8.2 Mechanismen ................................................................................................. 94
8.3 Aanbevelingen ............................................................................................... 98
9 Monitoring, auditing en alerting ....................................................................99
9.1 Inleiding........................................................................................................ 99
9.3 Aanbevelingen ..............................................................................................101
A Referenties .................................................................................................. 110
B Beveiligingsadvies GOVCERT.NL-2006-133.................................................. 111
C Afkortingen en definities ............................................................................. 113
D Hoofdpunten Beveiliging ............................................................................. 115

ENGLISH SUMMARY
This Framework for Web Application Security provides an overview of security

aspects at various layers of a web application environment; i.e. any application
that can be reached over HTTP. The framework describes vulnerabilities, threats
and recommendations in chapters about the following layers:
The network. This is one of the most important layers when securing web
applications and is the precondition for securing other layers. The components in
this layer should only allow essential protocols, such as HTTP and HTTPS, and
block all others. A DMZ, DNS and firewalls are all part of this layer.
The operating system. The OS is the link between the network and the web
application. Vulnerabilities in the operating system can have a direct impact on
the security of the web application. The framework discusses, among other things,
maintenance, hardening, access control and back-ups of the operating system.
The application platform. Fortunately, focus on the security of web applications

has increased in recent years. The framework discusses various common errors,
such as insuficient input validation, cross site scripting and SQL injection
vulnerabilities. It also discusses methods of protection, such as secure coding,
application level firewalls, HTTPS and VPNs.
Authentication and autorisation, including various types of access control (role

based, rule based, mandatory etc), the use of two factor authentication and
session management.
Confidentiality and Integrity of information, using encryption and digital

signatures.
Integration of the web application with various security components. This

chapter discusses ways in which a web application can retrieve information from
other components for security purposes, such as the usernames of authenticated
users. A well designed and coherent system of components will greatly increase
the overall security.
Monitoring, auditing and logging.
The framework does not treat these layers as separate components, but rather as
part of a chain of components that all need to be secured in order to provide for a
secure environment.
Raamwerk Beveiliging Webapplicaties ■ Versie 1.3 ■ 28 juli 2009 1/116

1 INLEIDING
Steeds meer organisaties bieden services aan klanten aan via internet. Men
gebruikt hiervoor bijvoorbeeld websites, extranetten en webservices. Met de
toename aan webapplicaties gaat ook een toename aan beveiligingsincidenten
gepaard. Zo blijkt uit onderzoek van de FBI en het Computer Security Institute
(CSI) uit 2005 (FBI/CSI, 2005) dat 95% van alle organisaties meer dan 10
beveiligingsincidenten per jaar met webapplicaties registreerden. Opvallend is dat
een jaar eerder maar 5% van de respondenten aangaf meer dan 10
beveiligingsincidenten met webapplicaties te hebben meegemaakt. Verschillende
oorzaken kunnen ten grondslag liggen aan deze dramatische toename van
beveiligingsincidenten; enkele mogelijke oorzaken zijn:
• Het aantal webapplicaties is sterk toegenomen waardoor de kans op

misbruik ook toeneemt;
• De monitoring van de beveiliging rondom webapplicaties is verbeterd
waardoor beveiligingsincidenten eerst niet werden opgemerkt maar nu
wel;
• Publieke exploits voor kwetsbaarheden verschijnen steeds sneller op
internet waardoor de kans op uitbuiting van deze kwetsbaarheden
toeneemt.
Ongeacht de exacte oorzaak van de toename aan incidenten is het bij het
inrichten van webapplicaties van belang dat het aspect beveiliging voldoende
aandacht krijgt. Aangezien een webapplicatie onderdeel uitmaakt van een keten
van ict-services is het belangrijk dat de aandacht niet alleen uitgaat naar sec de
webapplicatie. Ook alle omliggende componenten (databases, logging servers,
procies, etc…), waarvan de webapplicatie afhankelijk is, vervullen een belangrijke
rol in het functioneren van de webapplicatie. Deze componenten dient men
daarom te betrekken in het geheel aan beveiligingsmaatregelen. Dit document
beschrijft een raamwerk (het Raamwerk Beveiliging Webapplicaties, kortweg
RBW) dat aandacht besteedt aan alle lagen van beveiliging rondom webapplicaties
en omliggende componenten.
1.1 Leeswijzer
Hoofdstuk 2 van dit document introduceert het Raamwerk Beveiliging

Webapplicaties (RBW). Het raamwerk bestaat uit verschillende lagen die elk een
onderdeel van de beveiliging rondom webapplicaties behandelen. De
daaropvolgende hoofdstukken gaan dieper in op de verschillende onderdelen van
dit raamwerk. Elk hoofdstuk start met een beschrijving van het specifieke
onderdeel uit het raamwerk waarna de bedreigingen, kwetsbaarheden en
mogelijke maatregelen de revue passeren. Mocht u geïnteresseerd zijn in één
specifiek onderdeel van beveiliging van webapplicaties dan kunt u het beste eerst

hoofdstuk 2 doorlezen om vervolgens één van de deelonderwerpen in meer detail
te bestuderen. De onderwerpen zijn als volgt verdeeld over de hoofdstukken:
• Hoofdstuk 3: netwerkbeveiliging;
• Hoofdstuk 4: beveiliging van het platform/besturingssysteem;
• Hoofdstuk 5: beveiliging van de webapplicatie en het applicatieplatform
waarop de webapplicatie werkt;
• Hoofdstuk 6: afscherming van webapplicaties via authenticatie- en
autorisatiemechanismen;
• Hoofdstuk 7: implementatie van vertrouwelijkheid en onweerlegbaarheid
in webapplicaties. In dit hoofdstuk komen zaken als versleuteling en
digitale handtekeningen aan de orde;
• Hoofdstuk 8: integratie van de webapplicatie met de verschillende
beveiligingscomponenten. Dit hoofdstuk kijkt bijvoorbeeld naar de manier
waarop een webapplicatie informatie over geauthenticeerde gebruikers
kan opvragen bij een losstaand beveiligingscomponent.
• Hoofdstuk 9: inrichting van monitoring, auditing en alerting.
OPMERKING De rode draad die door dit document loopt, is dat beschouwing van
beveiliging vanuit een ketenperspectief (tegenover beveiliging van losse
componenten) van belang is. Door tijdens het inrichten van beveiliging van
webapplicaties alleen beveiliging per losstaand component in te richten, ontstaat
geen optimaal beveiligde omgeving. Daarom is het, voor een juiste perceptie op
beveiliging van webapplicaties, aan te raden om het gehele document door te
lezen.
Dit document maakt veelvuldig gebruik van afkortingen en specifieke termen. Een
overzicht van alle gebruikte afkortingen en termen kunt u terugvinden in bijlage
C. Een puntsgewijze opsomming van alle kwetsbaarheden, bedreigingen en
aanbevelingen uit dit document vindt u terug in bijlage D.
Tot slot gebruikt dit document ook voetnoten om bepaalde termen of begrippen te
verduidelijken. Deze voetnoten herkent u aan een cijfer in superscript
(bijvoorbeeld: 3)
NOOT Indien in dit document de naam van een product, dienst, fabrikant of
leverancier wordt genoemd betekent dit niet dat GOVCERT.NL deze op enige wijze
goedkeurt, afkeurt, aanraadt, afraadt of anderszins hiermee verbonden is.

2 RAAMWERK BEVEILIGING WEBAPPLICATIES
Dit hoofdstuk introduceert het RBW. Dit raamwerk beschrijft de verschillende

aandachtspunten die aan bod moeten komen bij het beveiligen van een
webapplicatie. Het hoofdstuk start met een beschrijving van het begrip
webapplicatie en mogelijke kwetsbaarheden en dreigingen m.b.t. webapplicaties,
om vervolgens het RBW in hoofdlijnen te beschrijven.
2.1 Webapplicaties
Wanneer dit document spreekt over een webapplicatie dan betekent dit in grote
lijnen: een applicatie die bereikbaar is via een webbrowser of via een andere
client die ondersteuning biedt voor het HyperText Transfer Protocol (HTTP). Een
dergelijke client noemt men een ‘HTTP user agent’. Kern van deze definitie is dat
een webapplicatie altijd bereikbaar is op basis van HTTP of de versleutelde vorm
hiervan: HTTPS (HTTP Secure). De functionaliteit die een webapplicatie kan
bieden is oneindig, de techniek is echter altijd gebaseerd op de HTTP
protocolstandaard zoals gedefinieerd in RFC 26161.
Enkele voorbeelden van applicaties die volgens deze definitie onder de noemer
webapplicatie vallen:
• Internetsites; internetsites zijn publieke websites die voor iedereen

toegankelijk zijn. Door met een browser naar een website te surfen
(bijvoorbeeld www.govcert.nl) kan men informatie over een organisatie
opvragen, formulieren downloaden, vragen aan de organisatie stellen,
etc….
• Extranetten; extranetten maken gebruik van dezelfde technieken als

internetsites met het verschil dat vaak enige vorm van authenticatie en
autorisatie plaatsvindt. Extranetten zijn in de regel bedoeld voor klanten
van een organisatie. Via een extranet kan een klant bijvoorbeeld
opdrachten geven, statussen bekijken, documenten inzien, etc… De
kennisbank van GOVCERT.NL (kennisbank.govcert.nl) is een voorbeeld van
een extranet.
• Intranetten; ook intranetten maken gebruik van dezelfde technieken als

internetsites. Intranetten zijn echter alleen bedoeld voor interne
medewerkers van een organisatie en bieden bijvoorbeeld de mogelijkheid
om interne berichten te verspreiden. Intranetten zijn veelal alleen vanuit
de infrastructuur van de eigen organisatie te bereiken.
1
Zie: http://rfc.net/rfc2616.html

• Webservices; de voorgaande typen webapplicaties maken allen gebruik
van HyperText Markup Language (HTML) om te communiceren met de
gebruiker. HTML maakt het mogelijk om webpagina’s op te maken en weer
te geven in een webbrowser. Webservices maken geen gebruik van HTML
maar van eXtensible Markup Language (XML). SOAP is één van de meest
gebruikte standaarden om invulling te geven aan een webservice. XML
bevat geen lay-out informatie zoals bij HTML, maar bevat informatie in een
gestructureerde, vooraf gedefinieerde, vorm. Webservices verbinden in de
regel applicaties met elkaar en baseren informatie-uitwisseling tussen deze
applicaties op het gebruik van XML-berichten. De RSS2-feed van De
Waarschuwingsdienst (http://www.waarschuwingsdienst.nl/rss.xml) is een
voorbeeld van een webservice.
Hoewel webapplicaties normaal gesproken gebruik maken van de standaard TCP-

poorten (80/tcp voor HTTP, 443/tcp voor HTTPS) kan een webapplicatie ook
gebruik maken van een andere poort (bijvoorbeeld 8080/tcp). In dat geval
spreken we nog steeds van een webapplicatie aangezien de applicatie te
benaderen is op basis van standaard HTTP-berichten.
ACHTERGROND Om de verschillende dreigingen, kwetsbaarheden en

voorgestelde maatregelen in dit document goed te kunnen begrijpen, is het van
belang enige basiseigenschappen van HTTP goed te begrijpen. Hieronder volgen
de belangrijkste eigenschappen van HTTP:
• HTTP werkt met vraag- (HTTP-request) en antwoordberichten (HTTP-

response);
• In de meeste gevallen is communicatie via HTTP synchroon van aard: de
client stuurt en vraag en ontvangt, in dezelfde sessie, onmiddellijk een
antwoord van de server. In sommige gevallen is de actie die de server
moet uitvoeren dusdanig complex dat deze niet binnen een bepaalde time-
out kan reageren. In dit soort gevallen bestaat de mogelijkheid om over te
schakelen op asynchrone communicatie. Hierbij ontvangt de client het
antwoord van de server via een aparte sessie. Een overeenkomstig
kenmerk in het vraag- en antwoordbericht is in deze gevallen benodigd om
vraag en antwoord aan elkaar te kunnen koppelen. Sommige webservices
maken gebruik van asynchrone communicatie;
• Elk HTTP-bericht bestaat uit een kop en een bericht (HTTP-payload). De
kop bevat o.a. de zogenaamde HTTP-headers. HTTP-headers bevatten
meta-informatie over het bericht zoals het type payload (bijvoorbeeld
tekst, HTML, XML, etc…), het gebruikte type webserver, de naam van de
te bevragen host, de inhoud van een cookie, etc…
• HTTP is stateless. Dit betekent dat elk vraag-antwoordkoppel los van
elkaar staat. De webserver beantwoordt elk vraagbericht daarom
onafhankelijk van het vorige bericht.
2
Really Simple Syndication (RSS 2.0); manier om informatie van de website in een vastgesteld formaat
beschikaar te stellen aan gebruikers en applicatie

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

maken van SSL (HTTPS). SSL kan tevens wederzijdse authenticatie
verzorgen: de server authenticeert zich (bewijst zijn identiteit) middels
een server certificaat, de gebruiker via een client certificaat. In veel
gevallen past men bij SSL-authenticatie alleen authenticatie van de server
toe.
2.2 Mogelijke kwetsbaarheden en bedreigingen
Een webapplicatie heeft te maken met een groot aantal mogelijke

kwetsbaarheden en bedreigingen. Deze kwetsbaarheden en bedreigingen
bevinden zich op verschillende niveau’s; hierbij kan men denken aan
kwetsbaarheden en bedreigingen op netwerkniveau (bv. Denial-of-Service), op
authenticatieniveau (bv. omzeilen van authenticatiemechanismen) of op
applicatieniveau (bv. Cross-Site Scripting). Deze kwetsbaarheden en bedreigingen
krijgen een plek in het RBW en komen aan de orde bij de beschrijving van de
afzonderlijke onderdelen uit het raamwerk (hoofdstuk 3 t/m 9).
Drie generieke kwetsbaarheden en bedreigingen noemen we hier alvast:
• Configuratiefouten; wanneer men niet nadenkt over de configuratie van

software en deze software out-of-the-box uitrolt, dan kan dit tot
beveiligingsproblemen leiden. In andere gevallen denkt men wel na over
de configuratie, maar doen zich fouten voor bij het daadwerkelijk

implementeren van de configuratie. Ook in het laatste geval kunnen
beveiligingsproblemen het resultaat zijn.
• Aanwezigheid van bekende kwetsbaarheden; dagelijks verschijnen op

internet beveiligingsadviezen van verschillende leveranciers waarin de
leverancier een kwetsbaarheid in één van zijn softwareproducten
beschrijft. Zodra de ontdekker of de leverancier details over een dergelijke
kwetsbaarheid bekend maakt, is het veelal een kwestie van tijd voordat
publieke code verschijnt waarmee kwaadwillenden deze kwetsbaarheid op
eenvoudige manier kunnen misbruiken. Het is dan zaak om tijdig de door
de leverancier aangeleverde updates te installeren om de kwetsbaarheid te
verhelpen.
• Aanwezigheid van nieuwe (0-day) kwetsbaarheden; wanneer niet de

leverancier maar een derde (bijvoorbeeld een hacker) een kwetsbaarheid
bekend maakt, en de leverancier niet in staat is gesteld om updates voor
zijn software uit te brengen, dan spreekt men van een 0-day
kwetsbaarheid. Aangezien organisaties een dergelijke kwetsbaarheid niet
kunnen verhelpen door updates te installeren, is men afhankelijk van
work-arounds en de effectiviteit en haalbaarheid van deze work-arounds.
Kwaadwillenden maken dankbaar misbruik van 0-day kwetsbaarheden om
aanvallen op webapplicaties uit te voeren.
Voor zowel bekende als 0-day kwetsbaarheden geldt dat kwaadwillenden vaak op
basis van specifieke eigenschappen kunnen zoeken naar kwetsbare
webapplicaties. Zoekmachines als Google kunnen de kwaadwillende hierbij van
nut zijn (‘Google Hacking’).
2.3 Het Raamwerk
In figuur 2-1 is het RBW weergegeven. Het raamwerk bevindt zich hierbij logisch
gezien tussen een client en een webapplicatie.

Figuur 2-1: Raamwerk Beveiliging Webapplicaties
Zoals uit het raamwerk van figuur 2-1 is op te maken bestaat de beveiliging van
webapplicaties uit verschillende (beveiligings)lagen. Bekeken vanaf de client
verschijnen achtereenvolgens de volgende lagen:
• Netwerkbeveiliging; beveiliging die zich met name richt op het

afschermen van informatiestromen op het transport-/netwerkniveau.
• Platformbeveiliging; richt zich op het beveiligen van de verschillende

platformen (besturingssystemen) waarvan webapplicaties – en
aanverwante componenten zoals databases – gebruik maken.
• Applicatiebeveiliging; richt zich op het beveiligen van de webapplicatie

en het applicatieplatform3. Applicatiebeveiliging hoeft geen geïntegreerd
onderdeel van de applicatie zelf te zijn, maar kan ook als losstaand
component functioneren binnen de infrastructuur van de webapplicatie.
Een application-level firewall is een typisch losstaand component dat geen
geïntegreerd onderdeel van de applicatie uitmaakt, maar wel
beveiligingservices biedt voor deze applicatie.
• Identiteitbeheer; identiteitbeheer richt zich o.a. op het authenticeren

van gebruikers van webapplicaties. Daarnaast is ook het beheren van deze
identiteiten een belangrijke functie.
3
Een webapplicatie is bijvoorbeeld een Websphere toepassing, een applicatieplatform bijvoorbeeld de
Websphere server

• Toegangsbeheer; binnen toegangsbeheer worden rechten toegekend op
basis van de identiteit van een gebruiker. Afhankelijk van de rechten van
de identiteit mag een gebruiker wel of geen gebruik maken van (delen
van) de webapplicatie.
• Vertrouwelijkheid en onweerlegbaarheid; vertrouwelijkheid en

onweerlegbaarheid richten zich op het versleutelen van vertrouwelijke
gegevens en op de onweerlegbaarheid van transacties die gebruikers via
de webapplicatie uitvoeren.
Daarnaast bevinden zich in het raamwerk ook nog een aantal verticale lagen.
Deze lagen bieden ondersteuning aan de horizontale lagen:
• Beveiligingsintegratie; deze laag richt zich op het integreren van de

webapplicatie(s) met de beveiligingsoplossingen uit de verschillende
beveiligingslagen. Via correct ingerichte beveiligingsintegratie kan een
webapplicatie bijvoorbeeld de services van een toepassing die zich richt op
het toegangsbeheer benaderen.
• Monitoring, auditing en alerting; deze laag richt zich op het monitoren

van de werking van de verschillende componenten uit de horizontale
lagen. Daarnaast houdt deze laag zich bezig met het vastleggen van
belangrijke acties die plaatsvinden binnen de omgeving van de
webapplicatie en het uitsturen van alarmmeldingen op het moment dat
zich afwijkende (mogelijk schadelijke) gebeurtenissen voordoen.
Als laatste is in figuur 2-1 het informatiebeveiligingsbeleid afgebeeld. Dit beleid is

leidend voor de invulling van de verschillende andere onderdelen van het
raamwerk. Dit informatiebeveiligingsbeleid komt in dit document verder niet aan
de orde omdat een organisatie bij het implementeren van de maatregelen uit het
RBW al over een dergelijk beleid dient te beschikken.
2.4 Doelen
Het RBW kent de volgende doelen:
• Dienen als referentiepunt voor het implementeren van

beveiligingsmaatregelen rondom webapplicaties;
• Bereiken van samenhang tussen gekozen beveiligingsoplossingen voor
webapplicaties;
• Bereiken van hergebruik van beveiligingsoplossingen zodat niet elke
webapplicatie een nieuwe beveiligingsoplossing introduceert;
• Bevorderen van snelheid en kwaliteit in de implementatie van
beveiliging voor webapplicaties (en daarmee het bevorderen van snelheid
en kwaliteit in de implementatie van webapplicaties).

Implementatie van het RBW moet ertoe leiden dat de mogelijkheid tot misbruik
van de webapplicatie tot een minimum beperkt wordt. Dit alles moet ervoor
zorgen dat kwaadwillenden er niet in slagen om hackpogingen op de webapplicatie
uit te voeren. Een dergelijke hackpoging kan leiden tot financiële, politieke en
juridische schade. Enkele voorbeelden van negatieve publiciteit (imagoschade)
waartoe misbruik van een webapplicatie kan leiden ziet u in figuur 2-2.
Figuur 2-2: schade door misbruik
2.5 Scope
De scope van het RBW is technisch van aard. Dit betekent dat een aantal
aspecten van informatiebeveiliging geen onderdeel uitmaken van het raamwerk.
Het raamwerk besteedt bijvoorbeeld geen aandacht aan zaken als
beveiligingsorganisatie, fysieke beveiliging en personeel.
Veel van de zaken die dit document behandelt, zijn niet alleen van toepassing op
webapplicaties maar ook op andere soorten applicaties. Het is daarom
onvermijdelijk dat het document naast specifieke beveiligingsoplossingen voor
webapplicaties ook algemene beveiligingsoplossingen beschrijft die het beveiligen
van webapplicaties vereist.

Het raamwerk houdt zich bezig met allerlei zaken die zich binnen een webhosting
omgeving kunnen afspelen. Het is goed mogelijk dat voor een webhosting
omgeving afwijkende regels en standaarden gelden dan voor een regulier
kantoornetwerk. Zo kunnen bijvoorbeeld afwijkende hardenings- en
beschikbaarheidseisen voor servers gelden. In sommige gevallen is de
webhostingomgeving zelfs extern ondergebracht en maakt de omgeving geen
onderdeel uit van het netwerk van de organisatie. Figuur 2-3 illustreert de
infrastructuur waarin een webhostingomgeving zich kan bevinden en de
afbakening van het RBW daarin (rode vlak).
Figuur 2-3: scope RBW (rode vlak)
Tot slot richt het RBW zich op de beveiliging van webapplicaties vanuit het
oogpunt van de aanbiedende partij (de serverzijde). Het raamwerk besteedt
daarom geen aandacht aan de manier waarop afnemende partijen (de
werkstations) veilig gebruik kunnen maken van webapplicaties.
2.6 Algemene aanbevelingen
Dit document beschrijft per deelgebied van het RBW een aantal aanbevelingen,
die een organisatie kan doorvoeren om de beveiliging van webapplicaties op een
voldoende niveau te kunnen brengen. Een aantal aanbevelingen is echter
algemener van aard en is van toepassing op alle lagen uit het RBW. Het gaat om
de volgende aanbevelingen:

• Test; voordat men een webapplicatie in productie plaatst, is het van
belang dat men eerst een uitgebreide test uitvoert op de webapplicatie en
de omliggende infrastructuur. Vanuit beveiligingsoptiek is het van belang
dat men bij het uitvoeren de test controleert of de webapplicatie en/of de
infrastructuur op enigerlei wijze is binnen te dringen of te misbruiken. Het
uitvoeren van testen is niet alleen belangrijk bij de initiële ingebruikname
van de webapplicatie, maar ook na het doorvoeren van belangrijke
wijzigingen in de webapplicatie of de infrastructuur.
• Bepaal een baseline en monitoor; aanvallen op de omgeving en

misbruik van webapplicaties herkent men in de regel aan afwijkende acties
die plaatsvinden binnen de infrastructuur. Zonder een vooraf gedefinieerde
baseline en juist ingerichte monitoring is het lastig om te bepalen of een
situatie op een bepaald moment afwijkt van de “normale” situatie. Ziet
men bijvoorbeeld een groot aantal clients verkeer richting de omgeving
initiëren, waarbij dit verkeer de volledige beschikbare bandbreedte
opslokt, dan is het de vraag of het hier gaat om een Distributed Denial-of-
Service (DDoS) aanval of dat het ‘gewoon’ druk is. Zonder informatie over
de bandbreedte die normaal in gebruik is, is dit onmogelijk te bepalen.
• Wees voorbereid; een organisatie kan een groot aantal maatregelen

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

3 NETWERKBEVEILIGING
Netwerkbeveiliging vormt de onderste laag van het RBW. Het netwerk maakt
communicatie met de webapplicatie via internet mogelijk. Het uitvallen van het
netwerk of een succesvolle aanval daarop kan daarom ook ernstige gevolgen
hebben voor de beschikbaarheid van de webapplicatie. Dit hoofdstuk gaat dieper
in op bedreigingen en aanbevelingen op het gebied van netwerkbeveiliging voor
webapplicaties.
3.1 Inleiding
Het afschermen van het netwerk is één van de belangrijkste aandachtsgebieden

bij het aanbieden van webapplicaties. Het juist afschermen van de verschillende
componenten op netwerkniveau is randvoorwaardelijk voor het kunnen invoeren
van andere beveiligingscomponenten. Gezien vanaf het internet laten de
componenten uit de laag netwerkbeveiliging alleen essentiële internetprotocollen
door (HTTP en HTTPS) en blokkeren deze alle overige protocollen4.
In het verleden richtten aanvallen op internetomgevingen zich m.n. op

tekortkomingen in netwerkbeveiliging. Door een sterke verbetering van
beveiligingstechnologieën op dit gebied, gecombineerd met een groeiend
bewustzijn bij organisaties, nemen aanvallen op netwerkniveau steeds verder af.
Aanvallen die echter gebruik maken van valide netwerkverkeer nemen
daarentegen steeds verder toe (aanvallen op applicatief niveau – zie hoofdstuk 5).
Desalniettemin is het van essentieel belang dat een organisatie zijn netwerk
afdoende beveiligt.
Deze paragraaf beschrijft mogelijke kwetsbaarheden en bedreigingen op

netwerkniveau die mogelijk van belang zijn voor webapplicaties.
Achtereenvolgens komen aan de orde: (Distributed) Denial-of-Service, server
hopping, kwetsbare DNS(configuraties) en kwetsbare firewall(configuraties).
4
Hierbij wordt uitgegaan van een dedicated infrastructuur voor webapplicaties waarin zich geen andere services
bevinden zoals mail (SMTP) en DNS.

3.2.1 (Distributed) Denial-of-Service5
Denial-of-Service-aanvallen (DoS) zijn aanvallen op een systeem of dienst met als
doel een systeem, dienst of netwerk zo te belasten dat deze uitgeschakeld wordt
of niet meer beschikbaar is. Meestal geschiedt dit door excessief gebruik te maken
van een op zich legitiem internetprotocol, bijvoorbeeld het opzetten van een TCP-
sessie.
Een Denial-of-Service-aanval kan worden geïnitieerd vanaf een enkel systeem,

maar ook vanaf meerdere systemen tegelijkertijd. Een Denial-of-Service aanval
vanaf meerdere systemen wordt een Distributed Denial-of-Service (DDoS) aanval
genoemd.
Over het algemeen gelden de volgende eigenschappen voor een Denial-of-Service

aanval:
• Poging om een netwerk te overspoelen met dataverkeer, waarmee

legitiem dataverkeer niet meer kan doorkomen;
• Poging om connecties tussen twee systemen te verbreken;
• Poging om een gebruiker geen toegang te geven tot een systeem;
• Poging om een service op een systeem te onderbreken.
Enkele voorbeelden van DoS-aanvallen zijn SYN-aanval, Smurf-aanval, Syslog-

aanval en E-mailbombing.
3.2.2 Server hopping

Het succesvol compromitteren van een server in de internetomgeving kan op zich
al tot ernstige schade leiden. Wanneer een kwaadwillende zich via de
gecompromitteerde server echter ook nog toegang kan verschaffen tot andere
servers en netwerkcomponenten die zich in de omgeving van de
gecompromitteerde machine bevinden (‘server hopping’), loopt de schade alleen
nog maar verder op. De kans op ‘server hopping’ is met name aanwezig in platte
omgevingen waarin alle servers in één logisch segment zijn geplaatst. In deze
omgevingen vervult een centrale firewall een essentiële rol en zal de
compromittering van deze firewall of een component achter de firewall tot
ernstige consequenties leiden. Figuur 3-1 bevat een voorbeeld van een
infrastructuur waarin ‘server hopping’ mogelijk is door de plaats van de firewall en
het gebrek aan compartimentering van de achterliggende infrastructuur.
5
Onderstaande tekst is ontleend aan het whitepaper “Aanbevelingen ter bescherming tegen Denial-of-Service
aanvallen” van GOVCERT.NL (DDoS-GOVCERT, 2005). U kunt dit document downloaden via de Kennisbank van
GOVCERT: kennisbank.govcert.nl (toegang tot deze Kennisbank is alleen mogelijk wanneer u beschikt over
toegangsrechten)

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

Domain Name Services (DNS) zijn zeer belangrijke services voor webapplicaties.
Zonder de beschikbaarheid van DNS kunnen gebruikers een website niet op basis
van bekende hostnamen (bijvoorbeeld www.overheid.nl) bereiken. Problemen met
DNS leiden daarom in veel gevallen tot een webapplicatie die nog wel
beschikbaar, maar niet meer ‘vindbaar’ is.
DNS maakt voor een groot gedeelte gebruik van het User Datagram Protocol
(UDP). Vanuit het oogpunt van beveiliging betekent dit dat DNS vatbaar is voor
zaken als hijacking en spoofing (een client die zich voordoet als een andere
client). UDP maakt namelijk geen gebruik van de 3-way handshake van TCP (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

• Toestaan van zone transfers; informatie over servers in een bepaald
domein slaat DNS op in een zogenaamde zone. Via zone transfers kunnen
clients alle DNS-informatie over een bepaalde zone opvragen. Deze zone
transfers zijn in principe bedoeld om primaire en secundaire DNS-servers
gesynchroniseerd te houden. Wanneer willekeurige clients zone transfers
kunnen uitvoeren richting de DNS-server, betekent dit dat iedereen alle
informatie uit een zone kan opvragen. Een kwaadwillende kan deze
informatie misbruiken om de omgeving waarin de webapplicatie zich
bevindt tot in detail in kaart te brengen.
• Denial-of-Service (DoS); ook DNS is, net als het netwerk, vatbaar voor
DoS-aanvallen. Wanneer de DNS-server een zeer groot aantal DNS-
verzoeken moet verwerken, kan dit ertoe leiden dat de DNS-server niet
meer in staat is om te reageren op verzoeken.
• DNS cache poisoining; DNS cache poisoining kan zich voordoen op

servers die naast de eigen authoritieve domeinen7 ook andere (niet-
authoritieve) domeinen ondersteunen (caching servers). De kwetsbaarheid
bestaat eruit dat een kwaadwillende in staat is om foutieve DNS-informatie
te injecteren in de cache van de DNS-server. Hierdoor kan het gebeuren
dat een gebruiker een foutief IP-adres geretourneerd krijgt bij het DNS-
verzoek voor een bepaalde hostnaam. Het gevolg hiervan is dat de
gebruiker verbinding maakt met een verkeerde webserver. Een
kwaadwillende kan cache poisoining misbruiken om bijvoorbeeld phishing-
aanvallen uit te voeren.
ACHTERGROND Meer informatie over misbruik van DNS en de manieren

waarop dit misbruik kan worden terug gedrongen kunt u ook vinden in het
GOVCERT.NL whitepaper “DNS-misbruik: van herkenning tot preventie”. Dit
whitepaper kunt u downloaden vanaf de Kennisbank van GOVCERT.NL
3.2.4 Kwetsbare firewall(configuratie)

Firewalls vormen een essentieel component in de beveiliging tegen aanvallen op
webapplicaties. Door de belangrijke rol die een firewall vervult, is het ook gelijk
een kwetsbaar element in de beveiligingsketen. De volgende zaken vormen een
risico bij het gebruik van firewalls:
• De organisatie redeneert: “we hebben een firewall, dus we zijn

veilig”. De redenering dat de inzet van een firewall de enige
beveiligingsmaatregel is die men vanuit beveiligingsoogpunt hoeft te
implementeren, is een verkeerde en kan leiden tot een misplaatst gevoel
van veiligheid. De firewall is inderdaad een belangrijk element maar kan
7
Een authoritieve DNS-server is een DNS-server die volledige controle heeft over de inhoud van een zonefile
behorende bij het domein. Authoritieve servers voor een specifiek domein zijn via whois op te vragen –
bijvoorbeeld door het commando ‘whois –h whois.sidn.nl govcert.nl’ uit te voeren op Linux-systemen (de
authoritieve DNS-servers voor dit domein verschijnen onder de kop ‘Domain nameservers’).

men niet los zien van andere beveiligingsmaatregelen.
• De firewall is geconfigureerd als router. Op een firewall kan men

zoveel verbindingen toestaan als men maar wil. Door een rulebase8 te
creëren die al het mogelijke verkeer toestaat, functioneert de firewall meer
als router dan als firewall. Ook hier geldt dat de firewall in dit geval een
misplaatst gevoel van veiligheid kan geven.
• Men ziet door de bomen het bos niet meer. Aangezien firewalls een
centrale rol innemen binnen een infrastructuur kan het op een gegeven
moment gebeuren dat er zoveel verkeer door de firewall heen gaat dat
beheerders het overzicht kwijt raken. Wijzigingen doorvoeren op een
dergelijke firewall is dan een vrijwel onmogelijke taak. In dit soort gevallen
kan een medewerker geneigd zijn meer verbindingen toe te staan dan
daadwerkelijk noodzakelijk is.
• Kwetsbaarheden in firewalls. Ook firewalls kunnen kwetsbaarheden

bevatten. Een kritieke kwetsbaarheid op een firewall kan, door de veelal
centrale plaatsing van de firewall, ernstige gevolgen hebben.
• Onduidelijke wensen. Projecten die tot doel hebben een bepaalde

webapplicatie te implementeren hebben niet altijd helder welke
verkeersstromen voor de specifieke webapplicatie door een firewall
benodigd zijn. Het kan daardoor gebeuren dat het project meer
verkeersstromen aanvraagt dan daadwerkelijk noodzakelijk is.
3.3 Aanbevelingen
Deze paragraaf besteedt aandacht aan de maatregelen die een organisatie kan
treffen om netwerkbeveiliging voor webapplicaties in te richten. Aangezien het
netwerk een generiek ‘onderstel’ is voor alle mogelijke toepassingen zijn veel
maatregelen niet specifiek gericht op de beveiliging van webapplicaties maar meer
op de algemene beveiliging van de infrastructuur rondom de webapplicatie.
3.3.1 Besteed veel aandacht aan het DMZ-ontwerp

Een Demilitarised Zone (DMZ) is een apart stuk netwerk dat specifiek bedoeld is
om webapplicaties – en andere vanaf het internet bereikbare applicaties – in
onder te brengen. De DMZ vormt de koppeling tussen het internet enerzijds en
het interne netwerk anderzijds. Een veilige inrichting van de DMZ is daarom van
groot belang om te voorkomen dat kwaadwillenden via internet toegang krijgen
tot het interne netwerk van de organisatie.
8
De rulebase van een firewall beschrijft de verbindingen die een firewall toestaat. De rulebase bevat een lijst
met bronnen en doelen (IP-adressen) en toegestane poorten.

Een aantal verschillende overwegingen moeten als input dienen voor het ontwerp
van de DMZ. Enkele belangrijke overwegingen die hierbij een rol kunnen spelen
zijn:
• Welke verkeersstromen zijn benodigd?

• Gaan we compartimentering toepassen (zie 3.3.2)?
• Welke typen applicaties willen we via de DMZ ontsluiten?
• Welke ondersteunende applicaties (bijvoorbeeld databases) hebben we
nodig voor het ontsluiten van deze applicaties?
• Hoe gaan we het verkeer richting deze applicaties door de DMZ routeren
(zie 3.3.3)?
• Waar en hoe koppelen we de DMZ aan internet?
• Waar en hoe koppelen we de DMZ aan de backoffice?
• Moeten de webapplicaties ook toegankelijk zijn vanuit onze backoffice (zie
3.3.4)?
• Hoe regelen we het beheer van de DMZ in (welke protocollen, welke
koppelingen, welke compartimenten, etc… - zie 3.3.5)?
• Gaan we een dual-vendor concept implementeren (zie 3.3.6)?
Figuur 3-2 beschrijft een voorbeeldinrichting van een DMZ. De DMZ heeft hierbij
een centrale ingang en een centrale uitgang. Daarnaast is te zien dat de DMZ
bestaat uit verschillende compartimenten die allen een andere gradatie (gekleurd
bolletje) hebben meegekregen. De komende paragrafen beschrijven deze
verschillende onderdelen in meer detail.
Figuur 3-2: inrichting DMZ

3.3.2 Pas compartimentering toe
Rondom de firewall(s) in de DMZ kan men segmenten of compartimenten creëren.
Uitgangspunt kan hierbij zijn dat applicaties en toepassingen van een gelijk
beveiligingsniveau in één gezamenlijk segment terecht komen. Zo komen
bijvoorbeeld web proxies in één segment, webservers voor internetsites in één
segment, webservers voor extranetten in één segment, databases in één
segment, etc… Door deze compartimentering toe te passen zorgt men ervoor dat
compromittering van een server of applicatie in een compartiment geen directe
gevolgen hoeft te hebben voor servers of applicaties in een ander compartiment.
Daarnaast kan men via deze compartimentering onderscheid maken in servers die
wel rechtstreeks vanaf internet bereikbaar zijn (bijvoorbeeld webservers) en
servers die dat niet zijn (bijvoorbeeld directory servers).
OPMERKING Voorkom te allen tijde dat webservers een rechtstreekse –

ongefilterde - verbinding hebben met de backoffice. Webservers die in de
backoffice geplaatst zijn, vormen een zeer ernstig beveiligingsrisico. Webservers
dienen daarom altijd via minimaal één firewall gescheiden te zijn van de
backoffice.
3.3.3 Leg routepaden vast

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

Veel van de webapplicaties die een organisatie ondersteunt, moeten ook
bereikbaar zijn vanaf het interne netwerk. Om deze koppeling tot stand te
brengen heeft men de beschikking over grofweg twee alternatieven:
• Routeer verkeer vanuit de backoffice via de internetkoppeling naar

internet en vervolgens weer terug naar de eigen DMZ. Bij dit alternatief
komt het erop neer dat men de webapplicaties vanuit de backoffice op
eenzelfde manier benadert als alle andere webapplicaties op internet. Een
argument dat tegen dit alternatief spreekt, is dat het onzinnig lijkt om

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

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

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

3.3.5 Scheid beheer- en productieverkeer
In het DMZ-ontwerp van figuur 3-2 is een onderscheid gemaakt tussen een
‘productie’-gedeelte (oranje lijnen) en een beheergedeelte (grijze lijnen/zwarte
bolletjes). Het productiegedeelte is in feite het gedeelte van de DMZ waarop
verkeer vanaf internet terecht komt. Het onderscheid is aangebracht om te
voorkomen dat beheer- en productieverkeer door elkaar heen gaan lopen. Beheer
werkt vaak via webinterfaces en door beheer toe te staan via het
productiegedeelte loopt men het risico dat ook de bijbehorende webinterfaces en
andere beheervoorzieningen te benaderen zijn vanaf het internet.
Scheiding van beheer en productie betekent dat servers minimaal twee

netwerkaansluitingen krijgen: één voor aansluiting op het productiegedeelte en
één voor aansluiting op het beheergedeelte.
OPMERKING Het is belangrijk dat de compartimentering die is aangebracht in

het productiegedeelte ook terugkomt in het beheergedeelte. Is dit niet het geval
dan kan een kwaadwillende via het beheergedeelte de compartimentering alsnog
omzeilen.
Het beheernetwerk kan tijdens kantooruren ondersteuning bieden voor het

uitvoeren van reguliere beheerwerkzaamheden (bijvoorbeeld SSH-verbindingen
opzetten met systemen). Aangezien beheerwerkzaamheden ’s nachts meestal niet
plaatsvinden, kan men buiten kantooruren over dit netwerkgedeelte back-ups
laten lopen zonder daarbij het productieverkeer in de weg te zitten.
Een laatste belangrijk aandachtspunt is te bepalen hoe beheerders toegang

krijgen tot het beheergedeelte. Hiertoe bestaan verschillende mogelijkheden:
• Implementeer beheerclients in het beheergedeelte die alleen te gebruiken

zijn door er via een afgeschermde ruimte achter plaats te nemen. Beheer
over de omgeving kan alleen plaatsvinden via deze fysiek afgeschermde
beheerclients.
• Implementeer beheerclients in het beheergedeelte die op basis van een
remote interface (bijvoorbeeld Citrix of Microsoft RDP) te benaderen zijn
voor een beperkte groep werkstations in het backoffice LAN. Beheerders
maken vanaf hun werkstation in het LAN een verbinding met de
beheerclients en kunnen vervolgens via deze beheerclients het beheer
over de omgeving uitvoeren.
• Implementeer een apart beheer-LAN in het backoffice LAN en sta
verbindingen richting het beheergedeelte alleen toe vanuit dit beheer-LAN.
Afhankelijk van de inrichting van de infrastructuur van de organisatie bestaan er

uiteraard ook nog andere mogelijkheden om het beheer in te regelen.

3.3.6 Overweeg de invoering van een dual-vendor concept
Door de centrale plaatsing van de firewall(s) kan een kwetsbaarheid op deze
firewall(s) grote gevolgen hebben (zie 3.2.4). Om de schade bij een dergelijke
kwetsbaarheid te beperken kan men overwegen een dual-vendor concept te
implementeren. Het dual-vendor concept houdt in dat twee firewalls de
netwerkbeveiliging in de DMZ uitvoeren en dat deze firewalls van verschillende
makelij zijn. In figuur 3-2 gebruikt het productiegedeelte van de DMZ twee
verschillende firewalls. Eén firewall is rechtstreeks aangesloten op internet, de
andere op de backoffice. Zouden deze firewalls van dezelfde makelij zijn dan zal
een potentiële kwetsbaarheid ook op beide systemen aanwezig zijn. Een
kwaadwillende kan hierdoor, na het compromitteren van de eerste firewall, op
eenzelfde manier mogelijk ook de tweede firewall compromitteren. Door
verschillende (merken) firewalls in te zetten voorkomt men dit.
OPMERKING Het toepassen van een dual-vendor concept hoeft niet automatisch
te betekenen dat men twee typen centrale firewalls in de omgeving plaatst. Dit
concept kan men bijvoorbeeld ook invullen door, naast de centraal geplaatste
firewalls, ook firewalls lokaal op de machines te installeren. Tools als ipfilter,
ipfw en iptables bieden hiertoe mogelijkheden. Zie hoofdstuk 4
(“Platformbeveiliging”) voor meer informatie over dit type firewalls.
3.3.7 Behoud overzicht

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

Figuur 3-4: voorbeeld verkeersoverzicht
Het verkeersoverzicht bevat ten eerste alle firewalls en servers die betrokken zijn
bij het aanbieden van de webapplicatie. Dit betekent dat naast de webserver ook
andere servers waarvan de webapplicatie gebruik maakt (zoals databaseservers),
onderdeel uitmaken van het verkeersoverzicht. Vervolgens tekent men de
verkeersstromen tussen de componenten in. Hierdoor ontstaat een overzicht van
de regels die op de firewalls benodigd zijn om de webapplicatie te kunnen laten
functioneren.
Daarnaast dient men wijzigingen op de firewall gecontroleerd door te voeren.

Inpassing van firewallwijzigingen in een bestaand proces van wijzigingsbeheer
(change management) is ideaal.
OPMERKING Nog meer voorzichtigheid is vereist bij het doorvoeren van

infrastructurele wijzigingen. Het aanbrengen van bijvoorbeeld nieuwe
verbindingen tussen netwerkcomponenten kan ervoor zorgen dat routepaden en
compartimenteringen plotseling (in negatieve zin) wijzigen.
3.3.8 Breng fysieke scheiding aan

Door veel aandacht te besteden aan de inrichting van de DMZ (zie 3.3.1) ontstaat
een logische scheiding van netwerksegmenten rondom de firewall(s). Deze
logische scheiding hoeft niet per definitie ook een fysieke scheiding van
netwerksegmenten te betekenen. Verschillende netwerkcomponenten, servers en
andere apparatuur kunnen immers wel zijn aangesloten op dezelfde switch of hub
waardoor een fysieke koppeling ontstaat. Door deze fysieke koppeling tussen
componenten is het in sommige gevallen mogelijk om de logische segmentering
van het netwerk via deze netwerkcomponenten te omzeilen.
Het risico dat kwaadwillenden in staat zijn om via fysieke (laag 2) koppelingen de
logische (laag 3) segmentering te omzeilen, is in de praktijk vrij klein. Een kleine

ingreep op de belangrijkste ingangspunten van de DMZ voorkomt dit echter. In
figuur 3-5 is (rechts) een voorbeeld opgenomen van een fysieke scheiding tussen
twee belangrijke segmenten. Daarnaast is in het figuur ook het verschil
weergegeven met een situatie waarin wel één fysiek segment bestaat (links).
Figuur 3-5: fysieke scheiding van segmenten
Een fysieke scheiding kan men ook realiseren door (reverse) proxies inline te
plaatsen. Dit betekent dat de proxies twee interfaces krijgen: één interface voor
de buitenkant en één interface voor de binnenkant. Al het verkeer van en naar de
webapplicatie is in dit geval verplicht om via de proxy te lopen. Het nadeel van
een dergelijke plaatsing van een proxy is dat alle applicaties via deze proxy
moeten verlopen waardoor men afhankelijk is van ondersteuning van de proxy
voor het specifieke type verkeer (bijvoorbeeld een HTTP-proxy voor webverkeer,
een SMTP-proxy voor e-mailverkeer, etc…). De mogelijkheid tot het inline
plaatsen van een proxy is dan ook zeer afhankelijk van de andere typen
applicaties die de organisatie via de DMZ ontsluit. Meer details over (web) proxies
kunt u terugvinden in het hoofdstuk over applicatiebeveiliging (hoofdstuk 5).
OPMERKING Ook bij het gebruik van inline proxies is het van belang dat de twee
interfaces gebruik maken van verschillende switches. Plaatst men de
componenten uit de compartimenten die de proxy van elkaar scheidt in dezelfde
switches, dan ontstaat alsnog hetzelfde probleem als uit figuur 3-5 (links).
3.3.9 Implementeer maatregelen tegen (D)DoS

Het whitepaper “Aanbevelingen ter bescherming tegen Denial-of-Service-
aanvallen” (DDoS-GOVCERT, 2005) beschrijft een aantal maatregelen die een
organisatie kan treffen om zichzelf tegen (D)DoS-aanvallen te beschermen. De
maatregelen die dit whitepaper voorstelt, zijn hieronder kort samengevat:
• Maak gebruik van anti-spoofingmechanismen:

o Unicast Reverse-Path Forwarding (uRPF); URPF controleert op een
interface of een IP-pakket afkomstig is van een source IP-adres dat
volgens de routeringstabel bereikbaar is via de betreffende interface.
o Bogon lists; via bogon lists kan men IP-adressen die nog niet door
IANA zijn uitgegeven blokkeren.
o Access Control Lists (ACL); reguleren dataverkeer op basis van
bijvoorbeeld IP-adres of poortnummer.
• Zet firewalls in.
• Harden systemen. Met name het ‘tunen’ van de TCP/IP-stack kan helpen in
het beveiligen tegen (D)DoS-aanvallen.
• Besteed aandacht aan de netwerkomgeving.
• Maak afspraken met (hosting) providers.
• Monitoor de infrastructuur zodat detectie van (D)DoS-aanvallen mogelijk
is.
3.3.10 Harden de (externe) DNS-infrastructuur

Door de vitale rol die DNS speelt in het bereikbaar houden van webapplicaties, is
het belangrijk dat het aspect beveiling bij de inrichting van DNS-services voorop
staat. Enkele aandachtspunten die van belang zijn bij het beveiligen van DNS:
• Beperk de (bron) IP-adressen die zone transfers mogen uitvoeren met de

DNS-server. Alleen primaire en secundaire DNS-servers zouden hiertoe
gerechtigd mogen zijn.
• Sta via de firewall alleen verkeer toe richting 53/udp. Vrijwel alle DNS-
verzoeken maken gebruik van UDP. Alleen bij zeer grote verzoeken en
zone transfers zal DNS overschakelen op het gebruik van TCP. Door 53/tcp
te blokkeren in de firewall, voorkomt men dat willekeurige IP-adressen in
staat zijn om zone transfers uit te voeren.
• Maak gebruik van meerdere authoritieve DNS-servers voor een zone.
• Verwijder onnodige records uit de zone. Onnodige records (bijvoorbeeld
HINFO- en TXT-records) zijn niet benodigd en leveren een kwaadwillende
alleen extra informatie.
MEER INFORMATIE Het National Institute of Standards and Technology (NIST)

heeft een zeer omvangrijk document geschreven over de manier waarop men
DNS kan beveiligen. Dit document kunt u vrij downloaden vanaf de website van
NIST: http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf
3.3.11 Harden ook de rest van de infrastructuur

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

• Sluit beheermogelijkheden zoveel mogelijk af. Biedt webinterfaces alleen
aan via beheersegmenten.
• Maak alleen gebruik van versleutelde beheermechanismen. Maak dus
bijvoorbeeld gebruik van Secure Shell (SSH) in plaats van Telnet en
Secure Copy (SCP) in plaats van File Transfer Protocol (FTP).
• Sta beheer alleen toe vanaf vooraf gedefinieerde IP-adressen.
• Maak gebruik van complexe wachtwoorden en/of sterke
authenticatiemechanismen voor het uitvoeren van beheer op de
componenten.
• Maak gebruik van logon banners. Een logon banner verschijnt op het
moment dat een gebruiker een beheersessie opstart met een
netwerkcomponent. Deze banner bevat een waarschuwing die de
toegangsvoorwaarden tot het systeem beschrijft. De banner kan daarnaast
waarschuwen voor juridische acties wanneer de gebruiker misbruik van
het systeem maakt.
• Harden het onderliggende besturingssysteem. Veel leveranciers leveren
netwerkcomponenten in de vorm appliances9 waarop weinig extra
hardeningsmaatregelen mogelijk zijn. In de gevallen dat een
netwerkcomponent echter niet gebaseerd is op een appliance, is het van
belang dat men het onderliggende systeem ‘hardent’. Meer hiervoor kunt u
vinden in hoofdstuk 4: platformbeveiliging.
• Besteed voldoende aandacht aan de beveiligingsconfiguratie van
veelgebruikte netwerkservices en -protocollen: Simple Network
Management Protocol (SNMP), Network Time Protocol (NTP), SYSLOG,
Trivial FTP (TFTP), finger en routeringsprotocollen zoals Border Gateway
Protocol (BGP) en Open Shortest Path First (OSPF).
• Schakel alle ongebruikte protocollen, services en netwerkpoorten uit.
Voorbeelden van protocollen die veelal standaard zijn aangeschakeld op
netwerkcomponenten maar in veel gevallen niet benodigd zijn, zijn Cisco
Discovery Protocol (CDP) en Spanning Tree Protocol (STP)
• Maak op switches gebruik van Virtual LAN’s (VLAN) en beperk de toegang
tot netwerkpoorten op basis van MAC-adres (port security).
MEER INFORMATIE Via internet zijn een groot aantal templates en

handleidingen te vinden die ingaan op het beveiligen van specifieke protocollen of
services. Hieronder vindt u een kleine greep uit een aantal interessante artikelen
op dit gebied:
• On the Vulnerabilities and Protection of OSPF Routing Protocol (NCSU):

http://www.cs.ucsb.edu/~rsg/Routing/references/wang98vulnerability.pdf
• Secure BGP Template (Cymru Team):
http://www.cymru.com/Documents/secure-bgp-template.html
• Securing Cisco Routers (SANS/GIAC):
http://www.giac.org/practical/GSEC/Nicholas_Vigil_GSEC.pdf
9
Een appliance is een deels voorgeconfigureerde machine met een specifieke functionaliteit (bijvoorbeeld
firewalling, routing, switching) en gelimiteerde toegang tot het besturingssysteem

• Secure IOS Configuration Template (Cymru Team):
http://www.cymru.com/Documents/secure-ios-template.html
• Secure Network Infrastructure and Switched Networks (SANS):
http://www.sans.org/reading_room/whitepapers/basics/451.php
3.3.12 Besteed aandacht aan beschikbaarheidvraagstukken

Door de belangrijke rol die het netwerk speelt als ‘onderstel’ van de
webapplicaties is het van belang dat het netwerk te maken krijgt met een
minimum aan storingen. Het ontwerp van het netwerk dient daarom zodanig te
zijn dat deze zo min mogelijk (liefst geen) Single Points-of-Failure (SPOF) bevat.
Load balancing en redundantie zijn twee technieken die een organisatie kan
inzetten om de beschikbaarheid van de infrastructuur te vergroten. De volgende
twee paragrafen beschrijven deze twee technieken in meer detail.
3.3.12.1 Maak gebruik van load balancing technieken

Load balancers kunnen verkeer richting een webapplicatie over verschillende
gelijkwaardige componenten verdelen. Voor webapplicaties bestaan twee
belangrijke load balancing technieken:
• Local Server Load Balancing (LSLB); een ‘LSLB load balancer’ verdeelt
verkeer lokaal (dat wil zeggen binnen hetzelfde datacenter) over
verschillende webservers. Uitval van een webserver zal in dit geval niet
per definitie leiden tot het niet meer beschikbaar zijn van de website.
• Global Server Load Balancing (GSLB); een ‘GSLB load balancer’ is een
stuk complexer dan een ‘LSLB load balancer’ en heeft als doel om load
balancing uit te voeren over geografisch gescheiden locaties. DNS-
functionaliteit is een mechanisme om GSLB voor webapplicaties te
bewerkstelligen. De ‘GSLB load balancer’ is hierbij autoritief voor de zone
waarin de webapplicatie zich bevindt en fungeert voor deze zone als DNS-
server. Door verzoeken voor de zone te beantwoorden met steeds
wisselende IP-adressen komen gebruikers uit op de verschillende
geografisch gescheiden locaties. Deze aanpak verschilt van de standaard
Round Robin (RR) functionaliteit in DNS omdat GSLB rekening houdt met
de load die een bepaalde locatie op dat moment ondervindt en de
beschikbaarheid van deze locatie. Valt een geografische locatie
bijvoorbeeld uit dan zal de ‘GSLB load balancer’ de bijbehorende IP-
adressen niet meer uitdelen. Bij gebruik van RR-DNS zal de DNS-server
het IP-adres van de uitgevallen server gewoon blijven retourneren omdat
de DNS-server geen middelen heeft om te achterhalen of de betreffende
webserver nog bereikbaar is.

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 informatie
over een locatie krijgen via lokale ‘LSLB load balancers’. Op basis van deze
statusinformatie en polling-gegevens besluit de GSLB load balancer om
een bepaald IP-adres te koppelen aan een DNS-verzoek van een client.
Door de afhankelijkheid van GSLB-oplossingen van DNS kan dit in de

praktijk tot problemen leiden. Zo gebruiken GSLB-oplossingen een zeer
kleine Time-to-Live (TTL) voor DNS-records. De lengte van de TTL bepaalt
hoe lang componenten (werkstations, DNS caching servers, etc…)
opgevraagde DNS-informatie mogen bewaren. Internet Service Providers
(ISP’s) kunnen ervoor kiezen om deze TTL te negeren en een standaard
TTL van 24 uur aan te houden. In dit soort gevallen werkt de oplossing
niet goed voor klanten die zijn aangesloten via deze provider omdat deze
providers DNS-records minimaal 24 uur cachen. Hierdoor duurt het
mogelijk 24 uur voordat een uitgevallen locatie niet meer wordt
geadverteerd richting clients. Bij de keuze voor een GSLB-oplossing is het
raadzaam voldoende aandacht te besteden aan deze factoren.
3.3.12.2 Voer centrale componenten redundant uit

Centrale componenten in de infrastructuur kan men redundant uitvoeren zodat zij
geen Single Point-of-Failure (SPOF) vormen. Veel netwerkcomponenten bieden
standaard ondersteuning voor redundantie en bijbehorende statussynchronisatie.

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

4 PLATFORMBEVEILIGING
Dit hoofdstuk beschrijft de beveiliging van de platformen waarvan de

webapplicatie afhankelijk is. Het platform waarop een webapplicatie draait, is in
de regel een besturingssysteem als Windows Server of Linux-/Unix-varianten. Dit
hoofdstuk besteedt aandacht aan de kwetsbaarheden en bedreigingen die er
bestaan op het gebied van platformen en zal tevens aanbevelingen doen ter
voorkoming van deze kwetsbaarheden en bedreigingen.
4.1 Inleiding
Het platform (besturingssysteem) bevindt zich tussen het netwerk en de

webapplicatie. In sommige gevallen zijn de services die het platform aanbiedt
rechtstreeks via internet te benaderen. Eventuele kwetsbaarheden die zich
bevinden in het platform kunnen daarom direct de beveiliging van de
webapplicatie in gevaar brengen.
Deze paragraaf beschrijft kwetsbaarheden en bedreigingen die op het gebied van

het platform bestaan.
4.2.1 Kwetsbaarheden in het OS

Leveranciers van besturingssystemen brengen met grote regelmaat patches uit
voor nieuwe kwetsbaarheden. Niet alle kwetsbaarheden hebben direct gevolgen
voor servers die in gebruik zijn door webapplicaties. Dit komt met name omdat
webservers in de regel slechts bereikbaar zijn op een beperkt aantal poorten (zie
hoofdstuk 3). Wanneer er echter een kwetsbaarheid in het besturingssysteem
aanwezig is welke kwaadwillenden via de webserver kunnen misbruiken, dan kan
dit ernstige gevolgen hebben voor alle webapplicaties die van deze server gebruik
maken.
Een buffer overflow is een specifieke kwetsbaarheid. Buffer overflows in het

platform kunnen ertoe leiden dat kwaadwillenden willekeurige code uitvoeren op
de webserver wanneer de betreffende kwetsbare service bereikbaar is vanaf het
internet. In sommige gevallen biedt een buffer overflow alleen mogelijkheden om
de kwetsbare service te laten crashen. Het probleem bij een buffer overflow is dat
een kwetsbare applicatie data wil opslaan buiten de geheugenbuffer die voor deze
applicatie is gereserveerd. Het gevolg hiervan is dat de applicatie geheugen in
aanliggende geheugengebieden overschrijft. Hierdoor overschrijft het programma
mogelijke andere buffers en data van andere programma’s.

ACHTERGROND Een buffer overflow op het platform kan met name tot grote
problemen leiden wanneer deze zich bevindt in een centraal onderdeel van het
platform dat bovendien moeilijk af te schermen is voor kwaadwillenden. Hierbij
kan men denken aan een kwetsbaarheid in de implementatie van TCP/IP.
Uit een onderzoek van beveiligingsbedrijf Internet Security Systems (ISS) blijkt
dat de tijd die men heeft om bekende beveiligingslekken te patchen steeds verder
afneemt. ISS evalueerde in totaal 4472 lekken die in 2005 bekend werden
gemaakt. Bij 3,13% van deze lekken (140) bleek binnen 24 uur na het
verschijnen van het lek al exploitcode10 op internet beschikbaar te zijn. Na 48 uur
was al voor 9,38% van de lekken (420) exploitcode beschikbaar. Zeker voor
lekken die op veel servers aanwezig zijn, en kunnen leiden tot het uitvoeren van
willekeurige code, zullen kwaadwillenden veel moeite doen tot uitbuiting.
4.2.2 Onveilig ingerichte beheermechanismen

Het beheer van server in de hosting omgeving kan op verschillende manieren
plaatsvinden. Enkele van de meest gebruikte beheermechanismen zijn:
• Consoleverbindingen; een consoleverbinding kan men normaal

gesproken alleen benaderen wanneer men een fysieke verbinding met de
server of het component kan opzetten. Hiervoor dient men dan ook fysieke
toegang te hebben tot de ruimte waarin de server zich bevindt. Ten
behoeve van beheer kan men consoleverbindingen ook via het netwerk
beschikbaar stellen. In dit geval sluit men de consoleverbindingen aan op
een netwerk-enabled component. Door een Telnet-verbinding op te zetten
met een dergelijk component kan men een consoleverbinding via het
netwerk benaderen.
• Telnet; via telnet kan men een command-line sessie openen met een
machine. Telnet is een redelijk gedateerd mechanisme dat vanwege
beveiligingsredenen steeds minder vaak wordt toegepast.
• Secure Shell (SSH); via een SSH-verbinding kan men een veilige
(versleutelde) verbinding opzetten tussen een client en een server.
Optioneel kan men gebruik maken van certificaten om wederzijdse
authenticatie te laten plaatsvinden. Via SSH kan men een command-line
sessie openen met een server. Het is echter ook mogelijk om andere
functionaliteiten (zoals het kopiëren van bestanden via Secure Copy) via
een SSH-verbinding te tunnelen.
• File Transfer Protocol (FTP); via FTP kan men bestanden uitwisselen
tussen een client en een server. FTP maakt gebruik van authenticatie op
basis van een gebruikersnaam en wachtwoord. Deze gegevens verstuurt
de FTP-client in cleartext (in onversleutelde vorm) over het netwerk. Dit
laatste is één van de belangrijkste redenen dat het gebruik van FTP
10
Programmacode waarmee men een bekende kwetsbaarheid kan misbruiken

onveilig is.
• Webinterface; veel systemen bieden tegenwoordig een webinterface via

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

(zie hoofdstuk 3) kan het gebruik van bepaalde beheermechanismen een
beveiligingsrisico met zich meebrengen. Het gaat hier met name om
beheermechanismen die geen gebruik maken van versleutelingen en die
gebruikersnamen en wachtwoorden in cleartext over het netwerk versturen.
Wanneer men dergelijke beheermechanismen toestaat over het internet, bestaat
de kans dat kwaadwillenden deze authenticatiegegevens onderscheppen. Figuur
4-1 geeft een voorbeeld van de informatie (gebruikersnaam ‘anonymous’ en
wachtwoord ‘a@b.nl’) die een kwaadwillende kan achterhalen door het
onderscheppen van FTP-verkeer.
Figuur 4-1: onderscheppen FTP-authenticatiegegevens via een sniff
4.2.3 Onjuiste autorisaties

Het is van belang om de rechten die men toekent aan processen,
bestandssysteem, register, etc… zoveel mogelijk in te perken. Op het moment dat
dit niet gebeurt, kunnen onveilige situaties ontstaan.
Besturingssystemen bieden op verschillende manieren mogelijkheden om rechten

te koppelen aan processen. Dit doet men door een proces onder een bepaald
‘serviceaccount’ te laten draaien. Daarnaast biedt een besturingssysteem altijd de
mogelijkheid om rechten te koppelen aan bestanden, directories, etc… Richt men

de rechten op een webserver niet op een juiste manier in dan kunnen een groot
aantal problemen ontstaan; enkele voorbeelden hiervan:
• Er bevindt zich in een buffer overflow in een bepaalde HTTP-listener; door

deze buffer overflow te misbruiken kunnen kwaadwillenden willekeurige code
uitvoeren op de webserver. Wanneer de webserver draait onder de rechten
van een ‘gelimiteerde’ gebruiker dan zijn de mogelijkheden die de
kwaadwillende heeft nog enigszins beperkt. Draait de webserver echter onder
een gebruiker die veel meer rechten heeft (bijvoorbeeld ‘root’, ‘SYSTEM’,
etc..), dan zijn de gevolgen van misbruik van deze buffer overflow veel
verstrekkender.
• De directory op een webserver blijkt niet voldoende te zijn afgeschermd.

Hierdoor heeft (het account gekoppeld aan) de HTTP-listener schrijfrechten tot
de webroot van de webserver. Een kwaadwillende weet dit te misbruiken en
plaatst zijn eigen pagina op de webserver. De website raakt hierdoor
‘gedefaced’.
• Voor de verbinding tussen de webapplicatie en een database maakt de

webapplicatie gebruik van een Database Administrator (DBA) account. Dit is
zo ontstaan tijdens de ontwikkeling van de webapplicatie. Er blijkt zich echter
een SQL injection kwetsbaarheid in de webapplicatie te bevinden. Deze SQL
injection kwetsbaarheid, gecombineerd met de maximale rechten op de
database, zorgt ervoor dat kwaadwillenden elke mogelijke actie op de
database kunnen uitvoeren (tot aan het verwijderen van de database toe).
Bovenstaande voorbeelden illustreren slechts een aantal mogelijke problemen die

kunnen optreden bij onvoldoende aandacht voor het adequaat toekennen van
rechten. Het foutief inrichten van rechten kan in de praktijk tot een grote
verscheidenheid aan beveiligingsproblemen leiden.
4.2.4 Onnodige services

Sommige van de services die standaard bij een installatie van een platform actief
zijn, hoeft men niet per se nodig te hebben. Elke service op een platform kan
kwetsbaarheden bevatten en vormt daarmee een potentieel lek. Zeker wanneer
een service wel is geïnstalleerd op een systeem maar men geen aandacht heeft
geschonken aan de beveiliging ervan (omdat men bijvoorbeeld niet verwachtte
dat deze service werd geïnstalleerd), ontstaat een belangrijke bron van
beveiligingsproblemen.
4.3 Aanbevelingen
Alle aanbevelingen uit deze paragraaf kan men scharen onder de noemer
‘hardening van het OS’. Hardening houdt in dat men het besturingssysteem
zodanig inricht dat dit systeem beter bestand is tegen aanvallen van
kwaadwillenden. De technische stappen die benodigd zijn om een

besturingssysteem te hardenen verschillen per type besturingssysteem. De
logische stappen verschillen echter veel minder. De aanbevelingen uit deze
paragraaf zijn dan ook vooral generiek van aard. Per aanbeveling is ook een
voorbeeld opgenomen van hoe deze stap er op een specifiek type
besturingssysteem uit zou kunnen zien.
4.3.1 Richt een solide updatemechanisme in

Een solide updatemechanisme is essentieel om voldoende beschermd te zijn tegen
bekende beveiligingsproblemen in software. Naast een technische implementatie
van een dergelijk mechanisme is het ook van belang om een goede procedure in
te richten waarin staat beschreven hoe de organisatie om dient te gaan met
updates: hoe snel implementeert de organisatie een kritieke patch, welke stadia
moet de patch doorlopen, wie draagt ervoor de verantwoordelijkheid, etc...?
VOORBEELD Microsoft biedt in zijn besturingssystemen standaard ondersteuning

voor een aantal verschillende updatemechanismen. Zo kunnen clients rechtstreeks
updates bij Microsoft ophalen via update.microsoft.com en via “Automatic
Software Updates”. In bedrijfsomgevingen biedt Windows Server Update Services
(WSUS) mogelijkheden om patches binnen de eigen infrastructuur uit te rollen.
Ook Linux-systemen kennen standaard updatemechanismen. Hierbij kan men
denken aan toepassingen als apt-get (Debian), up2date (Red Hat),
MandrakeUpdate (Mandriva), YaST (SUSE) en yum (Fedora).
Grofweg bestaat een juist ingericht patch management proces uit de volgende
onderdelen:
• Stap 1: vaststellen dat een patch beschikbaar is gekomen. Voordat de

organisatie beseft dat het een patch moet installeren, is het eerst zaak op
de hoogte te zijn van het feit dát een patch beschikbaar is gekomen.
Hiertoe kan de organisatie monitoringprocessen inregelen voor de meest
gebruikte technologieën. De advisorydienst van GOVCERT.NL is een
manier om op de hoogte te blijven van de laatst uitgebrachte patches van
leveranciers.
• Stap 2: beoordeel de impact van de uitgebrachte patch en de

bijbehorende kwetsbaarheid. Mogelijk is de kwetsbaarheid technisch
gezien vrij ernstig maar bestaan er, gezien de inrichting van de
infrastructuur van de organisatie, verzachtende omstandigheden waardoor
de kwetsbaarheid voor de organisatie minder ernstig is. Als de impact van
zowel kwetsbaarheid als patch bepaald is, kan de organisatie bepalen of er
sprake is van een acuut (beveiligings)probleem.
• Stap 3: verkrijgen van de patch. De organisatie zal de patch moeten

ophalen bij de leverancier ervan. Tegenwoordig verloopt dat in alle
gevallen via internet.

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

de testen acceptatieomgeving is gebleken dat de patch geen negatieve
effecten heeft, kan men besluiten om de patch uit te rollen op alle
productieservers.
• Stap 6: monitoor eventuele berichtgeving rondom de patch. Nadat een

patch is uitgebracht door een leverancier verschijnen in sommige gevallen
berichten op internet waarin organisaties problemen met de patch
beschrijven. Deze problemen kunnen zich mogelijk ook voordoen in de
eigen omgeving waardoor kennis hiervan van belang kan zijn.
4.3.2 Verwijder onnodige services

Bij het hardenen van het systeem is een belangrijke strategie om de
communicatiemogelijkheden van het systeem tot een minimum (het strikt
noodzakelijke) te beperken. Eén van de manieren om dit te bereiken is door
onnodige services uit te schakelen. Door benodigde services in kaart te brengen
en vervolgens de afhankelijkheden te bepalen komt men tot een minimale lijst
van services die het betreffende systeem dient te ondersteunen. Alle overige
services kan men óf uitschakelen óf verwijderen.
VOORBEELD Debian biedt de tool rcconf (zie onderstaande schermafdruk) als

hulpmiddel voor het bepalen van de services die het systeem moet starten tijdens
het booten van het systeem. De tool haalt een lijst van services op uit /etc/init.d
en kijkt vervolgens in de /etc/rc?.d directories om te bepalen of deze services
automatisch starten. Via de tool kan men de configuratie ook aanpassen.
Bedenk dat niet-actieve maar wel aanwezige services op een systeem uiteindelijk
toch tot een kwetsbaar systeem kunnen leiden aangezien ‘lekke’ programmacode

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

Het beperken van rechten op een systeem voorkomt misbruik van dit systeem. De
manier waarop het systeem deze rechtenbeperking mogelijk maakt, hangt af van
het gebruikte besturingssysteem. Hieronder volgen enkele aanwijzingen voor het
inperken van rechten op twee populaire typen besturingssystemen: Linux en
Microsoft Windows.
Linux:
• chmod (change mode) en chown (change owner) vormen de belangrijkste
mechanismen voor het beveiligen van bestanden en directories. chmod biedt
mogelijkheden om rechten op bestanden en directories in te stellen en chown
maakt het mogelijk om de eigenaar van een bestand of directory te wijzigen.
• umask wijzigt de modus voor het aanmaken van nieuwe bestanden. Door via
umask een zeer strikte modus in te schakelen voorkomt men dat nieuw
aangemaakte bestanden ‘per ongeluk’ toegankelijk zijn voor ongeautoriseerde
gebruikers.
• setuid (Set UserID) en setgid (Set GroupID) zijn vlaggen die men aan
bestanden en directories op een Linux-systeem kan hangen. De vlaggen
maken het mogelijk om bepaalde bestanden met tijdelijk verhoogde
gebruikersrechten uit te voeren. Het is van belang deze privileges nauwgezet
te monitoren en deze selectief uit te delen.
• Normaal gesproken geldt dat, wanneer een gebruiker schrijfrechten heeft op
een directory, deze gebruiker ook bestanden uit deze directory kan
verwijderen. Dit kan zelfs wanneer de gebruiker niet de eigenaar is van deze
bestanden. Door het plaatsen van een zogenaamd ‘sticky bit’ op de directory
voorkomt men dit. Sticky bits kan men daarom toepassen om de toegang tot
het bestandssysteem verder in te perken.
• Via chattr kunnen verschillende attributen op bestanden en directories
worden geplaatst. Enkele van deze attributen zijn bruikbaar vanuit het
oogpunt van beveiliging. Het gaat in het bijzonder om de volgende attributen:
o ‘a’-attribuut: gebruikers (en processen) kunnen een bestand met het ‘a’-
attribuut alleen in ‘append’-mode openen voor schrijven. Dit betekent dat
de gebruiker (of het proces) wel inhoud aan het bestand kan toevoegen,
maar bestaande inhoud niet kan overschrijven of verwijderen.
o ‘i’-attribuut: gebruikers (en processen) kunnen bestanden met een ‘i’-
attribuut niet verwijderen of hernoemen. Daarnaast is het niet mogelijk
om links naar dit bestand op te nemen of inhoud naar het bestand te
schrijven
o ‘u’-attribuut: wanneer een gebruiker (of proces) een bestand met een ‘u’-
attribuut verwijdert, slaat het besturingssysteem de inhoud van dit
bestand op. Hierdoor biedt het besturingssysteem de mogelijkheid om de
verwijdering van een bestand later ongedaan te maken.
• Bovenstaande punten hadden allen betrekking op het inperken van rechten op
het niveau van het bestandssysteem. Het is in Linux ook mogelijk om de
rechten op het niveau van de kernel in te perken. Een handige tool voor het

administreren van deze rechten is lcap. Het bijzondere aan deze
rechtenbeperking via de kernel is dat de beperking ook van toepassing is op
de ‘root’-gebruiker. Zaken die de kernel kan beperken c.q. onmogelijk kan
maken zijn bijvoorbeeld het wijzigen van de GID en de UID en het ‘killen’ van
processen.
Windows:
Microsoft Windows biedt de mogelijkheid om rechten toe te passen op o.a.
bestanden, directories en het register. Via zogenaamde Group Policy Objects
(GPO) kunnen beheerders de rechten van gebruikers centraal via de Active
Directory (AD) inregelen.
4.3.4 Harden de implementatie van essentiële protocollen

Door essentiële protocollen op een server te hardenen, voorkomt men misbruik
van deze protocollen en verhoogt men de stabiliteit van het systeem. Dit kan
ervoor zorgen dat een eventuele kwetsbaarheid in een dergelijk protocol niet
direct ernstige consequenties voor het systeem hoeft te hebben. Eén van de
protocollen die zich uitstekend leent voor hardening is TCP/IP. Zoals al in
paragraaf 3.3.9 werd beschreven, kan het hardenen van de TCP/IP-stack ervoor
zorgen dat het risico op een succesvolle DoS aanval vermindert. Voor elk type
besturingssysteem bestaan mogelijkheden om de configuratie van de TCP/IP-
stack zodanig te veranderen dat deze beter bestand is tegen aanvallen. Het is aan
te raden om goed uit te testen wat de gevolgen van deze veranderingen zijn,
zodat geen ongewenste gevolgen voortvloeien uit deze wijzigingen.
VOORBEELD De TCP/IP-stack van Windows Server 2003 is standaard ingericht

voor het afhandelen van intranet verkeer. Wanneer een organisatie een Windows
Server 2003 machine aansluit op internet raadt Microsoft aan enkele wijzigingen
door te voeren in de configuratie van de TCP/IP-stack. Deze wijzigingen voert
men door, door de inhoud van bepaalde registersleutels aan te passen. Deze
wijzigingen hebben tot doel om:
• Timeouts gedurende een SYN-attack te verminderen;

• Te voorkomen dat het systeem dynamisch een alternatieve gateway verkiest;
• Te voorkomen dat het systeem een dynamische MTU kiest;
• Keep-alive mechanismen in te schakelen;
• Te voorkomen dat het systeem zijn NetBIOS naam vrijgeeft.
Zie voor meer informatie: http://support.microsoft.com/?kbid=324270
In webomgevingen leent HTTP zich ook voor hardening. Om bijvoorbeeld een

Denial-of-Service-aanval op HTTP-niveau te voorkomen, kan men ervoor kiezen
om de idle timeout van een HTTP-sessie te verkleinen en ‘session pooling’ tussen
een eventuele application-level firewall (hoofdstuk 5) en webservers aan te
schakelen. ‘Session pooling’ verhoogt de performance van HTTP door de kosten
die gepaard gaan met het steeds opnieuw opbouwen van een HTTP-sessie te
voorkomen. Zo kan een application-level firewall meerdere kleinere bestanden via

één HTTP-sessie ophalen bij een webserver. Naast dat dit leidt tot meer efficiëntie
en betere responsetijden, helpt dit ook in het voorkomen van eerder genoemde
DoS-aanvallen.
4.3.5 Maak gebruik van jailing

Een mechanisme dat voornamelijk bestaat op het Linux- en Unix-platform is
jailing (sandboxing). Het is een zeer eenvoudige vorm van isolatie van een
proces. Een bekende implementatie hiervan is chroot. Het commando chroot
wijzigt de root-directory voor een proces (change root). Door een proces via
chroot te laten werken, kan het proces niet buiten zijn root-directory treden. Dit
mechanisme kan men bijvoorbeeld inzetten om de Apache-server geïsoleerd te
laten draaien.
VOORBEELD Over het ‘chrooten’ van Apache zijn enkele goede ‘howto’-artikelen
terug te vinden op internet. Zie onder andere:
• Howto: Chroot Apache (haught.org):

http://www.haught.org/freebsdapache.php
• Chrooting Apache (Linux.com):
http://www.linux.com/article.pl?sid=04/05/24/1450203
Voordat men besluit om Apache in een ‘chrooted’-configuratie te laten werken is

het belangrijk dat men op de hoogte is van eventuele problemen die dit met zich
mee kan brengen. Zo moet men eventuele bibliotheken en executables waarvan
Apache gebruik maakt, beschikbaar maken in de ‘chrooted’-omgeving. Om deze
problemen zoveel mogelijk te voorkomen is ‘chroot’-functionaliteit ook ingebouwd
in de ModSecurity application-level firewall (vanaf versie 1.6). Meer informatie
over deze – nog experimentele – functionaliteit in ModSecurity vindt u hier:
http://www.modsecurity.org/documentation/apache-internal-chroot.html
Naast het afschermen van directories via chroot bestaan er ook mechanismen om
andere delen van het besturingssysteem af te schermen; voorbeelden zijn het
beperken van I/O rates, het beperken van het toegestane hoeveelheid geheugen,
het beperken van de toegestane hoeveelheid CPU-cycles, etc…
VOORBEELD Afscherming van processen kan zover gaan dat op een gegeven
moment virtualisatie ontstaat. Toepassingen als VMware, QEMU, Xen en Microsoft
Virtual Server bieden bijvoorbeeld de mogelijkheid om volledig autonome
besturingssystemen naast elkaar te laten functioneren.
4.3.6 Hanteer strikte OS-authenticatie(mechanismen)

Het is cruciaal dat beheerders de authenticatie tot systemen zeer strikt inregelen.
Afhankelijk van het type besturingssysteem kunnen zij hiertoe een aantal
verschillende maatregelen treffen. Enkele aanbevelingen zijn echter meer
generiek van aard en zijn van toepassing op vrijwel alle besturingssystemen:

• Zorg ervoor dat het systeem niet toegankelijk is op basis van ‘anonieme’
accounts.
• Overweeg de invoering van sterke authenticatiemechanismen voor de
toegang tot systemen. Deze mechanismen kenmerken zich door het
gebruik van twee factoren voor authenticatie. Zie hoofdstuk 6 (‘Identiteit-
en toegangsbeheer’) voor meer informatie over dergelijke
authenticatiemechanismen.
• Beperk de groepslidmaatschappen van gebruikers.
• Implementeer een strikte password policy. In een password policy legt
men zaken vast als minimale passwordlengte, lengte van de
passwordhistorie, complexiteit van het wachtwoord, account lockouts,
etc…
• Verwijder ongebruikte accounts en standaard aanwezige accounts.
• Hernoem ‘bekende’ accounts (zoals bijvoorbeeld ‘administrator’).
4.3.7 Maak gebruik van veilige beheermechanismen

Voorkom zoveel mogelijk het gebruik van onveilige beheermechanismen. Gebruik
dus bijvoorbeeld SSH in plaats van Telnet. Zorg er daarnaast voor dat
beheerinterfaces alleen bereikbaar zijn vanaf een gescheiden beheernetwerk (zie
hoofdstuk 3).
Het gebruik van ‘backdoors’ moet absoluut uitgesloten zijn. Een backdoor voor
beheer is bijvoorbeeld een beheer interface waarvoor geen authenticatie benodigd
is maar die draait op poort 8888 en daardoor moeilijk te ontdekken zou moeten
zijn (‘security through obscurity’). De kans is echter groot dat kwaadwillenden
backdoors vroeg of laat ontdekken, en erin slagen om deze te misbruiken.
4.3.8 Maak back-ups

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

4.3.9 Maak gebruik van lokale firewalls
In het vorige hoofdstuk werd beschreven hoe centraal geplaatste firewalls de
omgeving kunnen beschermen tegen kwaadwillenden. Naast deze centrale
firewalls is het ook mogelijk om decentraal, op de verschillende machines, een
aparte firewall te laten werken. Deze lokale (decentrale) firewalls vormen
daarmee een extra laag in de beveiliging. Veel besturingssystemen bieden de
mogelijkheid tot het gebruik van een lokale firewall. Enkele voorbeelden van deze
firewalls zijn:
• ipfw; FreeBSD packet filter. Het is daarnaast een standaard onderdeel van
Apple Mac OS. Voor simpele regels biedt Apple daarnaast een eenvoudige
grafische gebruikersinterface.
• pf; OpenBSD packet filter. Is de opvolger van ipfilter voor het

OpenBSD platform.
• iptables; standaard onderdeel van veel Linux-distributies. Maakt gebruik

van netfilter.
• ipfilter (ipf); onderdeel van Linux-distributies en Unix (onder andere

Sun Solaris 10).
• Windows Firewall; onderdeel van Windows XP SP2 en Windows Server

2003.
Lokale firewalls hebben als voordeel dat ze niet alleen op poortniveau controles
kunnen uitvoeren maar ook procesniveau. Verder hebben lokale firewalls vaak
meer inzicht in het verkeer dat zich richting de machine begeeft omdat op de
machine zelf ontsleuteling van eventuele versleutelde tunnels plaatsvindt.
Daarnaast bevatten lokale firewalls vaak veel minder regels in de rulebase
waardoor fouten in de configuratie minder aannemelijk zijn.
Tot slot bieden deze firewalls veelal ook uitgebreide mogelijkheden op het gebied
van logging en Network Address Translation (NAT).
ACHTERGROND Door de uitgebreide mogelijkheden die met name de Linux-

en Unix-gebaseerde firewalls leveren, is het ook mogelijk deze in te zetten als
centrale firewall. Wanneer een firewall wordt ingezet als een centrale firewall
spreekt men ook wel van een perimeter firewall (pfw). Een lokale firewall noemt
men in dit verband ook wel een end-point firewall (epfw).
4.3.10 Audit de wijzigingen op het systeem

Op het moment dat een kwaadwillende erin slaagt om een kwetsbaar systeem te
compromitteren, zal deze vaak wijzigingen (moeten) aanbrengen op dit systeem.
Het auditen van de wijzigingen die op systemen plaatsvinden, kan daarom helpen
in het opmerken van misbruik van de omgeving. Door op het platform tools in te

zetten die deze wijzigingen in kaart brengen en deze informatie beschikbaar te
stellen aan “Monitoring, auditing en alerting” (hoofstuk 9) kan men deze
wijzigingen adequaat monitoren.
VOORBEELDEN Eén van de bekendste tools die men kan inzetten om

wijzigingen op een systeem te detecteren is Tripwire. Er is zowel een commerciële
als een open-source versie van dit pakket beschikbaar. Tripwire houdt een
database bij waarin het een snapshot van het bestandssysteem opslaat. Via een
policy bepaalt Tripwire welke wijzigingen op dit snapshot mogelijk gevaarlijk zijn
(bijvoorbeeld het toevoegen van een gebruiker of een ‘root’-gebruiker zonder
wachtwoord).
Microsoft Windows kent ingebouwde functionaliteit om wijzigingen op bestanden

e.d. te auditen. Het is van belang dat men, bij toepassing hiervan, strikte
auditregels opstelt aangezien anders de hoeveelheid auditdata extreme vormen
kan aannemen.
4.3.11 Maak gebruik van beveiligingstemplates

Alle hardeningsmaatregelen die benodigd zijn voor servers kan een organisatie
opnemen in beveiligingstemplates. Beveiligingstemplates kan men opstellen aan
de hand van het gebruikte besturingssysteem (bijvoorbeeld “Microsoft Windows
Beveiligingstemplate”) en aan de hand van de rol die het systeem vervult
(bijvoorbeeld webserver, database server, etc…). Probeer alle mogelijke
hardeningsmaatregelen eerst uit in een representatieve testomgeving zodat zeker
is dat het betreffende systeem zonder probleem zal blijven functioneren zodra de
maatregelen zijn geëffectueerd. Beveiligingstemplates bestaan in ieder geval uit
documenten die de hardening beschrijven. Scripts, images,
configuratiebestanden, etc… kunnen deze templates vervolgens technisch
ondersteunen.
ACHTERGROND Er zijn op internet diverse handleidingen te vinden die men

kan gebruiken bij het opstellen van beveiligingstemplates. Onderstaand vindt u
een opsomming van enkele bruikbare stukken op dit gebied:
• Windows Server 2003 Security Guide (Microsoft):

http://www.microsoft.com/downloads/details.aspx?familyid=8a2643c1-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 APPLICATIEBEVEILIGING
5.1 Inleiding
Daar waar netwerkbeveiliging zich richt op het afschermen van het netwerk op
basis van te onderscheiden protocollen zal applicatiebeveiliging een niveau dieper
gaan en de inhoud van de protocollen willen bekijken. Een applicatiefilter heeft
kennis over het gebruikte protocol en kan bepalen of het gebruik van het protocol
voldoet aan eerder opgestelde policies en syntaxis. Door applicatie filtering toe te
passen kunnen applicaties er vanuit gaan dat de aangeboden applicatieaanvragen
(requests) syntactisch correct zijn bevonden en zijn genormaliseerd.
Veel identieke beveiligingsproblemen keren terug in een groot aantal verschillende

webapplicaties. Het “Open Web Application Security Project” (OWASP –
www.owasp.org) heeft de 10 meest gemaakte (beveiligings-)problemen in
webapplicaties samengevat in een top 10. Deze paragraaf geeft een overzicht de
meest voorkomende kwetsbaarheden en bedreigingen op het gebied van
webapplicaties. De problemen zoals geschetst in de “OWASP top 10” zijn in dit
overzicht verwerkt.
ACHTERGROND Een project genaamd ‘Common Weakness Enumeration’

(CWE) tracht een complete lijst van alle mogelijke kwetsbaarheden in software
samen te stellen. Deze zeer uitgebreide lijst bevat, naast de kwetsbaarheden
zoals beschreven in deze paragraaf, nog een groot aantal andere
kwetsbaarheden. Hoewel de lijst niet specifiek is toegespitst op webapplicaties is
het aardig om de lijst eens te doorlopen om meer inzicht te krijgen in de
mogelijke problemen die zich in software kunnen voordoen. U kunt de lijst hier
terug vinden: http://cve.mitre.org/cwe/
5.2.1 Ongevalideerde input

Het niet juist valideren van input blijkt één van de meest gemaakte fouten in
webapplicaties. Webapplicaties moeten er per definitie vanuit gaan dat alle
informatie die zij toegestuurd krijgen niet te vertrouwen is. Applicaties kunnen
niet vertrouwen op eventuele controles die client-side scripts hebben uitgevoerd
omdat deze scripts eenvoudig te omzeilen zijn. Het niet juist valideren van input
van gebruikers ligt ten grondslag aan drie bekende 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.2.2 Cross-Site Scripting (XSS)
Cross-Site scripting (XSS11) houdt in dat een kwaadwillende kwaadaardige code
injecteert in een link die verwijst naar een vertrouwde website. Hiertoe moet de
kwaadwillende de beschikking hebben over een alom vertrouwde website die
mogelijkheden biedt tot XSS.
In juni 2006 ondervond PayPal zulke XSS-problemen op zijn website. Het scenario
dat kwaadwillenden konden gebruiken om deze kwetsbaarheid uit te buiten is
gelijk aan dat van figuur 5-1. In figuur 5-1 is een legale, vertrouwde website
opgenomen. Een gebruiker ontvangt via zijn e-mail een verzoek om verbinding
met deze website te maken (bijvoorbeeld met als reden dat er een speciale
reclame zou zijn). Wanneer de gebruiker de link volgt zal deze in eerste instantie
wellicht niet achterdochtig worden: de gebruiker krijgt een volledig correcte SSL-
verbinding met de betreffende website en het inloggen verloopt zonder
problemen. Echter, de kwaadwillende heeft in de URL een script verpakt dat wordt
uitgevoerd zodra het slachtoffer verbinding heeft gemaakt met de vertrouwde
website. Doordat de website parameters in de URL niet goed afhandelt, stuurt de
webserver het script als opdracht terug naar het slachtoffer, waarna de client het
aldaar uitvoert. Het script dat de kwaadwillende heeft geïnjecteerd, zorgt ervoor
dat de client de inloggegevens van de gebruiker verstuurt naar een server van de
kwaadwillende. Op deze manier kan deze kwaadwillende inloggegevens van een
groot aantal gebruikers verzamelen en misbruiken.
Figuur 5-1: voorbeeld van Cross-Site Scripting (XSS)
11
Bij de introductie van dit begrip werd Cross-Site Scripting afgekort tot CSS. Aangezien dit tot verwarring kan
leiden met andere reeds bestaande begrippen (bijvoorbeeld Cascading Style Sheets) is besloten om Cross-Site
Scripting af te korten tot XSS.

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

SQL injection ontstaat, net als XSS, door onvoldoende controles op de invoer van
gebruikersdata. De aanwezigheid van een SQL injection kwetsbaarheid betekent
dat een gebruiker op het internet in staat is om de SQL-verzoeken die een
webapplicatie verstuurt naar de database, te manipuleren. De gevolgen van deze
kwetsbaarheid zijn in grote mate afhankelijk van de programmalogica. Mogelijke
gevolgen zijn:
• Een kwaadwillende kan het authenticatiemechanisme van de webapplicatie

omzeilen en op deze manier ongeautoriseerd ‘inloggen’ op de
webapplicatie;
• Een kwaadwillende kan gegevens in de database wijzigen zonder dat de
organisatie dit opmerkt;
• Een kwaadwillende kan de volledige database ‘droppen’ waardoor alle
informatie uit de database verloren gaat;
• Een kwaadwillende kan een eigen gebruikersaccount aanmaken zonder dat
de organisatie dit opmerkt en dit account gebruiken om toegang tot de
webapplicatie te verkrijgen en te behouden.
Bovenstaande gevolgen dienen slechts als voorbeeld. In de praktijk zijn de

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

Figuur 5-2: voorbeeld van SQL injection
Zoals het proces in figuur 5-2 weergeeft, vertrouwt de webapplicatie de invoer

van de gebruiker zonder meer en verwerkt de webapplicatie deze input
rechtstreeks in een SQL-verzoek richting de database. De programmalogica is
zodanig gebouwd dat een gebruiker succesvol geauthenticeerd is wanneer de
query meer dan 0 resultaten genereert; het idee hierachter is dat het zoeken op
een combinatie van gebruikersnaam en wachtwoord alleen resultaten oplevert als
de gebruikersnaam en het bijbehorende wachtwoord voorkomen in de database.
De webapplicatie construeert hiertoe de volgende query:
SELECT *
FROM gebruikers
WHERE gebruikersnaam = ‘<gebruikersnaamveld>’
AND wachtwoord = ‘<wachtwoordveld>’
Door het wachtwoordveld te manipuleren kan de kwaadwillende bereiken dat de

webapplicatie aan de zoekopdracht de voorwaarde “OF 1=1” toevoegt. Dit bereikt
de kwaadwillende door bij gebruikersnaam ‘1’ in te vullen en bij wachtwoord “x’
OR ‘1=1”. Hierdoor ontstaat de volgende query:
SELECT *
FROM gebruikers
WHERE gebruikersnaam = ‘1’
AND wachtwoord = ‘x’ OR ‘1=1’

Eén is vanzelfsprekend altijd gelijk aan één waardoor elk record uit de
gebruikerstabel voldoet aan dit zoekcriterium. Dientengevolge zal het uitvoeren
van het SQL-verzoek alle records uit de tabel als resultaat geven. Hierdoor
concludeert de programmalogica dat het gebruikersnaam met dit wachtwoord
voorkomt in de database en dat de gebruiker dus geautoriseerd is voor toegang
tot de webapplicatie.
OPMERKING Wanneer de applicatie geen verbinding met een database maar

met een andere dataverzameling opzet, kan hetzelfde probleem zich ook op een
andere manier manifesteren. Denk hierbij bijvoorbeeld aan misbruik van een
verbinding tussen de webapplicatie en een LDAP server (LDAP injection).
5.2.4 Buffer overflows

Buffer overflows kunnen zich voordoen in elk stuk softwarecode. Een buffer
overflow doet zich voor op het moment dat de applicatie meer data naar een
geheugenbuffer schrijft dan dat daar initieel voor was gereserveerd. Hierdoor
komt data op plekken in het geheugen terecht waar dit eigenlijk niet had
gemogen. Misbruik van een buffer overflow kan leiden tot het uitvoeren van
willekeurige code op het systeem; hierdoor kan een kwaadwillende in het
ernstigste geval volledige controle over een server krijgen.
Buffer overflows zijn niet altijd eenvoudig te ontdekken en daarnaast blijkt het
vaak moeilijk om een gevonden buffer overflow te misbruiken. Van sommige
ontdekte kwetsbaarheden publiceert de ontdekker Proof-of-Concept (PoC) code op
internet waardoor de kans op uitbuiting plotseling sterk toeneemt. In sommige
gevallen publiceert de ontdekker zelfs code waarmee een kwaadwillende de
kwetsbaarheid in zijn volledigheid kan uitbuiten (exploit).
ACHTERGROND Proof-of-Concept (PoC) code bewijst dat een bepaalde

kwetsbaarheid aanwezig is binnen software. Een PoC buit deze kwetsbaarheid
echter niet maximaal uit. Een exploit doet dit wel. Een voorbeeld is een
kwetsbaarheid in een browser waarbij men volledige controle kan krijgen over een
kwetsbaar systeem. Een PoC bewijst dat de kwetsbaarheid aanwezig is door via
de code de browser te laten crashen, de exploit biedt de mogelijkheid om ook
daadwerkelijk controle over het kwetsbare systeem te krijgen. De code achter een
PoC en een exploit kan vrijwel overeen komen.
5.2.5 Lekken van informatie

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

5.2.5.1 Uitgebreide foutmeldingen
Fouten in webapplicaties zullen zich altijd voordoen. Wat van belang is, is hoe de
webapplicatie met deze fouten omgaat. Sommige webapplicaties leveren bij het
optreden van een foutsituatie allerlei informatie aan over de achtergrond(en) van
de fout. Figuur 5-3 toont een dergelijke foutmelding.
Figuur 5-3: voorbeeld van een verbale foutmelding
Een uitgebreide foutmelding kan een kwaadwillende helpen om meer inzicht te

krijgen in de programmalogica van een webapplicatie. Een foutmelding vertelt
vaak iets over de gebruikte database, het uitgevoerde SQL-verzoek of het
aangeroepen bestand. Al deze informatie draagt bij aan kennisvorming van de
kwaadwillende over de infrastructuur. Stel bijvoorbeeld dat een webapplicatie een
SQL-injection kwetsbaarheid (5.2.3) bevat. De mogelijkheden die de
kwaadwillende heeft zijn mogelijk redelijk beperkt als deze geen inzicht heeft in
de opbouw van de code en de database. Wanneer de kwaadwillende er echter in
slaagt om een foutmelding te forceren met daarin de beschrijving van een SQL-
verzoek dat mislukt, dan heeft deze op dat moment voldoende informatie om met
andere (soortgelijke) SQL-verzoeken te gaan experimenteren. De kwaadwillende
heeft op dat moment bijvoorbeeld kennis van attribuutnamen, tabelnamen,
databasenamen, etc…
OPMERKING Ook het ontstaan van foutmeldingen kan men deels wijten aan het
onvoldoende controleren op input van gebruikers. Een foutmelding ontstaat
namelijk in veel gevallen doordat er zich een uitzondering voordoet binnen de
programmalogica. Deze uitzondering kan ontstaan uit het feit dat een verwachte
verbinding richting een database niet beschikbaar is maar ook omdat de
webapplicatie niet goed weet om te gaan met ‘afwijkende’ input’: de applicatie
krijgt bijvoorbeeld een string te verwerken terwijl het een getal verwacht.

5.2.5.2 Header-informatie
HTTP-headers kunnen veel informatie verschaffen over de webapplicatie en de
software waarvan de webapplicatie gebruik maakt. Eén van de bekendste HTTP-
headers die informatie vrijgeeft is de “Server”-header. In veel gevallen zal de
webserver via deze header informatie geven over het type webserver
waarvandaan de pagina afkomstig is. In sommige gevallen bevat deze header
echter nog veel meer informatie. Figuur 5-4 geeft een voorbeeld van een
dergelijke header.
Figuur 5-4: voorbeeld van HTTP-header informatie
In figuur 5-4 is een voorbeeld opgenomen van een antwoord dat een webserver
geeft n.a.v. het opvragen van een webpagina. Zoals in dit voorbeeld is te zien
toont de webserver niet alleen de gebruikte webserver-versie (Apache/1.3.27 op
Red Hat Linux) maar bijvoorbeeld ook de gebruikte versies van OpenSSL en PHP.
Op basis van deze informatie kan een kwaadwillende zeer gerichte aanvallen
uitvoeren op de webserver. Informatiebronnen als Secunia, de National
Vulnerability Database (NVD) en SecurityFocus kunnen de kwaadwillende hierbij
voorzien van de laatste kwetsbaarheden die bekend zijn met de gebruikte
software.
5.2.5.3 Commentaarregels in scripts

Commentaarregels in code kunnen ongewild informatie vrijgeven aan de
eindgebruiker. Met name HTML-code en client-side scripts (zoals Javascript)
kunnen dit commentaar bevatten. Commentaarregels zijn niet altijd
problematisch; in sommige gevallen bevat commentaar echter ‘een
geheugensteuntje’ voor programmeurs en vergeten zij deze informatie te
verwijderen zodra een webapplicatie in productie gaat. Figuur 5-5 geeft een zeer
eenvoudig voorbeeld van commentaar in Javascript - in een inlogpagina - dat een
kwaadwillende kan lezen en mogelijk misbruiken.

Figuur 5-5: voorbeeld van commentaarregels die veel informatie onthullen
5.2.6 Onveilige opslag van informatie

Een webapplicatie maakt vaak gebruik van grote hoeveelheden informatie. Van
belang is op welke manier de webapplicatie deze informatie opslaat. Technisch
gezien kan de webapplicatie voor opslag van gegevens gebruik maken van lokale
bestanden op de webserver en databases. Vaak vindt de opslag van gegevens
onversleuteld plaats. Dit kan ernstige gevolgen hebben wanneer een
kwaadwillende erin slaagt om deze gegevens te benaderen. Onderstaand volgen
twee voorbeelden van situaties waarin de onversleutelde opslag van gegevens tot
problemen leidt.
Voorbeeld #1: opslag van adresgegevens in een lokaal tekstbestand

Een webapplicatie verzamelt adresgegevens van particulieren. De organisatie
gebruikt deze gegevens om abonnees per post een nieuwsbrief te versturen.
Zodra een gebruiker zijn gegevens invult op een webpagina slaat de webapplicatie
de gegevens op in het bestand ‘/webapp/abonnees.txt’. De ontwikkelaar ging
ervan uit dat deze gegevens hier veilig stonden omdat de webapplicatie draait
vanuit ‘/webapp/wwwroot/’ (webroot). Een kwaadwillende vindt echter een fout in
een script binnen de webapplicatie waardoor deze erin slaagt buiten de webroot te
treden. Het volgende verzoek naar de webapplicatie levert de kwaadwillende de
inhoud van het bestand op:
http://www.eenwebsite.nl/showfile.php?file=%2Fwebapp%2Fabonnees.txt
Hoewel het onversleutelde bestand normaal gesproken niet via internet te

bekijken is, zorgt de kwetsbaarheid in een script (showfile.php) binnen de
webapplicatie ervoor dat het bestand toch te benaderen en te lezen is.

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

De configuratie van de webapplicatie en het applicatieplatform spelen een
belangrijke rol in de beveiliging van het geheel. Door een webapplicatie en/of
applicatieplatform te installeren zonder daarbij aandacht te besteden aan de
configuratie ervan kunnen zich een aantal verschillende beveiligingsproblemen
voordoen. Enkele voorbeelden hiervan:
• Gebruik van standaardpaden voor de webroot; veel webservers

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

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

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

• Aanwezigheid van standaard plug-ins; een ‘kaal’ geïnstalleerde
webserver kent over het algemeen al een aantal plug-ins die
functionaliteiten binnen de webserver ondersteunen. Een webapplicatie
hoeft niet per definitie gebruik te maken van deze plug-ins. Dit kan ertoe
leiden dat een bepaalde plug-in wel aanwezig is op een webserver, maar
dat geen aandacht is besteed aan de beveiliging ervan. Hierdoor kan een
mogelijk beveiligingslek ontstaan.
• Ontbreken van patches; wanneer men een applicatieplatform installeert

vanaf een medium (bijvoorbeeld CD-ROM) is de kans aanwezig dat op dit
medium nog niet de laatste patches voor het applicatieplatform zijn
geplaatst. Wanneer men vergeet om deze patches na installatie van de
webserver te downloaden en te installeren, bevat de applicatie ongedichte
lekken. Het spreekt voor zich dat kwaadwillenden deze lekken kunnen
misbruiken om zich toegang te verschaffen tot de webserver of
webapplicatie.
• Aangeschakelde ‘debugging’-opties; sommige applicatieplatformen

ondersteunen standaard een aantal ‘debugging’-opties. Debugging is
bedoeld om het aantal bugs (fouten) in een applicatie te verminderen door
duidelijke foutmeldingen te genereren in het geval zich een probleem
voordoet. Deze foutmeldingen kan een kwaadwillende in zijn voordeel
gebruiken (zie 5.2.5.1).
5.2.8 Kwetsbare aangekochte applicaties

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

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

5.3 Aanbevelingen
Deze paragraaf beschrijft aanbevelingen op het gebied van applicatiebeveiliging.

De paragraaf start met een beschrijving van het begrip ‘application-level firewall’.
Daarop volgen een groot aantal aanbevelingen die men zowel losstaand als via
een application-level firewall kan implementeren.
5.3.1 Overweeg de invoering van een application-level firewall

Een application-level firewall heeft specifieke kennis van een bepaald protocol. In
het geval van webapplicaties dient de application-level firewall diepgaande kennis
te hebben van het HTTP-protocol. Daarnaast is ook kennis van de payloads van
HTTP-berichten (XML in het geval van webservices) van belang. Een 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 een
maakt in de meeste gevallen gebruik van applicatie-proxies. Deze applicatie-
proxies zetten, voor de totstandkoming van een verbinding tussen client en
server, aparte sessies op met de client en met de server. Op deze manier kunnen
de applicatie-proxies al het verkeer dat client en server met elkaar uitwisselen
inspecteren en op deze manier verdacht verkeer tegen houden. Een applicatie-
proxy heeft specifieke kennis van een bepaald protocol. Wanneer men spreekt
over een application-level firewall die ingezet wordt voor de beveiliging van
webapplicaties (een web application-level firewall) dan betekent dit dat de firewall
gebruik maakt van applicatie-proxies die specifieke kennis hebben van HTTP en
aanverwante protocollen en standaarden (bijvoorbeeld HTML en XML).
5.3.1.2 Plaatsing van de application-level firewall

Een application-level firewall kan men op verschillende manieren inpassen in de
DMZ-infrastructuur. Binnen de infrastructuur fungeert de application-level firewall
als een reverse proxy. Dit betekent dat de application-level firewall alle
verbindingen vanaf een client richting een webapplicatie afhandelt en dat de
reverse proxy (de application-level firewall) zélf een verbinding opzet met de
achterliggende webapplicatie. Dit is dus precies een omgekeerde (reverse)
werking van een ‘normale’ proxy waarbij de proxy intern verkeer naar externe
servers verstuurt. Figuur 5-6 geeft een overzicht van mogelijke manieren waarop
men de application-level firewall in de DMZ van hoofdstuk 3 kan plaatsen.

Figuur 5-6: plaats van de application-level firewall
Bij de oplossingen (a), (b) en (c) uit figuur 5-6 is de application-level firewall een
losstaand netwerkcomponent binnen de DMZ-infrastructuur. Er bestaan echter
ook een aantal oplossingen die niet als losstaand netwerkcomponent maar als
plug-in op de webserver fungeren. Deze situatie is weergegeven in optie (d) in
figuur 5-6.
5.3.1.3 Functionaliteiten
De functionaliteiten die application-level firewalls bieden, verschillen van
leverancier tot leverancier. Er zijn echter een aantal functionaliteiten die in veel
producten terugkeren:
• Caching: het tijdelijk cachen van opgevraagde content (zoals bijvoorbeeld

plaatjes) teneinde de load op de achterliggende webservers te
verminderen.
• Beheer via een eigen grafische gebruikersinterface; veel 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; een

application-level firewall kan gebruikersverzoeken doorsturen naar
verschillende achterliggende webservers. De keuze baseert de application-
level firewall hierbij op de gebruikte URL. Op deze manier is het mogelijk
dat de inhoud van één website afkomstig is van verschillende

achterliggende webservers.
• Uitvoeren van inputvalidatie (zie 5.3.2): deze inputvalidatie betreft

validatie 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. Dit
houdt in dat de application-level firewall sites authenticeert middels
server-side SSL-certificaten en daarnaast gebruikersauthenticatie middels
client-side SSL-certificaten kan toepassen.
• Controle van digitale handtekeningen (hoofdstuk 6); wanneer op basis

van standaard protocollen digitale handtekeningen op uitgewisselde
informatie zijn geïmplementeerd, kan de application-level firewall deze
handtekeningen controleren en verkeer alleen accepteren wanneer de
digitale handtekening in orde blijkt te zijn. Deze functionaliteit is
voornamelijk aanwezig bij het gebruik van webservices.
• Bescherming tegen lekken van informatie (zie 5.3.5); door de

uitgebreide controles die de application-level firewall kan uitvoeren op de
verschillende onderdelen van een HTTP-antwoord, kan deze gevoelige
informatie uit het antwoord filteren en een gefilterd antwoord retourneren
aan de gebruiker.
• Normaliseren van HTTP-verzoeken (zie 5.3.6); voordat een application-

level firewall een HTTP-verzoek valideert, zal deze het verzoek eerst
normaliseren. Hierdoor voorkomt men dat kwaadwillenden via
geëncodeerde karakters e.d. beveiligingsmechanismen omzeilen.
• Controle tegen bekende aanvalspatronen (zie 5.3.7); als laatste

‘redmiddel’ kan een application-level firewall een verzoek controleren op
bekende aanvalspatronen. Wanneer een HTTP-verzoek overeen komt met
een bekend patroon (bijvoorbeeld een bekend verzoek van een worm) dan
kan de application-level firewall dit verzoek blokkeren.
• Controle op HTTP-methoden (zie 5.3.8); hoewel HTTP vanuit de RFC

ondersteuning biedt voor een groot aantal verschillende HTTP-methoden,
gebruiken webapplicaties in de praktijk slechts twee van deze methoden
veelvuldig: GET en POST. De application-level firewall kan mogelijk
onveilige HTTP-methoden blokkeren.
• Controle op gebruikte HTTP-headers (zie 5.3.10); zowel HTTP-

verzoeken als HTTP-antwoorden kunnen beveiligingsproblemen opleveren
wanneer deze speciale HTTP-headers bevatten. Een application-level
firewall kan diepgaande filtering op deze headers toepassen.

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

Een belangrijke eigenschap van een application-level firewall is of deze een
positief of negatief beveiligingsbeleid implementeert. Een positief
beveiligingsbeleid is een beveiligingsbeleid waarbij de application-level firewall alle
verzoeken blokkeert, tenzij expliciet toegestaan. Bij een negatief
beveiligingsbeleid blokkeert de application-level firewall helemaal niets, tenzij
expliciet verboden. Application-level firewalls die een positief beveiligingsbeleid
hanteren (of in ieder geval daartoe de mogelijkheid bieden) krijgen vanuit het
oogpunt van beveiliging de voorkeur boven application-level firewalls die een
negatief beveiligingsbeleid implementeren.
Een positief beveiligingsbeleid werkt met een syntax waaraan een HTTP-verzoek
moet voldoen vanuit een vooropgestelde configuratie. De application-level firewall
blokkeert verzoeken die niet aan deze syntax voldoen. Op deze manier is de kans
klein dat kwaadwillenden nieuwe – onbekende – kwetsbaarheden kunnen
uitbuiten. Een negatief beveiligingsbeleid werkt op basis van aanvalspatronen
(handtekeningen van kwaadaardige verzoeken). Alleen wanneer een verzoek blijkt
te matchen met een aanvalspatroon zal de application-level firewall dit verzoek
blokkeren. Dit betekent in de praktijk dat de application-level firewall alleen
bekende aanvallen richting de webapplicatie zal blokkeren. Veel application-level
firewalls implementeren een positief beveiligingsbeleid en bieden de mogelijkheid
om verzoeken die op basis van het positieve beveiligingsbeleid zijn toegestaan,
als laatste controle ook nog eens tegen de verzameling van aanvalspatronen te
houden (negatief beveiligingsbeleid).
ACHTERGROND Application-level firewalls kennen veel benamingen. Het

artikel “Web Application Firewalls Primer” (INSECURE, 2006) geeft een overzicht
van 22 van deze benamingen. Enkele van de meest in het oogspringende zijn:
Web Application Firewall, Application Level Gateway, Web Application Proxy, Web
Intrusion Prevention System en Web Security Proxy. In dit document zullen we
echter de term Application-level firewall hanteren.
Een application-level firewall werkt, zoals al eerder werd beschreven, in veel

gevallen als een reverse proxy. Dit betekent dat de client nooit een rechtstreekse
verbinding kan opzetten met de webserver; zodra een client een webpagina
opvraagt ontstaan in ieder geval twee verbindingen op IP-niveau: één tussen de
client en de application-level firewall en één tussen de application-level firewall en
de webserver. Een webserver logt normaliter bij alle verzoeken die het krijgt te
verwerken ook het IP-adres van waaraf dit verzoek afkomstig is. In het geval men

gebruik maakt van een reverse proxy zal dit IP-adres dus altijd het IP-adres van
de application-level firewall zijn via welke de client een verbinding krijgt. Omdat
op deze manier waardevolle informatie verloren gaat, moet men een
configuratiewijziging doorvoeren op zowel de appliction-level firewall als de
webserver. Deze configuratiewijziging bestaat eruit dat de application-level
firewall het originele IP-adres van de client doorstuurt in een aparte HTTP-header
(bijvoorbeeld HTTP_ORIG_IP_ADDRESS) en de webserver niet het IP-adres van
de application-level firewall in het requestlog plaatst, maar het IP-adres uit de
eerder genoemde HTTP-header.
5.3.1.5 Voordelen
Één van de belangrijkste voordelen van de inzet van een application-level firewall
is dat deze bescherming kan bieden tegen bekende én nieuwe (0-day)
kwetsbaarheden. Door uit te gaan van een positief beveiligingsbeleid zal de
application-level firewall veel pogingen tot misbruik automatisch blokkeren,
aangezien deze werken op basis van bijvoorbeeld een groot aantal karakters,
vreemde karakters of speciale encodering. Op het moment dat leveranciers
nieuwe kwetsbaarheden bekend maken en patches ter beschikking stellen is de
noodzaak tot het installeren van deze patches wellicht iets minder dringend.
Zolang de application-level firewall verzoeken blokkeert die de kwetsbaarheid
uitbuiten, loopt de webserver/webapplicatie minder gevaar. Uiteraard is het nog
steeds van belang om de patches uiteindelijk te installeren, alleen is de periode
waarbinnen dit moet gebeuren mogelijk iets ruimer.
Daarnaast kan de inzet van een application-level firewall met een zeer strikt
positief beveiligingsbeleid, dwingen tot webapplicaties die voldoen aan strenge
vereisten op het gebied van beveiliging. Een strikt positief beveiligingsbeleid zorgt
er namelijk voor dat de application-level firewall veel verzoeken richting de
applicatie blokkeert zodra ze gebruik maken van vreemde karakters, vreemde
headers, lange strings, relatieve paden, etc… Op deze manier dwingt de
application-level firewall ontwikkelaars ertoe goed na te denken over de opbouw
van de applicatie. Uiteraard is het wel van belang dat systeemontwikkelaars op de
hoogte zijn van het standaard beveiligingsbeleid zodat zij weten aan welke
voorwaarden een webapplicatie moet voldoen om zonder problemen te kunnen
functioneren achter de application-level firewall.
OPMERKING Vrijwel alle application-level firewalls bieden mogelijkheden om

aparte policies te definiëren op URL-basis. Dat betekent dat in theorie elke
webapplicatie een apart beveiligingsbeleid kan hanteren. Dit kan echter leiden tot
een onoverzichtelijk geheel waarin zich beveiligingsproblemen voordoen. Het is
daarom aan te raden altijd te werken met een standaard positief
beveiligingsbeleid en hier alleen in specifieke gevallen een uitzondering op te
maken.
5.3.1.6 Voorbeelden
Application-level firewalls zijn in steeds grotere getale beschikbaar. Onderstaand
volgt – in alfabetische volgorde - een overzicht van enkele producten die veel van
de functionaliteiten uit dit hoofdstuk implementeren. Het bestuderen van

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

ACHTERGROND Het Web Application Security Consortium (WebAppSec)
biedt organisaties die de inzet van een application-level firewall overwegen een
(onafhankelijk) handvat via het document ‘Web Application Firewall Evaluation
Criteria’. In dit document is een verzameling algemene criteria opgenomen die
van belang zijn bij het selecteren van een web application firewall voor een
organisatie. Het document kunt u downloaden vanaf
http://www.webappsec.org/projects/wafec/
5.3.2 Voer inputvalidatie uit

Inputvalidatie is essentieel voor het afdoende kunnen beschermen van een
webapplicatie tegen een verscheidenheid aan aanvallen. Cross-site scripting
(5.2.2) en SQL injection (5.2.3) zijn bekende aanvallen die misbruik maken van
het ontbreken van gedegen inputvalidatie. Inputvalidatie moet plaatsvinden op
alle onderdelen van een HTTP-verzoek. Voordat inputvalidatie plaatsvindt op een
verzoek is het van belang dat het verzoek eerst genormaliseerd is (zie 5.3.6).
Bij inputvalidatie kan men denken aan de volgende maatregelen:
• Controle op lengte en type van invoer. Wanneer bijvoorbeeld

maximaal 20 karakters in een variabele passen moet de applicatie
controleren of de gebruiker niet meer dan 20 karakters heeft ingevuld.
Hierdoor voorkomt men bijvoorbeeld buffer overflows.
• Controle op karakters. De applicatie moet elke invoer controleren op de

aanwezigheid van speciale karakters. Bij SQL injection maken
kwaadwillenden bijvoorbeeld veel gebruik van quotes (‘) en dubbele
mintekens (‘--‘) om SQL-commando’s te kunnen injecteren. Deze
karakters horen veelal niet thuis in reguliere invoer en dient de applicatie
daarom uit te filteren.
• Controle op sleutelwoorden. Door invoer te controleren op de

aanwezigheid van specifieke sleutelwoorden voorkomt men veel gebruikte
aanvallen. Sleutelwoorden als ‘<script>’, ‘DELETE FROM’, ‘SELECT’,
‘INSERT’ en ‘DROP’ horen niet thuis in invoervelden, waardoor de
applicatie verzoeken waarin deze sleutelwoorden voorkomen vaak zonder
problemen kan blokkeren.
• Controle op lengte en type van attachments. Sommige websites

bieden de mogelijkheid om bestanden te uploaden. Denk hierbij aan online
fotoalbums e.d. Belangrijk is in dit geval te controleren of het type
attachment overeenkomt met het verwachte type (bijvoorbeeld JPG) en of
de grootte van het attachment geen grenzen overschrijdt. Hierdoor
voorkomt men dat bestanden van enkele honderden megabytes de
schijven van de webserver laten vollopen en extreem veel resources
(bandbreedte, CPU, etc…) gebruiken.

• Controle tegen een vooropgesteld XML-template. XML-berichten die
men uitwisselt via webservices zijn vrijwel altijd gebaseerd op XML-
templates. Deze XML-templates nemen vaak de vorm aan van een Web
Service Description Language (WSDL) bestand. Het WSDL-bestand
beschrijft welke namespaces de webservice gebruikt, welke methoden de
webservice ondersteunt, welke attributen de webservice verwacht (of
verplicht stelt) en hoe deze attributen moeten zijn opgebouwd. Door een
aangeboden XML-bericht te controleren tegen het XML-template, kan men
vaststellen of het XML-bericht voldoet aan datgene wat de webapplicatie
verwacht. Afwijkingen van het XML-template duiden mogelijk op een
poging tot misbruik.
Figuur 5-7 geeft een voorbeeld van een definitie uit een WSDL-bestand. In
dit voorbeeld is te zien dat de WSDL beschrijft welke data-typen de
applicatie verwacht en hoe vaak een bepaald type moet en mag
voorkomen in een ‘sequence’.
Figuur 5-7: definitie uit een WSDL-bestand
Alle bovenstaande controles dient men uit te voeren op alle onderdelen van het
HTTP-bericht. Hiertoe dient de applicatie het HTTP-bericht volledig te ontleden en
elk onderdeel apart te evalueren. Figuur 5-8 geeft een voorbeeld van een HTTP-
verzoek vanaf een client met daarin de onderdelen waarop de applicatie controles
kan uitvoeren.

Figuur 5-8: onderdelen van een HTTP-verzoek
Inputvalidatie past men in sommige gevallen al toe op de client. Zo kan men

bijvoorbeeld in webformulieren een maximale lengte van het invoerveld bepalen
(via het MAXLENGTH attribuut). Deze controles aan de clientkant voorkomen dat
reguliere gebruikers verkeerde invoer versturen. Het voorkomt echter niet dat
kwaadwillenden verkeerde invoer versturen. Het is immers eenvoudig om de
beperkingen van een formulier te omzeilen door buiten de webbrowser om een
verzoek richting de webapplicatie te versturen. Inputvalidatie via de browser kan
dus helpen om de invoer van een reguliere gebruiker te sturen maar mag nooit als
beveiligingsmiddel dienen.
OPMERKING Naast inputvalidatie (wat krijgen we binnen?) is ook outputvalidatie

(wat sturen we terug?) van belang. Paragraaf 5.3.4 gaat hiertoe met name in op
de vraag hoe de applicatie kan voorkomen dat deze onbedoeld informatie ontsluit
richting clients.
5.3.3 Maak (extern) gebruik van SSL-verbindingen

HTTP biedt standaard ondersteuning om een versleutelde verbinding op te zetten
tussen de client en server. Voor de versleuteling maakt HTTP gebruik van het
Secure Sockets Layer protocol (SSL) of de opvolger daarvan: het Transport Layer
Security (TLS) protocol. Door de verbinding richting de webapplicatie te
versleutelen middels SSL of TLS voorkomt men dat kwaadwillenden eenvoudig de
verkeersstromen tussen client en server kunnen inzien. Men moet zich bij het
gebruik van SSL en TLS wel beseffen dat het hier versleuteling op transportniveau
betreft. Op de server zorgt het webserverproces voor ontsleuteling van de
informatie waarna de webapplicatie met onversleutelde informatie aan de slag
gaat. Om informatie ook versleuteld op te slaan in bestanden en databases aan
serverzijde dient men aparte maatregelen te treffen (zie 5.3.12).

Bij de inzet van een application-level firewall handelt niet de webserver maar de
application-level firewall de SSL-verbinding af. Zodra de SSL-verbinding tot stand
is gekomen, zal de application-level firewall de verbinding doorproxien naar de
achterliggende webserver. De verbinding tussen de application-level firewall en de
achterliggende webserver hoeft niet per definitie op basis van SSL of TLS te
worden gerealiseerd. Aangezien deze laatste verbinding zich vrijwel altijd in een
vertrouwde en afgeschermde omgeving bevindt (de DMZ van de organisatie), kan
men er ook voor kiezen deze verbinding te baseren op het onversleutelde HTTP.
Het voordeel van een dergelijke aanpak is dat de achterliggende webserver niet
wordt belast met SSL-versleuteling en dat daarnaast de mogelijkheid bestaat om
het verkeer te laten bekijken door eventueel aanwezige Intrusion Detection
Systemen (IDS). Daar waar een IDS normaal gesproken het verkeer richting een
SSL-beveiligde webapplicatie niet kan monitoren, kan dit door de inzet van een
application-level firewall in combinatie met een HTTP-verbinding tussen de
application-level firewall en de webapplicatie plotseling wel. Zie hoofdstuk 9 voor
meer informatie over de inzet van een IDS. Figuur 5-9 illustreert het hierboven
beschreven concept.
Figuur 5-9: SSL/TLS naar HTTP-omzetting op de application-level firewall
Als een application-level firewall de SSL-verbinding termineert en op basis van

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

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

versleutelingsprotocollen voor (1) het uitwisselen van sleutels, (2) het
authenticeren van gebruiker en server en (3) het versleutelen van de gegevens.
Belangrijk is om voor elk van deze functionaliteiten een sterk protocol te kiezen.
De keuze voor een zwak protocol kan ertoe leiden dat kwaadwillenden de SSL-
beveiliging breken.
VOORBEELD Apache, een bekende webserver, biedt standaard de mogelijkheid

om alleen sterke protocollen toe te staan voor SSL. Door het opnemen van de
regel ‘SSLCipherSuite HIGH:MEDIUM’ in het Apache configuratiebestand dwingt
Apache af dat de webserver alleen sterkere protocollen ondersteunt. Wanneer een
gebruiker een verbinding opzet en verzoekt om het gebruik van een zwakker
protocol dan zal de webserver deze verbinding niet accepteren.
5.3.4 Voorkom het lekken van informatie

Het lekken van informatie richting een kwaadwillende moet men zoveel mogelijk
voorkomen. De volgende aanbevelingen beschrijven de belangrijkste manieren
waarop de applicatie dit kan voorkomen:
• Retourneer alleen standaard HTTP-headers. Alleen headers die voor

het functioneren van HTTP van belang zijn, dient men te retourneren aan
gebruikers (RFC 261612 voor HTTP/1.1, RFC 194513 voor HTTP/1.0). Alle
overige HTTP-headers kan de applicatie in de regel zonder gevolgen uit
een HTTP-antwoord verwijderen (zie ook 5.3.9).
• Beperk informatie in de standaard HTTP-headers. Het is voor een

client bijvoorbeeld niet van belang om te weten welk type webserver
antwoord heeft gegeven op het HTTP-verzoek. Daarom kan men ervoor
kiezen om bijvoorbeeld de “Server”-header uit het antwoord te
verwijderen of deze te voorzien van een nietszeggende inhoud als “Server:
WebServer 1.0”.
12
13

• Voorkom het lekken van gedetailleerde foutmeldingen. Op het
moment dat er zich een probleem voordoet binnen een webapplicatie zal
de webserver veelal een statuscode “500 Internal Server Error”
retourneren. Deze statuscode wijst erop dat er zich een exceptie heeft
voorgedaan en dat de webserver mogelijk gevoelige informatie m.b.t. de
applicatielogica openbaart (databasenamen, gebruikersnamen,
bestandsnamen, interne IP-adressen, etc…). In het geval een application-
level firewall een dergelijke statuscode detecteert kan deze een standaard
foutmelding (bijvoorbeeld “Er heeft zich een onbekende fout voorgedaan.”)
retourneren aan de client en het gedetailleerde antwoord van de
webserver negeren. Ook webservers zelf bieden functionaliteit om
standaard meldingen te laten genereren a.d.h. van specifieke statuscodes.
OPMERKING HTTP kent een groot aantal verschillende codes. Bij elke
webapplicatie dient men zich af te vragen welke codes legitiem voor deze
webapplicatie zijn en welke niet. Zo kunnen ook codes als “501 Not
Implemented”, “405 Method Not Allowed” en “414 Request-URI Too Long”
ongewenst zijn en de kwaadwillende helpen in het footprinten van de
applicatie. Bedenk goed hoe de webapplicatie met deze verschillende
codes om moet gaan en welk antwoord de webapplicatie (of de
application-level firewall) in een dergelijk geval moet retourneren aan de
eindgebruiker.
• Voorkom de aanwezigheid van commentaarregels in scripts.

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

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

encodering bestaat eruit dat de client niet het karakter, maar de
hexadecimale waarde van het karakter in de URL plaatst. Een spatie komt
op deze manier als ‘%20’ in een URL terecht en een komma als ‘%2C’.
URL encodering kan men voor alle mogelijke karakters uitvoeren. Hierdoor
kan het gebeuren dat een kwaadwillende speciale karakters of
karakterreeksen niet direct opneemt in een URL, maar deze encodeert. Op
deze manier hoopt de kwaadwillende controles te omzeilen. Daarom is het
belangrijk dat een applicatie een HTTP-verzoek eerst decodeert alvorens
hiermee aan de slag te gaan.
• HTML decodering; naast decodering van de URL moet de applicatie ook

HTML decoderen. HTML biedt namelijk de mogelijkheid om in HTML
karakters te encoderen zoals ampersand tekens (‘&’), groter-dan
tekens (‘>’), kleiner-dan tekens (‘<’), etc… De applicatie moet deze
geencodeerde karakters decoderen alvorens met de verwerking van de
invoer te starten.
• Pad normalisatie; pad normalisatie betekent dat een applicatie alle

relatieve padverwijzingen uit een URL filtert en een absolute URL
samenstelt. Dit betekent dat de applicatie relatieve pad verwijzingen als
‘/./’ en ‘/../’ uitfiltert. Hierdoor verandert de URL
‘/a/b/c/.././../d/script.html’ in ‘/a/d/script.html’. Door deze normalisatie
uit te voeren voorkomt men ook dat een aanroep buiten de webroot treedt
(een verzoek naar ‘/a/b/../../../../script.html’ is bijvoorbeeld niet
toegestaan omdat de uiteindelijke – genormaliseerde – directory buiten de
webroot valt). Ook invoervelden waarvan een webapplicatie gebruikt
maakt, dient de applicatie te controleren op genormaliseerde paden.
• Converteren backslashes naar forward slashes; het web maakt

gebruik van forward slashes (‘/’) in plaats van backslashes (‘\’). De
aanwezigheid van backslashes kan duiden op een poging tot misbruik van
een op Windows-gebaseerd systeem. Aangezien backslashes niet
thuishoren in HTTP-verzoeken moet de applicatie deze backslashes
‘vertalen’ naar forward slashes.
5.3.6 Sta alleen benodigde HTTP-methoden toe

HTTP ondersteunt verschillende methoden (zie tabel 5-1). In de praktijk gebruikt
een webapplicatie alleen de methoden GET en POST. Voor veel scripts en objecten
op een webserver geldt zelfs dat alleen de GET-methode benodigd is. Methoden
anders dan GET en POST zijn vrijwel nooit benodigd en vormen alleen een extra
beveiligingsrisico. Niet benodigde methoden kan men daarom via configuratie van
de webserver of via de application-level firewall blokkeren.
Methode Omschrijving
CONNECT Een methode die aangeeft dat een tussenliggende proxy het
verzoek niet mag aanpassen c.q. onderzoeken en simpelweg moet

Methode Omschrijving
doorsturen
DELETE Verwijderen van het object op de webserver onder de gedefinieerde
URL
GET Opvragen van informatie betreffende het object
HEAD Idem aan GET met het verschil dat bij HEAD de webserver niet de
body van het bericht retourneert
OPTIONS Biedt de mogelijkheid om te achterhalen welke HTTP-methoden een
specifiek object ondersteunt
POST Versturen van gegevens richting de webserver om verwerkt te
worden door het object
PUT Plaatsen van een nieuw object op de webserver onder de
gedefinieerde URL
TRACE Bedoeld om te zien hoe het HTTP-verzoek terecht komt op de
webserver en daarom vooral geschikt voor het uitvoeren testen en
het verkrijgen van diagnostische informatie
Tabel 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 deze
mogelijkheid ook. In onderstaande afbeelding is een Lotus Domino website te zien
die alleen de methoden GET, HEAD, POST, OPTIONS en TRACE toestaat. Zie voor
meer informatie over het configureren van deze methoden onder Lotus Domino,
zie: http://www-1.ibm.com/support/docview.wss?uid=swg21201202

5.3.7 Sta beperkt bestandsextensies toe
De bestandsextensie is meestal het gedeelte achter de laatste ‘.’ in een URL. De
bestandsextensie bepaalt welk type bestand de client bevraagt. Naast standaard
bestandsextensies (.html, .htm, .jpeg, .jpg, etc…) ondersteunen veel webservers
ook minder generieke bestandsextensies (bijvoorbeeld .aspx voor Microsoft .NET
webservers, .jar voor Websphere servers, etc…). Vaak ondersteunt een webserver
meer extensies dan daadwerkelijk benodigd is voor het goed functioneren van de
webapplicatie. In dit soort gevallen is het aan te raden om deze extensies
onschadelijk te maken omdat elke extensie een mogelijke nieuwe ingang is tot
misbruik van de webserver. Niet gebruikte bestandsextensies kunnen op de
volgende manieren onschadelijk worden gemaakt:
• Door het uitvoeren van een controle op de bestandsextensie op

een application-level firewall. Een application-level firewall kan een
HTTP-verzoek ontleden en bepalen welke bestandsextensie is
aangeroepen. Alleen wanneer de bestandsextensie voldoet aan een de lijst
met standaard toegestane extensies zal deze het verzoek doorlaten
richting de webapplicatie. In alle andere gevallen blokkeert de application-
level firewall het verzoek. Zelfs wanneer de webserver een bepaalde
gevaarlijke bestandsextensie ondersteunt (bijvoorbeeld .exe) zal de
kwaadwillende er, bij een strikte configuratie van de application-level
firewall, niet in slagen om bestanden met deze extensie aan te roepen op
de webserver.
• Door het hardenen van de webserver. Na installatie van een

webserver ondersteunt deze out-of-the-box een verzameling extensies
waarvan de webapplicatie zeer waarschijnlijk maar een gedeelte
daadwerkelijk gebruikt. Door de configuratie van de server te veranderen
(bijvoorbeeld het verwijderen van ISAPI-filters op een Microsoft IIS-
server) voorkomt men dat de webserver bepaalde extensies ‘begrijpt’ en
verwerkt.
Bij het gebruik van een application-level firewall hoeft men het blokkeren van
bestandsextensies slechts op te nemen in het standaard beveiligingsbeleid waarna
de application-level firewall dit voor elke webapplicatie bekrachtigt. Kiest men
ervoor om bestandsextensies te blokkeren door het hardenen van webservers,
dan zal men elke webserver (en mogelijk ook elke virtuele website op deze
webserver) apart moeten configureren.
VOORBEELD Een voorbeeld van een zeer gevaarlijke bestandsextensie bij

uitstek is de .exe bestandsextensie op Windows-servers. Op het moment dat een
kwaadwillende erin slaagt om bijvoorbeeld de cmd.exe executable aan te roepen
op de webserver kan deze allerlei commando’s uit laten voeren op de webserver.
Door de .exe-extensie op voorhand te blokkeren richting webservers
(webapplicaties mogen deze extensie nooit gebruiken), voorkomt men misbruik
op deze manier. De alom bekende Nimda-worm maakt bijvoorbeeld misbruik van
de cmd.exe executable (via een verzoek als ‘GET

/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 Controleer verzoeken tegen bekende aanvalspatronen

Application-level firewalls bieden doorgaans de mogelijkheid om HTTP-verzoeken
te controleren tegen een lijst van bekende aanvalspatronen. Deze vorm van
negatief beveiligingsbeleid past men in de regel alleen toe als laatste controle op
een HTTP-verzoek. Op het moment dat een applicatie het HTTP-verzoek
controleert tegen de lijst met aanvalspatronen moeten de syntactische controles
vanuit het positieve beveiligingsbeleid al zijn uitgevoerd zonder (negatief)
resultaat. Door te controleren tegen bekende aanvalspatronen voorkomt men dat
aanvallen die syntactisch volledig in orde zijn toch de webapplicatie bereiken.
Een negatief beveiligingsbeleid vereist wel dat de application-level firewall continu

wordt voorzien de laatste signatures. Verzuimt men deze nieuwe signatures
beschikbaar te stellen aan de application-level firewall dan zal ook het negatieve
beveiligingsbeleid geen beveiliging kunnen bieden tegen recente exploits, wormen
en virussen.
5.3.9 Controleer de inhoud van HTTP-headers

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

doorlaten;
• De header uit het HTTP-bericht verwijderen en het gefilterde bericht
doorsturen;
• Het HTTP-bericht in zijn geheel blokkeren.
Onderstaand volgen enkele voorbeelden van mogelijk misbruik via HTTP-headers

en de oplossing die filtering van deze headers in dit geval biedt.
Voorbeeld #1: ongewenste authenticatie

Een bepaalde webapplicatie is alleen bedoeld voor gebruik door anonieme
gebruikers. Dit betekent dat gebruikers zich in geen enkel geval hoeven te
authenticeren tegen de webapplicatie. De anonieme gebruiker heeft minimale
rechten op het bestandssysteem van de webserver. Op de webserver is ook een
‘administrator’-account aanwezig dat uiteraard veel uitgebreidere rechten heeft
dan de anonieme gebruiker. Een kwaadwillende wil proberen om een verbinding
met de webapplicatie te krijgen om vervolgens te gaan werken onder het

‘administrator’-account in plaats van het anonieme account. Hiertoe voegt de
kwaadwillende een ‘Authorization’ header toe aan het HTTP-verzoek:
Authorization: Basic YWRtaW46YWRtaW4=
Hoewel de webserver geen authenticatie afdwingt accepteert deze de

Authorization-header wel en zal de webserver proberen om de gebruiker te
authenticeren op basis van de meegestuurde authenticatiegegevens
(admin:admin in dit geval). Indien dit succesvol is, krijgt de kwaadwillende de
beschikking over een verbinding op basis van uitgebreidere toegangsrechten.
In de application-level firewall configureert men dat het hier gaat om een publieke
webapplicatie zonder authenticatie. Daarom filtert de application-level firewall
HTTP-headers die bedoeld zijn voor authenticatie uit het bericht, waardoor het
gefilterde verzoek zonder de ‘Authorization’ header terecht komt bij de
webapplicatie. De kwaadwillende slaagt er hierdoor niet in om zich tegen de
webserver authenticeren en onder het ‘administrator’-account een verbinding met
de webapplicatie op te zetten.
Voorbeeld #2: ongewenst lekken van informatie

Een webserver lekt via HTTP-headers allerlei informatie over de gebruikte
software op de webserver. De application-level firewall zorgt ervoor dat deze
informatie niet terecht komt bij de eindgebruiker door bepaalde HTTP-headers uit
te filteren en de inhoud van andere HTTP-headers te wijzigen. Figuur 5-5 geeft
een voorbeeld van de werking van een application-level firewall als het gaat om
het uitvoeren van controles op HTTP-headers.
Figuur 5-10: HTTP-header filtering
In het voorbeeld van figuur 5-10 heeft de application-level firewall een aantal
HTTP-headers uit het antwoord van de webserver verwijderd (‘X-Aspnet-version’
en ‘Accept-Ranges’) en heeft het daarnaast de inhoud van de HTTP-header
‘Server’ aangepast. Het resultaat is een gefilterd antwoord richting de client
zonder daarbij ongewenst informatie over de webserver te lekken.

5.3.10 Controleer het gebruik van cookies
Cookies vormen een veelgebruikt middel om statusinformatie vast te leggen. Een
webserver verstuurt een cookie richting de client via een ‘Set-Cookie’ HTTP
responseheader; een client biedt een cookie aan een webapplicatie aan via een
‘Cookie’ HTTP requestheader. Kwaadwillenden kunnen het cookiemechanisme
misbruiken om bijvoorbeeld sessies te ‘spoofen’ om op die manier
ongeautoriseerd toegang te verkrijgen tot een webapplicatie. Door aan de
serverkant actief te controleren op het gebruik van deze cookies kan men de kans
op misbruik hiervan verminderen. Een application-level firewall kan wederom een
rol spelen in het blokkeren van verzoeken met ongeldige cookies. Een mogelijk
proces rondom de controle op cookies is afgebeeld in figuur 5-11.
Figuur 5-11: registratie van cookies
In figuur 5-11 start het proces met het uitgeven van een cookie door de
webserver via een ‘Set-Cookie’ HTTP-header (1). De application-level firewall
registreert de uitgifte van dit cookie in een eigen database (2). Naast de inhoud
van het cookie registreert de application-level firewall bijvoorbeeld ook een IP-
adres waarnaar deze het cookie zal versturen en de webapplicatie die het cookie
heeft uitgegeven. De application-level firewall retourneert het cookie aan de client
(3) waarna de client het cookie zal opslaan in zijn geheugen of op de harde schijf
(afhankelijk van het type cookie). Vervolgens tracht een kwaadwillende ditzelfde
cookie te gebruiken om ook toegang tot de webapplicatie te verkrijgen (4). De
kwaadwillende heeft bijvoorbeeld opgemerkt dat het sessie-ID voorspelbaar is en
probeert daarom, via een ‘gespoofed’ sessie-ID in een cookie, een sessie met de
webserver op te bouwen. De application-level firewall controleert vervolgens de
inhoud van het aangeboden cookie tegen de database met uitgegeven cookies

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

Een solide updatemechanisme is essentieel om voldoende beschermd te zijn tegen
bekende beveiligingsproblemen in software. Deze aanbeveling vond u eerder al
terug in hoofdstuk 4 (Platformbeveiliging). Een updatemechanisme voor alle
applicatieplatformen, applicaties, databases, etc… die bovenop dit platform
draaien is minstens zo belangrijk. Zorg er daarom voor dat de verschillende
stappen uit patch management (vaststellen, beoordelen, verkrijgen, testen,
uitrollen en monitoren) ook zijn ingeregeld voor dit soort applicaties.
5.3.12 Schakel ‘directory listings’ uit

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

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

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

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

• Het afvangen van excepties;
• De mogelijkheid tot het genereren van buffer overflows;
• De aanwezigheid van type mismatches;
• Gebruik van potentieel gevaarlijke functies;
• Juiste toepassing van input validatie;
• Datastromen door een webapplicatie.
5.3.15 Pas alle maatregelen op alle applicaties toe

Zorg ervoor dat alle voorgaande maatregelen worden toegepast op alle in gebruik
zijnde webapplicaties binnen de organisatie. De maatregelen moeten dus, waar
mogelijk, van toepassing zijn op zowel intern ontwikkelde applicaties als extern
aangekochte applicaties.

6 IDENTITEIT- EN TOEGANGSBEHEER
Identiteitbeheer en toegangsbeheer zijn onlosmakelijk met elkaar verbonden.

Toegangsbeheer is niet mogelijk zonder dat een correcte invulling is gegeven aan
identiteitbeheer. Dit hoofdstuk behandelt daarom deze twee lagen uit het RBW
gezamenlijk.
6.1 Inleiding
Van Dale definieert een identiteit als ‘iets wat eigen is aan een persoon’. In meer
technische zin bestaat een identiteit uit een identifier, een authenticator en een
profiel. Figuur 6-1 beschrijft deze onderdelen van een identiteit.
Figuur 6-1: opbouw van een identiteit
De identifier representeert de gebruiker of de applicatie. Hierbij kan men denken

aan een gebruikersnaam of een persoonsnummer als identifier. De identifier is
uniek binnen een bepaald domein: zo is een gebruikersnaam (identifier) uniek
binnen een applicatie (domein) en is een persoonsnummer (identifier) uniek
binnen Nederland (domein). Daarnaast is de identifier over het algemeen niet
onderhevig aan een lifecycle. De gebruikersnaam van een medewerker voor een
bepaalde applicatie wijzigt bijvoorbeeld vrijwel nooit en het persoonsnummer dat
een inwoner van Nederland bij geboorte krijgt verandert nooit meer tot zijn/haar
dood.

De authenticator is datgene dat een persoon gebruikt om de identifier te
‘bewijzen’. Om te bewijzen dat een gebruikersnaam een valide identifier is, moet
een gebruiker ook zijn wachtwoord (authenticator) opgeven. Om te bewijzen dat
het persoonsnummer inderdaad een bepaalde persoon toebehoort, moet deze
persoon zijn paspoort (authenticator) tonen. Authenticatoren verschillen veelal in
sterkte. Zo vormt een wachtwoord van drie letters een stuk minder sterke
authenticator dan een certificaat dat is opgeslagen op een smartcard. Daarnaast
dient men de authenticator beveiligd op te slaan. Een paspoort hoort normaal
gesproken in de kluis, een wachtwoord in het hoofd (en in de kluis). Doordat een
gebruiker zijn wachtwoord bijvoorbeeld kan opschrijven op een ‘geeltje’ is deze
authenticator een stuk minder sterk. Tot slot is een authenticator onderhevig aan
een lifecycle. Een wachtwoord zou men bijvoorbeeld elke maand moeten
veranderen, een paspoort moet men elke 10 jaar vernieuwen.
Het profiel bevat tot slot bepaalde kenmerken (attributen, rollen en data) die
toebehoren aan de identiteit. Hierbij moet men denken aan de rol die een
medewerker vervult (bijvoorbeeld manager) of de datum waarop een medewerker
in dienst is getreden. De gegevens uit het profiel slaan applicaties veelal in
verschillende repositories op (bijvoorbeeld in een personeelssysteem en op het
intranet). Daarnaast kunnen de gegevens uit het profiel regelmatig wijzigen en is
de informatie uit het profiel vaak privacy gevoelig.
De identifier en/of het profiel bepaalt vervolgens welke autorisaties een gebruiker
krijgt binnen de webapplicatie. Er bestaan verschillende autorisatiemechanismen
om deze autorisatie op te baseren. Enkele van de meest bekende
autorisatiemechanismen zijn:
• Role-based Access Control; toegang tot (onderdelen van) de

webapplicatie is afgeschermd door het toekennen van rollen aan
gebruikers en het toekennen van rechten aan rollen.
• Rule-based Access Control; beschrijft specifieke regels waaraan een

gebruiker moet voldoen (bijvoorbeeld attribuut x >= 1) voordat deze
toegang krijgt op basis van gegevens uit zijn/haar profiel. Bij rule-based
access control hoeft het controlerende mechanisme alleen attributen van
een gebruiker te controleren. Daarom kan rule-based access control
performancevoordelen geven boven control mechanismen waarbij de
server bijvoorbeeld een grote groep moet nalopen op een mogelijk
lidmaatschap van een bepaalde gebruiker.
• Mandatory Access Control (MAC); bij dit model baseert men de

autorisaties op classificaties of labels aan een object gecombineerd met
het classificatieniveau of labels van de gebruiker.
• Discretionary Access Control (DAC); toegang tot bestanden wordt

bepaald door de rechten die een gebruiker heeft toegewezen gekregen. De
eigenaar van het bestand kan vervolgens zelf weer rechten uitdelen aan
andere gebruikers.

OPMERKING Onder identiteitbeheer verstaat dit hoofdstuk alle activiteiten die
nodig zijn in het kader van identiteiten. Het gaat hier dus om het toevoegen,
verwijderen en wijzigen van identiteiten maar zeker ook om het authenticeren van
identiteiten op basis van hun authenticator. Op eenzelfde manier betreft
toegangsbeheer alle activiteiten die applicaties moeten uitvoeren om de
autorisaties rondom deze webapplicatie in te regelen en af te dwingen (runtime
uitdelen van autorisaties op basis van een autorisatietabel).
Deze paragraaf gaat in op mogelijke kwetsbaarheden en bedreigingen die zich

voor kunnen doen op het gebied van identiteiten toegangsbeheer.
6.2.1 Foutieve implementatie van authenticatie en

sessiemanagement
Zoals eerder in dit document al werd beschreven, kent HTTP standaard geen
mechanisme om de status van een sessie te behouden. Wanneer een gebruiker
zich heeft geauthenticeerd tot een webapplicatie, is het uiteraard wenselijk dat de
webapplicatie onthoudt dat de gebruiker zich inmiddels succesvol heeft
geauthenticeerd. Zou dit niet zo zijn dan zou de gebruiker zich bij elk volgend
verzoek opnieuw moeten authenticeren en gaat de historie van zijn acties binnen
de webapplicatie verloren.
Om de sessie tussen een gebruiker en een webapplicatie te ‘fixeren’ staan de

systeemontwikkelaar ruwweg de volgende mechanismen ter beschikking:
• Sessie-fixatie op basis van argumenten in de URL; hierbij zorgt de

webapplicatie ervoor dat de client het sessie-ID als argument toevoegt aan
elk verzoek richting de webapplicatie. Hierdoor ontstaat een URL als
http://www.eenwebsite.nl/aanroep.asp?sessieid=123.
• Sessie-fixatie op basis van verborgen velden; invoervelden in HTML

kunnen zowel zichtbaar als onzichtbaar zijn. Webapplicaties maken vaak
dankbaar gebruik van onzichtbare velden om informatie over de sessie in
op te slaan. Elke keer wanneer de gebruiker informatie uit zichtbare
velden verstuurt naar de webapplicatie verstuurt deze daarmee in dit
geval ook de informatie uit de onzichtbare velden. Onzichtbaar is hierbij
echter een relatief begrip. De velden zijn niet direct zichtbaar vanuit een
webbrowser. Onzichtbare velden maakt men echter op eenvoudige wijze
zichtbaar door de broncode van een pagina te bekijken of via een sniffer
de uitwisseling van gegevens te bestuderen. Kiest een ontwikkelaar ervoor
om de velden van een formulieren via een GET-actie te versturen naar de
webapplicatie dan verschijnen de ‘verborgen’ velden automatisch als
argument in de URL (zie vorige punt). Kiest de ontwikkelaar ervoor om de
inhoud van een formulier via een POST-actie te versturen naar de
webapplicatie dan geeft de webbrowser deze waarden door via de body

van het bericht.
• Sessie-fixatie op basis van cookies; sessie-fixatie op basis van cookies is

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

Onderstaande lijst beschrijft twee van deze problemen:
• Een kwaadwillende ontdekt dat een webapplicatie gebruik maakt van het
verborgen veld genaamd ‘userid’. Bij het initieel benaderen van de
webapplicatie is de inhoud van dit verborgen veld leeg. Nadat de
kwaadwillende probeert in te loggen met een standaard gebruikersnaam
en wachtwoord blijkt dit niet te lukken en het ‘userid’ veld blijft leeg. De
kwaadwillende probeert vervolgens om het inlogscherm te omzeilen en
een verzoek aan de webapplicatie te richten waarin hij het verborgen veld
‘userid’ de waarde ‘Blackhat’ geeft. Nadat hij dit gedaan heeft krijgt hij de
melding ‘Welkom Blackhat’ en kan hij gebruik maken van de webapplicatie
zonder zich geauthenticeerd te hebben. De webapplicatie blijkt in dit geval
volledig te vertrouwen op de waarde van het verborgen veld ‘userid’.
• Een reguliere gebruiker van een webapplicatie logt in op de webapplicatie

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

een webapplicatie. Niet alleen het fixeren van een sessie kan lastig blijken. Ook
het uiteindelijk ‘ontmantelen’ van een sessie kan problemen met zich

meebrengen. De volgende vraag doet zich in dit kader voor: hoe zorgen we
ervoor dat de webapplicatie een sessie uiteindelijk ook weer afsluit? Sessies
kunnen immers niet oneindig lang open blijven staan. De aanwezigheid van een
sessie zorgt aan de ene kant voor onnodig resourcegebruik op de server (de
server moet alle sessies op één of andere manier administreren en hiervoor
geheugen reserveren) en daarnaast voor een beveiligingslek. Hoe meer sessies
een webserver op enig moment open heeft staan, hoe groter de kans dat een
kwaadwillende erin slaagt één van deze sessies te kraken. En ook: hoe langer een
sessie actief blijft, hoe langer eventueel onderschepte sessiegegevens bruikbaar
blijven voor een kwaadwillende (denk bijvoorbeeld aan misbruik van een cookie
via een internetcafé).
6.2.2 Foutieve implementatie van toegangsbeheer

Vergelijkbare problemen als bij authenticatie en sessiemanagement (vorige
paragraaf) kunnen zich ook voordoen bij toegangsbeheer. Toegangsbeheer volgt
op authenticatie en houdt in dat de webapplicatie controleert of een gebruiker
gerechtigd is om bepaalde acties uit te voeren. Denk hierbij aan het al dan niet
mogen uitvoeren van een bepaalde transactie of het al dan niet mogen bekijken
van een specifieke webpagina.
Het volgende voorbeeld illustreert een mogelijk probleem dat zich kan voordoen
bij toegangsbeheer:
Een webapplicatie kent de pagina ‘/protected/insidernews.aspx’ waartoe alleen

geregistreerde gebruikers toegang hebben. Binnen de applicatie is vastgelegd dat
voor alle verzoeken naar ‘/protected/*’ een speciale autorisatievlag benodigd is.
De volgende voorbeelden illustreren implementatiefouten die ertoe kunnen leiden
dat de webapplicatie deze autorisaties niet goed afhandelt:
• De applicatie voert geen normalisatie van het verzoek vanaf de gebruiker

uit (zie 5.3.5). Een kwaadwillende kan dit misbruiken door geen verzoek te
doen naar ‘/protected/insidernews.aspx’ maar naar
‘/./protected/insidernews.aspx’. Logischer wijs zijn deze twee
verzoeken identiek. Toch past de webapplicatie bij het laatste verzoek
geen autorisaties toe aangezien het verzoek niet start met ‘/protected/’.
De kwaadwillende kan op deze manier de autorisaties op de betreffende
directory eenvoudig omzeilen.
• De applicatie baseert de toegang tot de beveiligde directory op basis van

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

• Een kwetsbaar script binnen de webapplicatie voert geen goede
inputvalidatie uit. Daardoor kan de kwaadwillende het ‘beveiligde’ script
uitvoeren door een speciale invoer mee te geven aan dit kwetsbare script.
Door een verzoek te doen naar
‘/scripts/runscript.aspx?script=/protected/insidernews.aspx’ kan
de kwaadwillende de autorisatie omzeilen en het script alsnog uitvoeren.
Bovenstaande voorbeelden dienen slechts ter illustratie. Het geeft aan dat er vele
implementatiefouten binnen een webapplicatie kunnen bestaan die ertoe kunnen
leiden dat kwaadwillenden autorisaties omzeilen.
6.2.3 Onveilige authenticatiemechanismen

Niet alle authenticatiemechanismen die een webapplicatie kan gebruiken, zijn
even veilig. Een belangrijk gevaar dat verbonden is aan het gebruik van
authenticatiemechanismen is de mogelijkheid tot het achterhalen c.q.
onderscheppen hiervan. Op het moment dat een kwaadwillende erin slaagt om
authenticatiegegevens te achterhalen, kan deze zich er vervolgens zelf mee gaan
authenticeren tegen de webapplicatie. Voor het onderscheppen van
authenticatiegegevens staan de kwaadwillende een aantal mogelijkheden ter
beschikking:
• Phishing: hierbij achterhaalt een kwaadwillende authenticatiegegevens

(en mogelijke andere informatie) door gebruikers te verleiden om naar een
namaak website te surfen en daar deze (authenticatie-)gegevens in te
laten vullen.
• Social engineering: social engineering bestaat eruit

authenticatiegegevens te achterhalen door gebruikers over te halen deze
te onthullen. Social engineering speelt ook een belangrijke rol bij phishing.
Social engineering is echter breder (het kan hier bijvoorbeeld ook gaan om
het opbellen van personen om op die manier authenticatie- of andere
waardevolle gegevens te achterhalen).
• Sniffing: bij sniffing probeert een kwaadwillende door het opvangen van
netwerkverkeer authenticatiegegevens te verkrijgen. Door deze passieve
vorm van aanvallen zal een gebruiker normaal gesproken niet merken dat
zijn authenticatiegegevens zijn onderschept.
Ook authenticatiemechanismen die op het oog veilig lijken hoeven niet per
definitie veilig te zijn. Neem bijvoorbeeld authenticatie op basis van het ‘basic
authentication’ mechanisme, een standaard – en veel gebruikt – mechanisme
binnen HTTP om gebruikers te authenticeren. Een typische HTTP-header bij
gebruik van ‘basic authentication’ ziet er als volgt uit:
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Op het eerste oog lijkt het erop dat de authenticatiegegevens versleuteld zijn
aangezien deze niet direct uit de inhoud van de HTTP-header af te leiden zijn. Het
blijkt echter dat ‘basic authentication’ gebruik maakt van ‘base64 encoding’.
Strings die middels base64 geencodeerd zijn, kan men ook eenvoudig weer
decoderen. Figuur 6-2 toont dat het zeer eenvoudig is om via een simpele tool
(base64 decoder) een gebruikersnaam en een wachtwoord uit deze string te
‘toveren’. Weet een kwaadwillende erin te slagen deze gegevens te sniffen, dan is
het voor hem zeer eenvoudig om de inhoud ervan te misbruiken.
Figuur 6-2: base64 encoding/decoding
ACHTERGROND In juli 2006 verscheen voor het eerst een grootschalige

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

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

Discrepantie tussen het authenticatiemechanisme en het beveiligingsbeleid kan
ook gedurende de levenscyclus van een applicatie ontstaan. Op het moment dat
een nieuwe applicatie het levenslicht ziet, voert de organisatie bijvoorbeeld een
risicoanalyse uit waaruit voortvloeit dat de applicatie voldoende beschermd is op
basis van gebruikersnaam/wachtwoord authenticatie. De applicatie groeit
vervolgens een aantal jaren door waarbij de organisatie steeds meer
functionaliteiten en data aan de webapplicatie toevoegt. Wat men nalaat is
regelmatig opnieuw een risicoanalyse uit te voeren op de applicatie. Hierdoor
blijkt op een gegeven moment het gebruikte authenticatiemechanisme niet meer
te voldoen voor de gestaag doorgegroeide applicatie.
6.2.5 Het wiel opnieuw uitvinden

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

ook aanwezig als verschillende webapplicaties op verschillende manieren ontsloten
worden en gebruik maken van verschillende protocollen en technologieën. Stel
bijvoorbeeld dat een organisatie start met een webapplicatie die gebruikers
benaderen via hun webbrowser (op basis van HTML). De webapplicatie is
beschermd middels een gebruikersnaam en een wachtwoord. Vervolgens besluit
de organisatie om delen van de webapplicatie ook beschikbaar te stellen via een
webservice (op basis van XML). Ook deze webservice wil men beschermen op
basis van een gebruikersnaam en een wachtwoord. In veel gevallen zal men voor
deze webservice een nieuw authenticatieproces inrichten. Dit terwijl het grootste
gedeelte van het bestaande authenticatiemechanisme in veel gevallen herbruikt
kan worden.
6.2.6 Incompatibele authenticatiemechanismen

Wanneer men het wiel voor elke webapplicatie opnieuw uitvindt (6.2.5), bestaat
de kans dat webapplicaties een groot aantal verschillende
authenticatiemechanismen implementeren om deze te beschermen. Deze
incompatibiliteit kan tot verschillende problemen leiden. Enkele van de meest
voorkomende zijn:
• Bij het ‘in elkaar schuiven’ van verschillende applicaties (bijvoorbeeld

verschillende bestaande webapplicaties achter een nieuw te ontwikkelen
portaal) ontstaan problemen omdat de verschillende
authenticatiemechanismen ervoor zorgen dat gebruikers op elke
afzonderlijke applicatie opnieuw moeten inloggen. Het is, met andere

woorden, niet mogelijk om via één account toegang te verkrijgen tot de
afzonderlijke webapplicaties (Single Sign-On).
ACHTERGROND Dit probleem doet zich bijvoorbeeld ook voor

wanneer twee voorheen afzonderlijke organisaties intensiever met elkaar
moeten samenwerken of fuseren. Het is niet ondenkbaar dat beide
organisaties vergelijkbare systemen bezitten die naar elkaar toe moeten
groeien en uiteindelijk in elkaar moeten opgaan. Gebruikers die voorheen
klant waren van beide organisaties bezitten hierdoor twee identiteiten. Het
bereiken van SSO-functionaliteit is in dit soort gevallen vaak alleen
mogelijk via complexe synchronisatiemechanismen tussen de twee
applicaties of via een “big-bang” aanpak (het lanceren van een volledig
nieuw systeem als vervanging voor de twee oudere systemen).
• De beheermechanismen rondom het ene authenticatiemechanisme zijn

niet toepasbaar op het andere authenticatiemechanisme. Gevolg hiervan is
dat men rondom elk authenticatiemechanisme een apart beheerproces
(inclusief achterliggende techniek) moet inrichten voor gebruikersbeheer,
rollenbeheer, etc…
• Het is niet mogelijk een goed profiel worden op te bouwen van een
gebruiker. Wanneer persoon A account A1 in applicatie 1 krijgt en account
A2 in applicatie 2, zijn deze twee identiteiten veelal niet met elkaar te
combineren of moeten hiervoor onevenredig veel activiteiten worden
ondernomen. Hierdoor kan men geen geheel omvattend profiel van deze
persoon opmaken en moeten applicaties overlappende gegevens ieder
apart bijhouden (denk hierbij bijvoorbeeld aan een adreswijziging die elke
applicatie afzonderlijk moet doorvoeren).
6.3 Aanbevelingen
In deze paragraaf komen maatregelen aan bod die een organisatie kan
implementeren om de gevaren en bedreigingen uit de vorige paragraaf het hoofd
te bieden.
6.3.1 Bepaal de plek van identiteiten toegangsbeheer

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

Figuur 6-3: verdeling identiteiten toegangsbeheer applicatie/centraal
Het overzicht van figuur 6-3 toont vijf verschillende applicaties (A-E) die allen een
andere invulling hebben gegeven aan identiteitbeheer en toegangsbeheer. Bij de
eerste applicatie (applicatie A) is alles op dit gebied in de applicatie zelf
ingebouwd. De applicatie kan geheel zelfstandig functioneren maar maakt geen
gebruik van bestaande mechanismen. Applicatie E daarentegen heeft totaal geen
ingebouwde logica voor identiteiten toegangsbeheer. Deze applicatie vertrouwt
volledig op centraal belegde functionaliteiten op dit gebied. Voordeel van de
aanpak van applicatie E is dat programmeurs zich tijdens het ontwikkelen van de
applicatie volledig hebben kunnen richten op de functionaliteit van de applicatie.
Zij hoeven zich niet druk te maken om zaken als authenticatie en autorisatie. Ook
tussenvormen zijn uiteraard mogelijk. Zo neemt applicatie D alle zaken op het
gebied van identiteitbeheer centraal af, maar geeft het een eigen invulling aan
toegangsbeheer. M.a.w.: het vaststellen van de identiteit vertrouwt de applicatie
toe aan een centraal mechanisme, maar het uitdelen van rechten aan deze
identiteit is voorbehouden aan de applicatie.
6.3.2 Overweeg de invoering van I&AM tooling

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

6.3.2.1 Omschrijving
I&AM tooling kan bijvoorbeeld de authenticatie uitvoeren voor een verzameling
van webapplicaties. Net als bij de application-level firewall kan deze tooling
werken op basis van een reverse proxy oplossing of via een plug-in op de
webserver. Figuur 6-4 beschrijft een voorbeeld van een mogelijke implementatie
van I&AM tooling (op basis van een reverse proxy oplossing).
Figuur 6-4: mogelijke opstelling centrale authenticatie en autorisatie
In figuur 6-4 vindt authenticatie en autorisatie buiten de applicatie plaats via een
centrale server. Deze server ondersteunt meerdere authenticatiemechanismen en
heeft bovendien verschillende servers tot zijn beschikking voor het controleren
van authenticatiegegevens en autorisaties. Voor de achterliggende webapplicaties
(applicatie A, B en C) is het gehele authenticatie- en autorisatieproces geheel
transparant. De webapplicatie krijgt een identifier aangeleverd en eventueel een
aantal autorisaties en attributen die van toepassing zijn op de identifier. De
manier waarop dit plaatsvindt, is afhankelijk van de gekozen strategie voor
beveiligingsintegratie (hoofdstuk 8). Vanuit het oogpunt van de webapplicatie is
het zeer eenvoudig om het authenticatiemechanisme te wijzigen: of de centrale
server nu authenticeert op basis van een gebruikersnaam/wachtwoord combinatie
of op basis van een digitaal certificaat maakt voor de webapplicatie niet uit
aangezien deze alleen werkt op basis van een identifier en dus
‘authenticatoronafhankelijk’ is.

6.3.2.2 Voordelen
Een belangrijk voordeel van het gebruik van I&AM tooling is dat de complexiteit
van het authenticeren en autoriseren van gebruikers uit de webapplicatie wordt
getrokken. Hierdoor vermindert de complexiteit van de webapplicatie en kunnen
ontwikkelaars zich in het geheel richten op het verwerken van functionaliteit in de
webapplicatie. Dit betekent dat de ontwikkeling van webapplicaties sneller zal
kunnen verlopen en een bewezen oplossing de authenticatie en autorisatie van
gebruikers afhandelt.
Door daarnaast de authenticatie los te trekken van de webapplicatie, is het

eenvoudiger om in de toekomst andere authenticatoren in te zetten voor het
beveiligen van de webapplicatie. Start men bijvoorbeeld met een webapplicatie
die beveiliging vereist op basis van een gebruikersnaam/wachtwoord en blijkt dit
later niet meer voldoende te zijn (i.v.m. de classificering van de data die de
webapplicatie aanbiedt), dan is het redelijk eenvoudig om de gebruikte
authenticator te wijzigen. Hiertoe voert men wijzigingen door in de I&AM tooling
en hoeft de achterliggende webapplicatie hier in principe niets van te merken.
Ook de integratie van verschillende afzonderlijke webapplicaties achter één

portaal verloopt een stuk eenvoudiger na de introductie van I&AM tooling. Door
één ‘master’-domein te creëren (bijvoorbeeld sso.eenwebsite.nl), kan de I&AM
tooling de gebruiker eenmaal tegen dit ‘master’-domein authenticeren en de
gebruiker vervolgens toegang geven tot een verscheidenheid aan webapplicaties.
De I&AM tooling speelt de inloggegevens van de gebruiker hierbij door aan de
achterliggende webapplicatie (Single Sign-On). Eventueel kan de I&AM tooling
verschillende mechanismen gebruiken voor het doorspelen van deze gegevens
aan verschillende achterliggende webapplicaties; hierdoor is de impact voor deze
webapplicaties minimaal. Ook de implementatie van Single Sign-Out (zie 6.3.5)
wordt op deze manier een stuk eenvoudiger.
6.3.2.3 Voorbeelden
Er zijn verschillende producten op de markt die services op het gebied van
identiteiten toegangsbeheer voor webapplicaties bieden. Onderstaand vindt u
een – alfabetisch – overzicht van producten die (geheel of gedeeltelijk) invulling
geven aan de functionaliteiten zoals deze in dit hoofdstuk worden beschreven:
• Entrust GetAccess;
• eTrust Siteminder;
• IBM Tivoli Access Manager (voorheen IBM Policy Director);
• Oblix NetPoint;
• RSA Cleartrust.
6.3.3 Maak een gefundeerde keuze voor authenticatiemechanisme

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

beste past bij de betreffende applicatie. Figuur 6-5 geeft een overzicht van enkele
authenticatiemechanismen.
Iets dat je weet
-Wachtwoord
-Passphrase
-PIN-code
Iets dat je hebt
-Token
-Smartcard
-Mobiele telefoon
Iets dat je bent
- Biometrische
kenmerken
Figuur 6-5: Overzicht van authenticatiemechanismen en voorbeelden14
Authenticatie kan men baseren op verschillende ‘factoren’. Een factor beschrijft op

welke manier een gebruiker zich moet authenticeren; dit kan zijn op basis van:
• Iets dat de gebruiker weet (bijvoorbeeld een wachtwoord of PIN-code);

• Iets dat de gebruiker heeft (bijvoorbeeld een token of smartcard);
• Iets dat de gebruiker is (bijvoorbeeld een vingerafdruk).
Bij webapplicaties ligt het gebruik van de eerste twee factoren (iets dat de
gebruiker weet of heeft) het meest voor de hand. Gebruik van biometrische
kenmerken voor authenticatie tot webapplicaties kan zeer complex en kostbaar
zijn en is nog geen gemeengoed.
Om de kans op het omzeilen van het authenticatiemechanisme te voorkomen, is

het gangbaar om minimaal 2 verschillende factoren te combineren (“2-factor
14
Fotoverantwoording:
iPhone: Dylan Parker; token: P^2 (via flickr.com); creditcard: Cheon Fong Liew (liewCF.com); iris en
vingerafdruk: stockfoto, rechten voorbehouden; handtekening: GOVCERT.NL; mond: Julia Freeman-Woolpert

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

Bij het authenticeren van gebruikers besteedt men over het algemeen veel
aandacht aan het inloggen van gebruikers. Wat men echter vaak vergeet is dat
gebruikers op een gegeven moment ook weer de kans moeten krijgen om uit te
loggen. Tijdens het uitloggen van een gebruiker wordt zijn/haar sessie onklaar
gemaakt en kan een kwaadwillende met eventuele onderschepte sessiegegevens
geen verbinding meer opzetten.
OPMERKING Uitloggen is ook een belangrijk aandachtspunt bij de implementatie

van Single Sign-On (SSO) mechanismen. Op het moment dat een gebruiker
aangeeft uit te willen loggen dient op dat moment een Single Sign-Out plaats te
vinden waarbij het mechanisme de authenticatie richting alle betrokken systemen
weer ongedaan maakt.
Verder is het zaak aandacht te besteden aan de idle time per sessie. Hoe lang
mag een gebruiker verbonden (geauthenticeerd) blijven als er geen activiteit
vanaf de gebruiker meer afkomt? Het is altijd aan te raden om een zodanige idle
timeout in te stellen dat gebruikers automatisch worden uitgelogd op het moment
dat zij geen gebruik meer (lijken te) maken van de webapplicatie. Op deze manier
vermindert men bijvoorbeeld het risico dat een kwaadwillende een webapplicatie
ongeautoriseerd vanuit een internetcafé kan benaderen doordat een vorige
gebruiker vergeten is uit te loggen. Daarnaast minimaliseert deze aanpak het
gebruik van resources op de webserver.
6.3.5 Zorg voor uniforme en flexibele authenticatiemechanismen

Zoals in paragraaf 6.2.5 al werd beschreven is het van belang dat applicaties
zoveel mogelijk gebruik maken van bestaande authenticatiemechanismen en niet
“het wiel opnieuw uitvinden”. Om dit te kunnen bereiken dient het
authenticatiemechanisme ingebouwd te kunnen worden in verschillende
technologieën en protocollen. Om dit te bereiken is het belangrijk rekening te
houden met de volgende overwegingen:
• Zorg ervoor dat gebruikersgegevens zoveel mogelijk in dezelfde

dataverzamelingen terecht komen. Creëer geen aparte databases met
gebruikers voor verschillende applicaties maar consolideer deze zoveel
mogelijk in één database. Hierdoor vermindert de beheerlast, voorkomt
men dat authenticatiemechanismen gerepliceerd en gesynchroniseerd
dienen te worden en verhoogt men de mogelijkheid tot de invoering van
Single Sign-On (SSO) en Single Sign-Out.
• Zorg ervoor dat ontwikkelde authenticatiemechismen eenvoudig

ingebouwd kunnen worden in verschillende technologieën en protocollen.

Hierbij is ook een rol weg gelegd voor eventueel ingezette I&AM tooling;
deze tooling moet eenvoudig overweg kunnen gaan met zowel HTML- als
XML-applicaties zonder dat daarvoor grote inspanningen benodigd zijn.
Denk hierbij bijvoorbeeld aan de implementatie van authenticatie op basis
van digitale (X.509-)certificaten: wanneer men dit gehele proces heeft
ingericht voor een webapplicatie op basis van HTML, moet het gehele
authenticatiemechanisme eenvoudig te porteren zijn naar een webservice
op basis van XML.
• Wees erop voorbereid dat aankomende technologieën eenvoudig kunnen

worden ingepast. Denk hierbij aan zaken als Federated Identity, SAML,
WS-Trust, etc…
ACHTERGROND De SAML-standaard is een relatief nieuwe standaard

die staat voor Secure Assertion Markup Language. De standaard definieert
een raamwerk voor het uitwisselen van beveiligingsinformatie tussen
verschillende (online) organisaties. Via SAML kunnen deze organisaties op
basis van XML ‘assertions’ aanmaken, opvragen en uitwisselen. Hierdoor
kan op een gegeven moment een vorm van inter-organisationele Single
Sign-On ontstaan: een gebruiker authenticeert zich bij organisatie A
waarna organisatie A ‘assertions’ beschikbaar stelt aan andere organisaties
die hierdoor niet opnieuw de gebruiker hoeven te authenticeren.

7 VERTROUWELIJKHEID EN
ONWEERLEGBAARHEID
Vertrouwelijkheid en onweerlegbaarheid zijn twee zaken die nauw aan elkaar

verbonden zijn. In het geval men gebruik maakt van asymmetrische versleuteling
(verschillende sleutels voor versleuteling en ontsleuteling), dient het publieke deel
van de sleutel voor versleuteling (vertrouwelijkheid) van gegevens en het privé-
deel van de sleutel voor ontsleuteling hiervan en het plaatsen van digitale
handtekeningen (onweerlegbaarheid/onloochenbaarheid). Dit hoofdstuk gaat
dieper in op de begrippen vertrouwelijkheid en onweerlegbaarheid in het kader
van webapplicaties.
7.1 Inleiding
De laag “Vertrouwelijkheid en onweerlegbaarheid” vormt de laatste schakel (laag)

in het contact tussen een client en een webapplicatie. Deze laag is met name
sterk afhankelijk van de inrichting van identiteitbeheer. Voor het kunnen
versleutelen van gegevens en het vaststellen van onweerlegbaarheid is het
namelijk van belang dat er wederzijdse authenticatie heeft plaatsgevonden. Dit
hoofdstuk gaat eerst in op kwetsbaarheden en bedreigingen op dit gebied om
vervolgens een aantal aanbevelingen te beschrijven.
De belangrijkste kwetsbaarheden en bedreigingen op het gebied van

vertrouwelijkheid en onweerlegbaarheid zijn de twee tegenpolen van deze
begrippen: lekken van informatie en weerlegbaarheid. De komende twee
paragrafen beschrijven deze begrippen in meer detail.
7.2.1 Lekken van informatie

Van lekken van informatie is in ieder geval sprake wanneer vertrouwelijke
informatie onbedoeld terecht komt bij ongeautoriseerde personen. Het lekken van
informatie kan men ook nauwer definiëren: het onnodig verstrekken van
informatie. Dit hoeft dus niet per se vertrouwelijke informatie te zijn. De volgende
voorbeelden schetsen een aantal gevallen waarin de applicatie onnodig informatie
verstrekt (zie ook hoofdstuk 5):
• Een webserver toont de gebruikte versies van software en plug-ins;

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

Zaken zoals hierboven beschreven, zijn redelijk basaal en kwamen al eerder aan
de orde in de voorgaande hoofdstukken. Waar dit hoofdstuk zich op concentreert
is het lekken van gevoelige informatie richting ongeautoriseerde personen. Dit kan
bijvoorbeeld gebeuren op het moment dat:
• Een kwaadwillende erin slaagt vertrouwelijke gegevens uit de database

van de webapplicatie op te halen;
• Een kwaadwillende erin slaagt bestanden met vertrouwelijke informatie
(bijvoorbeeld Word-documenten en tekstbestanden) op de webserver te
benaderen;
• Een kwaadwillende erin slaagt bestanden met vertrouwelijke informatie uit
de backoffice te benaderen terwijl deze bestanden niet bedoeld zijn voor
ontsluiting via de webapplicatie.
7.2.2 Weerlegbaarheid
Er is sprake van weerlegbaarheid op het moment dat de applicatie geen
mogelijkheden biedt om belangrijke zaken rondom een transactie te bewijzen. De
volgende zaken vallen onder de weerlegbaarheid van een transactie:
• De bron van een transactie; een zendende partij kan ontkennen dat een
bepaald bericht van hem/haar afkomstig is.
• Het tijdstip van een transactie; een zendende of ontvangende partij
kan ontkennen dat een transactie op een bepaald tijdstip heeft
plaatsgevonden.
• De ontvangst van een transactie; een ontvangende partij kan
ontkennen dat deze een bepaalde transactie heeft ontvangen.
• De inhoud van een transactie (integriteit); een zendende of
ontvangende partij kan ontkennen dat een transactie een bepaalde inhoud
bevatte. Een klassiek voorbeeld hiervan is een bedrag dat zich in een
transactie bevindt. Het is belangrijk dat onweerlegbaar is welk bedrag zich
in een transactie bevindt.
7.3 Aanbevelingen
De komende paragrafen beschrijven aanbevelingen die ervoor moeten zorgen dat

bij transacties via webapplicaties geen gegevens uitlekken en dat daarnaast
zender en ontvanger niet kunnen twisten over het feit dat deze transacties
hebben plaatsgevonden.
7.3.1 Versleutel vertrouwelijke informatie

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

loopt de organisatie het risico dat deze informatie op één-of-andere manier in
handen van kwaadwillenden komt. Daarom is het aan te raden om vertrouwelijke
informatie op te slaan in versleutelde vorm.
Er zijn een groot aantal standaard bibliotheken beschikbaar die een ontwikkelaar
van een webapplicatie kan gebruiken om versleuteling van gegevens te bereiken.
Het is aan te raden dergelijke standaard bibliotheken te gebruiken boven eigen
ontwikkelde bibliotheken om versleuteling toe te passen. Deze standaard
bibliotheken zijn veelal ver uitontwikkeld, zijn door de internetgemeenschap
uitgebreid onderzocht en beproefd en bieden een maximale performance.
Bovenop (of in plaats van) transportversleuteling via SSL/TLS kan men er ook
voor kiezen om specifieke onderdelen van het bericht te versleutelen. Hiermee
voorkomt men dat een kwaadwillende via een man-in-the-middle aanval de
SSL/TLS-sessie onderbreekt en daarmee toegang krijgt tot de inhoud van HTML-
en XML-berichten. Voor het versleutelen van specifieke onderdelen uit een XML-
bericht bestaan inmiddels al een aantal standaarden; voor HTML-berichten is dat
niet het geval. De XML-Encryption standaard is een voorbeeld van een standaard
die men kan toepassen om versleuteling van gegevens in een XML-bestand te
bereiken. Via deze standaard is het mogelijk om een gedeelte van het XML-bericht
te versleutelen en sleutelinformatie te versturen.
ACHTERGROND Meer informatie over het versleutelen van gegevens in XML

kunt u terugvinden in de ‘WS-Security Core Specification’ van de Organization for
the Advancement of Structured Information Standard (OASIS). Dit document kunt
u hier downloaden: http://www.oasis-open.org/committees/download.php/
16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
Het versleutelen van onderdelen van een bericht kan ook van nut zijn bij
architecturen waarbij de webapplicatie niet direct communiceert met de
eindgebruiker maar via een message broker. Een message broker ontvangt
berichten van verschllende bronnen en routeert het bericht uiteindelijk naar de
juiste eindbestemming. Door onderdelen van het bericht apart te versleutelen
voorkomt men dat deze message broker inzage krijgt in mogelijk vertrouwelijke
gegevens. Figuur 7-1 geeft deze situatie weer. In de situatie van figuur 7-1
wisselen een client en een server informatie uit via een broker. De informatie
betreft een drietal velden: A, B en C. De communicatieverbindingen tussen client-
broker en broker-server realiseert men op basis van SSL/TLS waardoor
transportversleuteling ontstaat. Client en server hebben vastgesteld dat voor de
velden A en B versleuteling op basis van SSL/TLS voldoende is. De waarde van
veld C is echter zeer vertrouwelijk. Het is niet de bedoeling dat de broker inzicht
krijgt in de waarde van dit veld. Aangezien de broker de SSL-sessie met de client
termineert is versleuteling van SSL/TLS voor het beschermen van de inhoud van
veld C in dit geval niet voldoende. Daarom versleutelt de client de inhoud van veld
C nog eens extra door gebruik van XML-Encryption. De broker kan hierdoor wel de
inhoud van de velden A en B bekijken maar niet van veld C omdat deze niet
beschikt over de benodigde sleutel (de privé-sleutel in dit geval).

Vertrouwelijkheid van de informatie in veld C is hierdoor bewerkstelligd, ondanks
de tussenkomst van een (minder vertrouwde) message broker.
Figuur 7-1: versleuteling van gegevens
7.3.2 Versleutel cookies

Cookies bevatten doorgaans informatie over de sessie die een gebruiker heeft met
een bepaalde webapplicatie en mogelijk ook authenticatiegegevens. Door tijdens
het bezoek aan een webapplicatie continu het cookie aan de webapplicatie te
tonen, weet de webapplicatie dat een gebruiker al geauthenticeerd is en dat dit
niet opnieuw hoeft te gebeuren. Misbruik van informatie uit de cookies kan ertoe
leiden dat kwaadwillenden zich ongeautoriseerd toegang verschaffen tot een
webapplicatie. Dit kan gebeuren op het moment dat een kwaadwillende een
cookie weet op te vangen (door het netwerkverkeer te sniffen) of op het moment
dat deze een achtergebleven cookie op een werkstation in handen krijgt
(bijvoorbeeld in een internetcafé). Veel van deze problemen met cookies kan men
voorkomen door het cookie te versleutelen of door extra controles uit te voeren
op cookies (zie hoofdstuk 5). Het versleutelen van het cookie dient te gebeuren
met een sleutel die alleen bekend is bij de webapplicatie. De gebruiker kan
hierdoor vrijwel niets met het cookie (hij beschikt immers niet over de geheime
sleutel) behalve dan dit cookie aan te bieden aan de webapplicatie. De gebruiker
(en ook de kwaadwillende) kan de inhoud van het cookie niet inzien.
Door het versleutelen van cookies voorkomt men dat kwaadwillenden de inhoud
ervan kunnen lezen en aanpassen. Hierdoor zijn vertrouwelijkheid en integriteit
van de inhoud van het cookie geborgd. Wat echter een restrisico blijft, is dat een
kwaadwillende zich op basis van het cookie toegang verschaft tot de webapplicatie
(authentication replay). Om dit restrisico te vermijden kan de webapplicatie

werken met dynamische sleutels. Door bijvoorbeeld elke 2 minuten een nieuwe
sleutel te generen blijft het cookie op het werkstation ook maar 2 minuten geldig.
Zolang de gebruiker ingelogd blijft op de webapplicatie ontvangt deze elke 2
minuten een nieuw cookie; de inhoud (na ontsleutelen) van het cookie blijft hierbij
wellicht onveranderd maar door de keuze voor een andere sleutel is de
versleutelde inhoud (de uiteindelijke inhoud van het cookie die de eindgebruiker
te zien krijgt en moet aanbieden) verschillend. Op het moment dat een
kwaadwillende een dergelijk cookie in handen krijgt is de geldigheid van de sleutel
naar alle waarschijnlijkheid al verlopen en kan deze niets meer met dit cookie
aanvangen.
7.3.3 Maak gebruik van digitale handtekeningen

In sommige gevallen kan het benodigd zijn dat transacties – en de inhoud
hiervan - onweerlegbaar zijn. In dit soort gevallen ontkomt men er vrijwel niet
aan om te gaan werken met digitale handtekeningen. Bij een digitale
handtekening maakt de ondertekenaar gebruik van een ‘geheim’ dat alleen bij
deze gebruiker bekend is. Dit kan bijvoorbeeld een code of een privé-sleutel zijn.
De eerste implementatie van een digitale handtekening maakte gebruik van Public
Key Cryptography (PKI) en werd bedacht door Diffie en Hellman.
VOORBEELD Het volgende voorbeeld illustreert het gebruik van een digitale
handtekening. In het voorbeeld wil gebruiker A een bericht sturen aan gebruiker B
en onweerlegbaarheid bereiken. Hiertoe voert gebruiker A de volgende stappen
uit:
1. Gebruiker A berekent een hash over het bericht. Alle relevante gegevens uit
het bericht maken onderdeel uit van deze hash: belangrijke waarden, tijdstip,
etc…
2. Gebruiker A versleutelt de hash met zijn privé-sleutel.
3. Gebruiker A versleutelt het volledige bericht met de publieke sleutel van
gebruiker B.
4. Gebruiker A verstuurt het bericht naar gebruiker B.
Doordat het bericht versleutelt is met de publieke sleutel van gebruiker B is dit
bericht alleen door gebruiker B te lezen. Bij ontvangst van het bericht voert
gebruiker B de volgende stappen uit:
1. Gebruiker B ontsleutelt het bericht via zijn privé-sleutel.
2. Gebruiker B berekent een hash over het ontsleutelde bericht (‘hash A’).
3. Gebruiker B ontsleutelt de hash van de gebruiker via de publieke sleutel van
gebruiker A (‘hash B’).
4. Gebruiker B vergelijkt ‘hash A’ met ‘hash B’. Alleen wanneer deze hashes
overeenkomen weet gebruiker B zeker dat de integriteit van het bericht in
orde is en dat de inhoud daadwerkelijk afkomstig is van gebruiker A.
Er bestaan verschillende mogelijkheden om een digitale handtekening te

implementeren. Voor een belangrijk gedeelte is de technische oplossing ook
afhankelijk van het gebruikte ‘transportprotocol’: XML of HTML. Voor XML bestaan
inmiddels standaarden waarmee men een digitale handtekening op de inhoud van

een bericht (of delen daarvan) kan plaatsen; XML Signature is een voorbeeld van
een dergelijke standaard. Figuur 7-2 bevat een voorbeeld van een XML bestand
dat (geheel) ondertekend is met een digitale handtekening.
Figuur 7-2: voorbeeld digitale handtekening
Bij op HTML-gebaseerde applicaties moet men over het algemeen meer

inspanningen verrichten om gebruik te kunnen maken van digitale
handtekeningen. Er bestaan geen standaard mechanismen om dit te bereiken. In
veel gevallen zal een plug-in in de webbrowser benodigd zijn om functionaliteiten
op het gebied van digitale handtekeningen te kunnen implementeren.

8 BEVEILIGINGSINTEGRATIE
De beveiligingsintegratielaag is vooral bedoeld om functionaliteit te bieden. Het is

daarnaast ook een virtuele laag: er bestaan geen specifieke producten die
beveiligingsintegratie met beveiligingscomponenten (en beveiligingscomponenten
onderling) mogelijk maken. Het is een ingebouwde functionaliteit van
beveiligingscomponenten die webapplicaties (en andere beveiligingscomponenten)
kunnen aanroepen c.q. raadplegen. Dit hoofdstuk gaat in op de manier waarop
beveiligingsintegratie tussen webapplicaties en beveiligingsapplicaties (en
beveiligingscomponenten onderling) tot stand kan komen.
8.1 Inleiding
Beveiligingsintegratie houdt in dat een webapplicatie de beschikking krijgt over

informatie die aanwezig is binnen de beveiligingscomponenten. Hierdoor kan een
beveiligingsoplossing als generiek onderdeel binnen een webomgeving fungeren
en hoeven ontwikkelaars de betreffende functionaliteit niet in elke applicatie
afzonderlijk in te bouwen. Een voorbeeld hiervan is het scheiden van
functionaliteiten op het gebied van autorisatie- en toegangsbeheer tussen de
webapplicatie en generieke beveiligingscomponenten (zie hoofdstuk 6, figuur 6-
2). Enkele voorbeelden van beveiligingsintegratie die een webapplicatie kan
wensen zijn:
• Een webapplicatie wil de gebruikersnaam achterhalen van een gebruiker

die door de I&AM tooling is geauthenticeerd;
• Een webapplicatie wil de rollen c.q. autorisaties achterhalen van een
gebruiker die door de I&AM tooling is geauthenticeerd (en mogelijk
geautoriseerd);
• De I&AM tooling wil de certificaatgegevens achterhalen van een SSL-sessie
die de application-level firewall met de eindgebruiker heeft;
• Een webapplicatie wil een load balancer opdracht geven geen verkeer
meer richting een specifieke webserver te versturen (omdat er
bijvoorbeeld onderhoud op deze webserver gaat plaatsvinden).
De volgende paragraaf beschrijft een aantal mechanismen dat een

beveiligingscomponent veelal biedt om deze integratie tot stand te brengen.
8.2 Mechanismen
In hoofdlijnen bestaan er twee mechanismen om beveiligingsintegratie te

bereiken: passief en actief. Passieve beveiligingsintegratie betekent dat een
beveiligingscomponent bepaalde informatie bij voorbaat aanbiedt aan de
achterliggende webapplicatie zonder dat de webapplicatie hier specifiek om
vraagt. De webapplicatie hoeft deze informatie niet te gebruiken. Actieve

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

Passieve beveiligingsintegratie is op verschillende manieren te implementeren.
Drie generieke stappen doorlopen gebruikers, beveiligingscomponent en applicatie
altijd bij passieve beveiligingsintegratie:
1. De gebruiker maakt contact met het beveiligingscomponent;

2. De beveiligingscomponent voert zijn beveiligingsacties uit;
3. De gegevens die uit deze beveiligingsactie naar voren komen stelt de
beveiligingscomponent bij voorbaat beschikbaar voor achterliggende
componenten. De mogelijkheid bestaat dat achterliggende componenten
geen gebruik maken van deze informatie.
Figuur 8-1: passieve beveiligingsintegratie
Figuur 8-1 toont drie mogelijke implementaties van bovenstaande stappen:
1. Opslaan van gegevens in een tussenliggende datastore; hierbij plaatst

het beveiligingscomponent beveiligingsgegevens (bijvoorbeeld
authenticatie- of autorisatiegegevens) in een database. Achterliggende
applicaties die deze gegevens willen gebruiken, kunnen de gegevens
vervolgens weer uit de database halen. In feite is deze manier van
beveiligingsintegratie een combinatie van passieve (beveilgingscomponent
plaatst de gegevens altijd in de database) en actieve integratie (de

achterliggende applicatie moet de gegevens zelf weer actief uit de
database halen).
2. Doorgeven van waarden via een querystring; bij deze oplossing plakt het
beveiligingscomponent belangrijke gegevens achter de gebruikte URL in de
vorm van een querystring. De achterliggende applicatie kan de gegevens
uit de querystring vervolgens gebruiken in de eigen programmalogica.
3. Doorgeven van waarden via HTTP-headers; de informatie die het
beveiligingscomponent in voorgaand punt verwerkt in een querystring kan
dit beveiligingscomponent ook aanbieden via HTTP-headers. De
achterliggende applicatie kan besluiten om de gegevens uit deze headers
op te halen en te verwerken in de eigen programmalogica.
VOORBEELD Passieve beveiligingsintegratie kan van groot nut zijn wanneer men
bijvoorbeeld in zeer korte tijd Single Sign-On moet inregelen voor twee
(voorheen) volledig losstaande applicaties. Applicatie A dwingt authenticatie af op
basis van een eigen inlogformulier en Applicatie B dwingt authenticatie af op basis
van basic authentication. Door I&AM tooling voor deze applicaties in te zetten en
enkele specifieke wijzigingen in deze tooling door te voeren, bereikt men dit
relatief eenvoudig zonder hiervoor ook maar één wijziging door te voeren in de
twee applicaties. De I&AM tooling voert hiertoe de volgende acties uit:
1. De I&AM tooling authenticeert een gebruiker die een verbinding wil opzetten
met Applicatie A of Applicatie B.
2. Nadat de gebruiker zich succesvol heeft geauthenticeerd bepaalt de I&AM
tooling met welke applicatie de gebruiker wil verbinden (Applicatie A of
Applicatie B).
3. Wanneer de gebruiker wil verbinden met Applicatie A construeert de I&AM
tooling een POST-request waarin het de gebruikersnaam en het wachtwoord
van de gebruiker verwerkt. De I&AM tooling simuleert hiermee het inloggen
van het formulier op de webapplicatie en het klikken op de knop ‘Inloggen’.
Hierdoor lijkt het dat de gebruiker zelf inlogt op de webapplicatie maar is het
de I&AM tooling die dit voor de gebruiker realiseert.
4. Wanneer de gebruiker wil verbinden met Applicatie B construeert de I&AM
tooling een “Authorization” HTTP-header waarin het de gebruikersnaam en het
wachtwoord van de gebruiker in base64 encoding opneemt. Deze HTTP-header
voegt de I&AM tooling toe aan elk verzoek dat de gebruiker verstuurt naar
Applicatie B. Applicatie B merkt hierdoor niet dat niet de gebruiker maar de
I&AM tooling inlogt op de applicatie. Wederom biedt de I&AM tooling hierdoor
de mogelijkheid om de bestaande applicatie te blijven gebruiken zonder
hiervoor aanpassingen door te voeren.
5. Gedurende de sessie die de gebruiker heeft met de I&AM tooling kan de
gebruiker zonder problemen ‘switchen’ tussen de verschillende applicaties
zonder dat hij/zij zich daarvoor opnieuw moet authenticeren. Voor de
gebruiker kan het dus om één applicatie lijken te gaan terwijl hij/zij in
werkelijkheid wordt bediend door twee losstaande applicaties.

8.2.2 Actieve beveiligingsintegratie
Bij actieve beveiligingsintegratie bevraagt een webapplicatie actief een
beveiligingscomponent om informatie over uitgevoerde beveiligingsacties te
achterhalen óf om een nieuwe beveiligingsactie uit te laten voeren. Bij actieve
beveiligingsintegratie hoeft het beveiligingscomponent dus niet inline (d.w.z.
tussen de client en achterliggende applicatie) geplaatst te zijn. Figuur 8-2 schetst
deze twee alternatieven.
Figuur 8-2: actieve beveiligingsintegratie
Bij inline plaatsing zal het beveiligingscomponent het verzoek van de gebruiker
valideren en, indien akkoord bevonden, doorsturen naar de achterliggende
webapplicatie. Bij het doorsturen van verzoek zal het beveiligingscomponent geen
gegevens over de sessie met de gebruiker naar de applicatie meesturen (zoals bij
passieve beveiligingsintegratie). Bij het ontvangen van het verzoek zal de
applicatie zelf actief contact gaan leggen met het beveiligingscomponent om
informatie over uitgevoerde beveiligingsacties door het beveiligingscomponent te
achterhalen.
Ook wanneer het beveiligingscomponent niet inline geplaatst is, kan de

achterliggende webapplicatie actief contact leggen met het beveiligingscomponent
om beveiligingsinformatie op te vragen. Zo kan de webapplicatie bijvoorbeeld aan
het beveiligingscomponent vragen om een bepaalde gebruikersnaam/wachtwoord
combinatie te valideren en het resultaat te retourneren.
Een voor de hand liggende methode voor het bereiken van actieve
beveiligingsintegratie is de toepassing van webservices.

VOORBEELD F5, leverancier van netwerk- en beveiligigingsapparatuur, biedt
mogelijkheden tot het bevragen van deze apparatuur via een mechanisme
genaamd iControl. iControl is een Application Programming Interface (API) op
basis van SOAP/XML (webservices) en CORBA. Vooralsnog kan de iControl
functionaliteit voornamelijk worden aangeroepen om load balancing functionaliteit
in F5-componenten aan te sturen en te bevragen.
8.3 Aanbevelingen
Met de invoer van elk nieuw beveiligingscomponent dient men zich af te vragen:
hoe integreer ik dit component binnen mijn omgeving? Belangrijk is vast te
stellen:
• Welke services de omgeving van het component zal afnemen;

• Op welke manier de omgeving deze services zal afnemen (actief of passief,
welke protocollen).
De vereisten die uit deze overwegingen naar voren komen dienen vervolgens als
input voor een productieselectie. Door bij elk nieuw of te vervangen
beveiligingscomponent deze vereisten in ogenschouw te nemen, ontstaat een
omgeving van nauw verwante componenten die moeiteloos met elkaar kunnen
integreren.

9 MONITORING, AUDITING EN ALERTING
9.1 Inleiding
Monitoring, auditing en alerting zijn van toepassing op elke laag van het RBW.
Voor zowel monitoring, auditing als alerting geldt dat de verschillende
technologieën die zich binnen de RBW-lagen bevinden hieraan een invulling
geven. Heel belangrijk is dat men monitoring, auditing en alerting niet los op elke
laag beschouwt, maar dat (causale) verbanden kunnen worden gelegd tussen de
afzonderlijke logging- en monitoringmechanismen. Dit soort denken is m.n. van
belang door de steeds verder voortschrijdende ketenintegratie waarbij
componenten aan elkaar gekoppeld worden en de sterkte van de keten bepaald
wordt door de zwakste schakel. Ketenintegratie vereist tevens dat verschillende
competenties binnen een organisatie (bijvoorbeeld netwerkbeheer en
systeemontwikkeling) nauwer met elkaar gaan samenwerken.
Vindt er bijvoorbeeld een aanval plaats op een applicatie binnen het RBW, dan
dient men de logging events op de verschillende lagen van het RBW te kunnen
combineren om zodoende een duidelijk aanvalspatroon (met bijbehorend
bewijsmateriaal) te kunnen verzamelen. Door op deze manier te werk te gaan,
kan men bijvoorbeeld bepalen welke actie op een specifiek tijdstip werd
uitgevoerd (applicatiebeveiliging), wie deze actie uitvoerde (identiteitbeheer) en
vanaf welke plek deze actie afkomstig was (netwerkbeveiliging).
Voor monitoring geldt eenzelfde soort redenering; hoewel het hierbij belangrijk is
dat men afzonderlijke componenten monitoort is het tevens belangrijk om de
verschillende componenten in een ‘monitoringketen’ te plaatsen. Op het moment
dat één component uit de keten niet meer goed blijkt te functioneren, heeft dit
gevolgen voor de gehele keten en moet dit ook als zodanig worden opgemerkt.
Deze paragraaf beschrijft kwetsbaarheden en bedreigingen die men op het gebied

van monitoring, auditing en logging kan onderscheiden.
9.2.1 Ontbreken van toezicht

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

mechanismen juist zijn geconfigureerd. Door verschillende oorzaken kan het
organisaties aan dit toezicht ontbreken:
• Er is überhaupt geen monitoring van netwerkverkeer ingeregeld;

• De monitoringcomponenten leveren zoveel informatie dat de belangrijke
aanvallen niet meer te onderscheiden zijn van de vele ‘script kiddie’
aanvallen; men ziet m.a.w. door de bomen het bos niet meer.
• De monitoringcomponenten verzamelen wel continu data maar er is geen
medewerker beschikbaar om deze logging door te nemen.
• De monitoringcomponenten verzamelen wel continu data maar de
gebeurtenissen vanaf deze componenten zijn op geen enkele manier aan
elkaar te koppelen doordat de tijdstippen op de componenten uit elkaar
lopen. Zelfs een afwijking van enkele seconden kan er al voor zorgen dat
gebeurtenissen op verschillende componenten niet meer aan elkaar
vallen te relateren.
Het ontbreken van dit toezicht kan ertoe leiden dat kwaadwillenden misbruik
maken van webapplicaties zonder dat de organisatie dit detecteert.
9.2.2 Impact: onbekend

Wanneer een component een losstaande gebeurtenis rapporteert, helpt dit in het
bepalen van de technische impact: het component is bijvoorbeeld tijdelijk niet
meer beschikbaar of de performance is tijdelijk verlaagd. Maar wat betekent dit
nu voor de gehele keten? Merkt de gemiddelde gebruiker niets van deze storing of
leidt de storing tot een zeer ernstige onderbreking van de service aan de
eindgebruiker? Om de impact van een gebeurtenis te kunnen bepalen, moet men
de gebeurtenis in een groter geheel (de keten) bekijken. Dit is niet mogelijk
wanneer men de omgeving beschouwt als een verzameling van losstaande
componenten. De beschouwing van de omgeving als een keten van nauw
samenwerkende componenten is in dit geval de enige juiste. Inzicht in de
verbanden die zich tussen de componenten bevinden is hierbij essentieel. Op
basis van dit inzicht zou de organisatie vervolgens een afhankelijkheids- en
kwetsbaarhedenanalyse (kortweg A&K analyse) of risicoanalyse moeten uitvoeren.
9.2.3 Gebrek aan coördinatie en samenwerking

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

9.3 Aanbevelingen
Dit hoofdstuk sluit af met een reeks aan aanbevelingen op het gebied van
monitoring, logging en auditing.
9.3.1 Maak gebruik van Intrusion Detection Systemen (IDS)

Intrusion Detection Systemen (IDS) kunnen helpen bij het detecteren van
aanvallen op webapplicaties. IDS’en monitoren continu het verkeer dat zich door
de DMZ-segmenten verplaatst en kunnen, veelal op basis van aanvalspatronen,
misbruik van webapplicaties en andere infrastructuurcomponenten detecteren.
Grofweg kan het volgende onderscheid in IDS’en worden aangebracht:
• Network-based Intrusion Detection Systems (NIDS); een NIDS plaatst

men als losstaand component in het netwerk waarna deze vervolgens
netwerkverkeer opvangt door de interface in promiscious mode te
plaatsen. Promiscious mode houdt in dat de interface niet alleen verkeer
opvangt dat specifiek voor deze interface bedoeld is, maar dat de interface
al het verkeer dat het voorbij ziet komen (dus ook het verkeer dat niet aan
de interface is gericht) verwerkt. De voordelen van een NIDS zijn dat één
NIDS een groot netwerk met verschillende componenten kan monitoren en
dat het NIDS geen negatieve effecten heeft op de werking van de
infrastructuur. Nadelen van een NIDS zijn dat bij grote drukte niet al het
netwerkverkeer kan worden geanalyseerd waardoor mogelijk aanvallen
niet gedetecteerd worden en dat versleuteld verkeer (zoals bijvoorbeeld
HTTPS) niet kan worden bekeken. Daarnaast vereist een NIDS dat men de
aansluiting hiervan op de infrastructuur zodanig inregelt dat al het verkeer
beschikbaar komt voor het NIDS. In het geval de organisatie gebruik
maakt van switches kan dit betekenen dat men de switch zodanig moet
configureren dat de switch al het verkeer ook kopieert naar het
aansluitpunt van het NIDS (span port) of dat het IDS dit verkeer ontvangt
via speciale ‘vampire taps’ (onderbrekingen in de kabelverbinding).
• Host-based Intrusion Detection Systems (HIDS); een HIDS installeert

men op een server waarna het HIDS continu de activiteiten op deze server
monitoort. Het HIDS kijkt hierbij niet alleen naar het netwerkverkeer
(zoals het NIDS) maar vooral ook naar logging en andere lokale
wijzigingen. Voordelen van de inzet van een HIDS zijn dat het meer
aanvallen zal detecteren als het NIDS en dat het bovendien in staat is om
versleutelde informatie te bekijken. Nadelen zijn dat het HIDS negatieve
effecten kan hebben op de werking van het system en het netwerk
(performance-impact) en dat het onderhouden van alle lokaal
geïnstalleerde HIDS-systemen veel beheerlast met zich mee kan brengen.
• Application-based IDS; een application-based IDS wordt specifiek

ingezet voor het monitoren van misbruik van een specifieke applicatie. Dit
is de minst gangbare vorm van een IDS.

Tabel 9-1 geeft een overzicht van de verschillende eigenschappen van NIDS- en
HIDS-systemen.
NIDS HIDS
• Monitoort het gehele netwerk • Monitoort alleen een specifiek systeem
• Kan alle aanvallen op een omgeving • Kan alleen die aanvallen vastleggen die
vastleggen door de filteringmechanismen zijn
doorgelaten
• Reageert direct op afwijkend • Reageert veelal pas op het moment dat
netwerkverkeer (real time); de een bepaalde regel in een log
aanvaller kan zijn sporen moeilijk verschijnt; de aanvaller heeft hierdoor
verbergen de mogelijkheid om zijn sporen
onzichtbaar te maken
• Kan niet bepalen of een • Kan uit de logging opmaken of een
gedetecteerde aanval succesvol is gedetecteerde aanval ook succesvol is
• Geen impact op de performance van • Levert een mogelijke vertraging op in
de omgeving de werking van het systeem
• Redelijk eenvoudig op te zetten • Mogelijk complexe setup bij veel hosts
• Bekijkt de header van pakketten en • Bekijkt de header van pakketten niet
kan daarom bepaalde aanvallen (IP
DoS en teardrop attacks) detecteren
• Onafhankelijk van een • Aparte implementaties voor
besturingssysteem verschillende besturingssystemen
• Vereist de aanschaf van nieuwe • Wordt geïnstalleerd op bestaande
hardware hardware
Tabel 9-1: NIDS versus HIDS
In de inleiding van deze paragraaf stelden we al dat het detecteren van aanvallen
veelal gebeurt op basis van bekende aanvalspatronen. Deze systemen noemt men
ook wel signature-based aangezien deze systemen op basis van bekende
‘handtekeningen’ van aanvallen detectie uitvoeren. Het nadeel van deze werkwijze
is dat het IDS alleen bekende aanvallen herkent en nieuwe aanvallen
onopgemerkt laat. Tegenover de signature-based IDS’en staan de anomaly-based
systemen. Deze systemen werken niet op basis van handtekeningen, maar op
basis van afwijkingen (anomalieën). Deze systemen vereisen eerst een
inleerperiode waarin zij bekijken wat ‘normaal’ gedrag is. Vervolgens kan het
systeem afwijkingen op dit normale gedrag herkennen en dit rapporteren als een
mogelijke aanval. Voordeel van deze werkwijze is dat een dergelijk IDS nieuwe –
onbekende – aanvallen hoogst waarschijnlijk zal detecteren. Nadeel is dat het
systeem veel false positives kan opleveren: een alarm zonder dat er iets aan de
hand blijkt te zijn. Dit is met name het geval op het moment dat de organisatie
een nieuwe applicatie in de omgeving uitrolt of een nieuwe versie van een
bestaande applicatie introduceert.
Van alle soorten IDS’en is de network-based variant (NIDS) met signatures de

meest gebruikte en meest bekende vorm. Bij het inrichten van een NIDS is het
zaak goed te bekijken welke meetpunten interessant zijn voor het NIDS. In figuur

9-1 is een voorbeeld opgenomen van mogelijk interessante meetpunten aan de
hand van de DMZ-opbouw zoals in hoofdstuk 3 werd beschreven.
Figuur 9-1: mogelijke plaatsing van een NIDS
Het NIDS uit figuur 9-1 kent drie meetpunten: één voor de eerste firewall (1), één
tussen de twee (dual-vendor) firewalls (2) en één tussen de DMZ en de
backoffice. Op punt (1) kan het IDS alle aanvallen die gericht zijn op de omgeving
detecteren omdat hier nog geen filtering van netwerkverkeer heeft
plaatsgevonden. De gegevens van dit meetpunt zijn dan ook vooral van
statistische waarde en leiden niet per definitie tot een alarm. Op punt (2) heeft al
enige filtering plaatsgevonden (van een firewall en mogelijk van een proxy).
Verkeer op dit punt zal zeer waarschijnlijk de servers aan de achterste firewall
gaan bereiken. Op het moment dat het IDS hier een aanval detecteert dient dit
een hogere prioriteit te krijgen als bij punt (1). Tenslotte monitoort het IDS op
punt (3) het verkeer tussen de DMZ en de backoffice. Dit is met name een
interessant meetpunt aangezien de meest vertrouwelijke informatie zich per
definitie zal bevinden in de backoffice en de toegang tot deze vertrouwelijke
informatie nauwkeurig moet worden gemonitoord.
ACHTERGROND Door het aantal geregistreerde gebeurtenissen op punt 1 en

punt 2 met elkaar te vergelijken ontstaat ook inzicht in de effectiviteit van de
filteringsmechanismen binnen de omgeving. Dit kan een organisatie helpen in het
opstellen van bijvoorbeeld een return-on-investment analyse voor
beveiligingscomponenten.

Naast het verzamelen van al deze informatie is het ook van belang dat men de
inrichting van het NIDS verder goed inregelt. Enkele aandachtspunten die hierbij
van belang zijn:
• Zorg ervoor dat signature-based systemen regelmatig worden voorzien

van de nieuwste aanvalspatronen.
• Zorg ervoor dat databases voldoende ruimte bieden om de grote

hoeveelheid gegevens die een NIDS produceert, in onder te kunnen
onderbrengen. Men dient ook na te denken over de duur die logging moet
worden opgeslagen en de manier waarop de logging zal worden
gearchiveerd.
• Zorg ervoor dat de alarmering van het NIDS goed getuned wordt. Een
NIDS dat continu alarmen uitzendt, zullen beheerders niet meer serieus
nemen.
• Regel een goede beheerprocedure rondom het NIDS. Een medewerker van
de organisatie zal de logging van het NIDS regelmatig (bijvoorbeeld elke
ochtend) moeten bekijken. Het is belangrijk dat binnen de organisatie is
belegd wie dit doet. Daarnaast is het, ter verbetering van de leesbaarheid
van de logging, aan te raden filters op de logging te plaatsen.
• Onderschat de hoeveelheid mankracht die benodigd is voor het monitoren

en onderzoeken van anomalieën en false positives niet. Het kan een zeer
intensieve klus blijken te zijn om de filters van het IDS optomaal in te
richten.
9.3.2 Breng logging op één punt samen

In de praktijk blijkt een organisatie er vaak niet aan te kunnen ontkomen om
verschillende loggingmechanismen naast elkaar te gebruiken. Zo ondersteunt het
ene systeem alleen logging op basis van SYSLOG, maakt een ander systeem
alleen lokaal logbestanden aan en stelt weer een ander systeem logging
beschikbaar via SNMP. Al deze verschillende loggingmechanismen zorgen ervoor
dat logging versnipperd raakt en men het overzicht over alle gebeurtenissen
mogelijk snel kwijtraakt. Om beveilingsissues efficiënt te kunnen detecteren is het
van belang deze logging op één centraal punt weer bijeen te brengen.
OPMERKING Hoewel een organisatie er in de praktijk niet aan ontkomt om

verschillende loggingmechanismen in te zetten is het altijd aan te raden om de
diversiteit in loggingmechanismen zoveel mogelijk te beperken.
Door de logging op een centraal punt bijeen te brengen en filtering toe te passen
op deze logging ontstaat een heldere blik op de informatie vanuit verschillende
lagen van het RBW. Dit kan uiteindelijk resulteren in een situatie zoals
weergegeven in figuur 9-2.

Figuur 9-2: inrichting centrale logging
In een centrale loggingdatabase komt de logginginformatie uit verschillende

onderdelen van het RBW samen. Denk hierbij aan de volgende typen informatie:
• Logging op het niveau van netwerkbeveiliging: bijvoorbeeld logging van

geweigerde netwerkverbindingen (mogelijk poortscans) door een firewall,
gedetecteerde aanvallen door een intrusion detection systeem, statistieken
van een honeypot, etc…
• Logging op het niveau van platformbeveiliging: logging van
ongeautoriseerde bestandstoegang, potentieel gevaarlijke
configuratiewijzigingen, toevoeging van nieuwe gebruikersaccounts, etc…
• Logging op het niveau van applicatiebeveiliging: logging van
uitgefilterde HTTP-headers, geblokkeerde URL’s, geblokkeerd lekken van
informatie, etc…
• Logging op het niveau van identiteitbeheer: logging van foutieve
inlogpogingen op de webapplicatie, accounts die ‘locked-out’ raken,
sessiemisbruik, etc…
• Logging op het niveau van autorisatiebeheer: logging van
autorisatiemisbruik, uitgedeelde autorisaties (met mogelijk uitgebreide
rechten), etc…
• Logging op het niveau van vertrouwelijkheid en onweerlegbaarheid:
logging van onweerlegbare transacties, foutieve handtekeningen, etc…
OPMERKING Dit document schaart monitoringgegevens ook onder de noemer

logging. Het verzamelen van informatie via SNMP zullen sommige organisaties
bijvoorbeeld meer zien als monitoringgegevens dan logginggegevens. Beide typen
informatie geven echter informatie over de status c.q. gezondheid van een
systeem: monitoringgegevens over het beveiligingsniveau op een specifiek
tijdstip, logging over acties die het beveiligingsniveau kunnen aantasten.
De centraal opgeslagen informatie kan zeer interessant zijn voor kwaadwillenden

aangezien ze 1) hier veel van kunnen leren v.w.b. de opbouw van de

infrastructuur en de gebruikte componenten hierin en 2) ze via deze centrale plek
eventuele sporen van misbruik kunnen wissen. Daarom is het van belang veel
aandacht te besteden aan de beveiliging van deze centrale database zodat
onbevoegden hiertoe geen toegang hebben (vertrouwelijkheid) en hierin geen
wijzigingen kunnen aanbrengen (integriteit).
OPMERKING SNMP kan slechts in beperkte mate beveiligd worden. Daarnaast

kan het via SNMP mogelijk zijn om configuratiewijzigingen op een component door
te voeren. Dit laatste verhoogt de noodzaak tot het afschermen van SNMP
aanzienlijk.
9.3.3 Breng correlaties aan

Nadat alle logginginformatie m.b.t. webapplicaties bijeen gebracht is (9.3.2),
bestaat de volgende stap uit het aanbrengen van correlaties tussen de
verschillende logging gebeurtenissen. De uitdaging hierbij is om alle
gebeurtenissen op de verschillende niveau’s aan elkaar en aan een specifieke
webapplicatie te correleren. Op deze manier kan men het pad dat een
kwaadwillende heeft doorlopen achterhalen en tevens inzicht krijgen in de
aanvallen die gedurende een bepaalde periode op een webapplicatie zijn
uitgevoerd. Figuur 9-3 geeft een voorbeeld van correlaties die er kunnen bestaan
tussen een applicatie en de aanwezige componenten (blauwe lijn) en de
correlaties (afhankelijkheden – rode lijnen) tussen componenten onderling.
Figuur 9-3: monitoringafhankelijkheden

Het leggen van correlaties blijkt in de praktijk geen eenvoudige klus en kan een
organisatie alleen bereiken door alle competenties rondom webapplicaties bijeen
te brengen. Een goed ingerichte Configuration Management Database (CMDB) kan
het leggen van correlaties voor een belangrijk gedeelte vereenvoudigen.
9.3.4 Richt NTP correct in

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

Autorisaties zijn aan veranderingen onderhevig. Medewerkers komen en gaan en
hetzelfde geldt voor klanten. Hierdoor zullen de autorisaties op webapplicaties
continu wijzigen. Niet alleen moet men nieuwe autorisaties uitdelen, ook
bestaande autorisaties zal men wellicht moeten verwijderen of inperken. Daarom
is het van belang dat ‘applicatieverantwoordelijken’ uitgedeelde autorisaties
regelmatig onder de loep nemen. Hiertoe moeten zij een overzicht toegestuurd
krijgen met de huidige stand van zaken rondom autorisaties voor de webapplicatie
waarvoor deze persoon autorisatieverantwoordelijk is. De
applicatieverantwoordelijke zal vervolgens moeten bekijken of er autorisaties
bestaan die niet meer nodig zijn of gewijzigd dienen te worden. Belangrijk is wel
dat het overzicht te behappen is voor een applicatieverantwoordelijke. Wanneer
het autorisatieoverzicht bijvoorbeeld 100 pagina’s omvat, zal de
applicatieverantwoordelijke door de bomen het bos niet meer zien en geen
serieuze aandacht meer (kunnen) besteden aan dit overzicht.
9.3.6 Bepaal wat te doen bij het uitvallen van loggingmechanismen

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

niet kan opslaan. Dit betekent dat logging verloren gaat.

• Het component normaal door laten functioneren en de logging lokaal laten
queuen. Veel componenten beschikken over een lokaal mechanisme om
logging tijdelijk te queuen. Op het moment dat het centrale logging
mechanisme weer beschikbaar komt, sluist het component de verzamelde
logging alsnog door. Dit voorkomt dat het component niet meer
beschikbaar is en voorkomt tevens dat logging verloren gaat. Dit is echter
wel een tijdelijke oplossing. Op het moment dat de lokale queue vol loopt
moet opnieuw besloten worden wat het component hierna doet (door
functioneren – zie bovenstaande optie – of stoppen met functioneren – zie
volgende optie).
• Het component acuut laten stoppen met functioneren. Dit betekent dat
gebruikers hoogst waarschijnlijk niet meer kunnen doorwerken. Het
voorkomt wel dat het component mogelijk malafide acties niet meer kan
registreren.
Vanuit het oogpunt van beveiliging en beschikbaarheid heeft het de voorkeur

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

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

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

9.3.8 Voer actief controles uit op logging
Het is belangrijk dat een organisatie actief controles uitvoert op de verzamelde
logging. Alleen op die manier kan een organisatie misbruik van de omgeving en
inbraakpogingen detecteren. Controle van de logging moet hiertoe onderdeel
uitmaken van procedures waardoor taken en verantwoordelijkheden op dit gebied
duidelijk belegd zijn. De verantwoordelijke moet in zijn taak ondersteund worden
door een deugdelijke filtering op de logging. Alleen bij een deugdelijke filtering is
het mogelijk om aanvallen te detecteren uit de grote hoeveelheid logging die
verschillende componenten op een dag zullen genereren. Filtering van de logging
zal dynamisch zijn; door het filter continu aan te passen ontstaat een behapbaar
en bruikbaar overzicht van gebeurtenissen die zich in de omgeving hebben
voorgedaan.
9.3.9 Coördineer en bevorder samenwerking

Doordat bij het samenbrengen van logging verschillende disciplines bijeenkomen
kan het handig zijn om in bepaalde gevallen deze disciplines met elkaar in contact
te brengen. Dit kan bijvoorbeeld nodig zijn op het moment dat een IDS een
aanval detecteert en op verschillende beveiligingslagen bekeken moet worden wat
over deze aanval kan worden teruggevonden. Ook bij onduidelijkheden rondom
gebeurtenissen is het handig dat verschillende disciplines elkaar snel weten te
vinden om op die manier problemen te verhelpen. Hoe een organisatie een
dergelijke samenwerking kan bevorderen is zeer afhankelijk van de
organisatiestructuur. In kleinere organisaties vindt samenwerking wellicht al
informeel plaats, in grotere organisaties kan men bijvoorbeeld gebruik maken van
virtuele teams.

A REFERENTIES
(DDoS-GOVCERT, 2005) GOVCERT.NL, Aanbevelingen ter bescherming tegen

Denial-of-Service-aanvallen. Den Haag, 2005.
(FBI/CSI, 2005) Computer Security Institute, 2005 CSI/FBI Computer Crime and
Security Survey. San Francisco, 2005.
(INSECURE, 2006) Ivan Ristic, Web Application Firewalls Primer. INSECURE

Magazine maart 2006. Beschikbaar:
http://www.insecuremagazine.com/INSECURE-Mag-5.pdf (online)

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 2000
Microsoft Windows Server 2003
Beschikbaarheid: https://kennisbank.govcert.nl/
Samenvatting
Er bevindt zich een kwetsbaarheid in Outlook Web Access (OWA), een
onderdeel van Microsoft Exchange. Via deze kwetsbaarheid kunnen
ongeautoriseerd scripts worden uitgevoerd via de browser van de
gebruiker. Microsoft heeft updates voor Microsoft Exchange 2000 en
2003 uitgebracht die deze kwetsbaarheid verhelpen.
Gevolgen
De kwetsbaarheid kan ertoe leiden dat ongeautoriseerd scripts op
het systeem van een gebruiker worden uitgevoerd zodra de gebruiker
een speciaal opgemaakte e-mail opent via OWA. Op deze manier kan de
kwaadwillende bijvoorbeeld de cookies van de gebruiker achterhalen
en op deze manier mogelijk toegang krijgen tot de e-mail van de
gebruiker (session hijacking).
Beschrijving
Er bevindt zich een kwetsbaarheid in Outlook Web Access (OWA), een
onderdeel van Microsoft Exchange. Wanneer een gebruiker een
speciaal opgemaakte e-mail via OWA opent kan het gebeuren dat
ongeautoriseerd scripts worden uitgevoerd via de browser van de
gebruiker. Dit wordt veroorzaakt door het feit dat Microsoft
Exchange sommige mails met daarin scripts onjuist interpreteert.

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:
FamilyId=0E192781-847F-41C1-B32A-84218DB60942
- Microsoft Exchange Server 2003 SP2:
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

C AFKORTINGEN EN DEFINITIES
Afkorting Omschrijving
ACL Access Control List
AD Active Directory
API Application Programming Interface
BGP Border Gateway Protocol
CDP Cisco Discovery Protocol
CMDB Configuration Management Database
CMS Content Management System
CSI Computer Security Institute
CWE Common Weakness Enumeration
DBA Database Administrator
(D)DoS (Distributed) Denial-of-Service
DMZ Demilitarised Zone
DNS Domain Name Services
EPFW End-Point Firewall
FBI Federal Bureau of Investigation
FTP File Transfer Protocol
GPO Group Policy Object
GSLB Global Server Load Balancing
HIDS Host-based Intrusion Detection System
HTML HyperText Markup Language
HTTP(S) HyperText Transfer Protocol (Secure)
I&AM Identity and Access Management
IDS Intrusion Detection System
IIS Internet Information Services
IP Internet Protocol
ISAPI Internet Server Application Program Interface
ISP Internet Service Provider
ISS Internet Security Systems
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LSLB Local Server Load Balancing
MTU Message Transfer Unit
NAT Network Address Translation
NIDS Network-based Intrusion Detection System
NTP Network Time Protocol
NVD National Vulnerability Database
OS Operating System
OSPF Open Shortest Path First
OWA Outlook Web Access
OWASP Open Web Application Security Project
PFW Perimeter Firewall
PKI Public Key Cryptography

Afkorting Omschrijving
PoC Proof-of-Concept
RBW Raamwerk Beveiliging Webapplicaties
RDP Remote Desktop Protocol
RFC Request For Comment
RSS Really Simple Syndication (RSS 2.0) / Rich Site Summary (RSS
0.91 en RSS 1.0) / RDF Site Summary (RSS 0.9 en 1.0)
SAML Security Assertion Markup Language
SCP Secure Copy
SIRT Security Incident Response Team
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SPOF Single Point-of-Failure
SQL Structured Query Language
SSH Secure Shell
SSL Secure Sockets Layer
SSO Single Sign-On / Single Sign-Out
STP Spanning Tree Protocol
TCP Transport Control Protocol
TFTP Trivial File Transfer Protocol
TLS Transport Layer Security
TTL Time-To-Live
UDP User Datagram Protocol
URL Uniform Resource Locator
uRPF Unicast Reverse-Path-Forwarding
VLAN Virtual LAN
WSDL Web Service Description Language
WSUS Windows Server Update Services
XML eXtensible Markup Language
XSS Cross-Site Scripting

D HOOFDPUNTEN BEVEILIGING
Deze bijlage geeft een overzicht van de kwetsbaarheden, dreigingen en

maatregelen die in dit document aan bod komen.
D.1 Kwetsbaarheden en dreigingen
Netwerk
• (Distributed) Denial-of-Service §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

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

Identiteit- en toegangsbeheer
• Bepaal de plek van identiteiten 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

(Dutch) Raamwerk Beveiliging Webapplicaties, Govcert

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(Dutch) Raamwerk Beveiliging Webapplicaties, Govcert

Uploaded by

Copyright:

Available Formats

WWW.GOVCERT.

WEBAPPLICATIES Postbus 84011

Wilhelmina van Pruisenweg 104

Dit werk is gepubliceerd onder de voorwaarden beschreven in

English Summary .........................................................................................................1

2 Raamwerk Beveiliging Webapplicaties ............................................................4

6 Identiteit- en Toegangsbeheer ......................................................................73

7 Vertrouwelijkheid en onweerlegbaarheid ......................................................88

A Referenties .................................................................................................. 110

B Beveiligingsadvies GOVCERT.NL-2006-133.................................................. 111

C Afkortingen en definities ............................................................................. 113

D Hoofdpunten Beveiliging ............................................................................. 115

This Framework for Web Application Security provides an overview of security

The application platform. Fortunately, focus on the security of web applications

Authentication and autorisation, including various types of access control (role

Confidentiality and Integrity of information, using encryption and digital

Integration of the web application with various security components. This

Monitoring, auditing and logging.

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

• Het aantal webapplicaties is sterk toegenomen waardoor de kans op

Hoofdstuk 2 van dit document introduceert het Raamwerk Beveiliging

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

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

Dit hoofdstuk introduceert het RBW. Dit raamwerk beschrijft de verschillende

• Internetsites; internetsites zijn publieke websites die voor iedereen

• Extranetten; extranetten maken gebruik van dezelfde technieken als

• Intranetten; ook intranetten maken gebruik van dezelfde technieken als

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

Hoewel webapplicaties normaal gesproken gebruik maken van de standaard TCP-

ACHTERGROND Om de verschillende dreigingen, kwetsbaarheden en

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

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

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

• Om HTTP-berichten versleuteld over internet te sturen kan men gebruik

2.2 Mogelijke kwetsbaarheden en bedreigingen

Een webapplicatie heeft te maken met een groot aantal mogelijke

Drie generieke kwetsbaarheden en bedreigingen noemen we hier alvast:

• Configuratiefouten; wanneer men niet nadenkt over de configuratie van

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

• Aanwezigheid van bekende kwetsbaarheden; dagelijks verschijnen op

• Aanwezigheid van nieuwe (0-day) kwetsbaarheden; wanneer niet de

2.3 Het Raamwerk

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

• Netwerkbeveiliging; beveiliging die zich met name richt op het

• Platformbeveiliging; richt zich op het beveiligen van de verschillende

• Applicatiebeveiliging; richt zich op het beveiligen van de webapplicatie

• Identiteitbeheer; identiteitbeheer richt zich o.a. op het authenticeren

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

• Vertrouwelijkheid en onweerlegbaarheid; vertrouwelijkheid en

• Beveiligingsintegratie; deze laag richt zich op het integreren van de

• Monitoring, auditing en alerting; deze laag richt zich op het monitoren

Als laatste is in figuur 2-1 het informatiebeveiligingsbeleid afgebeeld. Dit beleid is

Het RBW kent de volgende doelen:

• Dienen als referentiepunt voor het implementeren van

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

Figuur 2-2: schade door misbruik

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

Figuur 2-3: scope RBW (rode vlak)

2.6 Algemene aanbevelingen

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

• Bepaal een baseline en monitoor; aanvallen op de omgeving en

• Wees voorbereid; een organisatie kan een groot aantal maatregelen

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