Beruflich Dokumente
Kultur Dokumente
NL
RAAMWERK
BEVEILIGING POSTADRES
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:
1 Inleiding..........................................................................................................2
1.1 Leeswijzer ....................................................................................................... 2
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.2 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 30
4.3 Aanbevelingen ............................................................................................... 33
5 Applicatiebeveiliging .....................................................................................42
5.1 Inleiding........................................................................................................ 42
5.2 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 42
5.3 Aanbevelingen ............................................................................................... 52
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.2 Mogelijke kwetsbaarheden en bedreigingen ........................................................ 99
9.3 Aanbevelingen ..............................................................................................101
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 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.
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:
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 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.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:
1
Zie: http://rfc.net/rfc2616.html
2
Really Simple Syndication (RSS 2.0); manier om informatie van de website in een vastgesteld formaat
beschikaar te stellen aan gebruikers en applicatie
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’).
In figuur 2-1 is het RBW weergegeven. Het raamwerk bevindt zich hierbij logisch
gezien tussen een client en een webapplicatie.
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:
3
Een webapplicatie is bijvoorbeeld een Websphere toepassing, een applicatieplatform bijvoorbeeld de
Websphere server
Daarnaast bevinden zich in het raamwerk ook nog een aantal verticale lagen.
Deze lagen bieden ondersteuning aan de horizontale lagen:
2.4 Doelen
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.
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.
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:
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
4
Hierbij wordt uitgegaan van een dedicated infrastructuur voor webapplicaties waarin zich geen andere services
bevinden zoals mail (SMTP) en DNS.
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)
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.
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
• 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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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
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).
9
Een appliance is een deels voorgeconfigureerde machine met een specifieke functionaliteit (bijvoorbeeld
firewalling, routing, switching) en gelimiteerde toegang tot het besturingssysteem
• 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.
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.
• Communicatieverbindingen;
• Firewalls;
• Load balancers;
• Proxies;
• Routers;
• Switches.
4.1 Inleiding
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.
• 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
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
Grofweg bestaat een juist ingericht patch management proces uit de volgende
onderdelen:
Bedenk dat niet-actieve maar wel aanwezige services op een systeem uiteindelijk
toch tot een kwetsbaar systeem kunnen leiden aangezien ‘lekke’ programmacode
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
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.
VOORBEELD Over het ‘chrooten’ van Apache zijn enkele goede ‘howto’-artikelen
terug te vinden op internet. Zie onder andere:
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.
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.
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.
• ipfw; FreeBSD packet filter. Het is daarnaast een standaard onderdeel van
Apple Mac OS. Voor simpele regels biedt Apple daarnaast een eenvoudige
grafische gebruikersinterface.
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).
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.
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.
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.
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=<script>alert(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.
SELECT *
FROM gebruikers
WHERE gebruikersnaam = ‘<gebruikersnaamveld>’
AND wachtwoord = ‘<wachtwoordveld>’
SELECT *
FROM gebruikers
WHERE gebruikersnaam = ‘1’
AND wachtwoord = ‘x’ OR ‘1=1’
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).
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.
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.
http://www.eenwebsite.nl/showfile.php?file=%2Fwebapp%2Fabonnees.txt
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.
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:
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).
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.
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
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.
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’.
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.
12
Zie: http://rfc.net/rfc2616.html
13
Zie: http://rfc.net/rfc1945.html
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.
• 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
Methode Omschrijving
CONNECT Een methode die aangeeft dat een tussenliggende proxy het
verzoek niet mag aanpassen c.q. onderzoeken en simpelweg moet
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.
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.
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.
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
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.
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:
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.
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:
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.
• 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’.
Het volgende voorbeeld illustreert een mogelijk probleem dat zich kan voordoen
bij toegangsbeheer:
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.
• 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:
• 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.
Het overzicht van figuur 6-3 toont vijf verschillende applicaties (A-E) die allen een
andere invulling hebben gegeven aan identiteitbeheer en toegangsbeheer. Bij de
eerste applicatie (applicatie A) is alles op dit gebied in de applicatie zelf
ingebouwd. De applicatie kan geheel zelfstandig functioneren maar maakt geen
gebruik van bestaande mechanismen. Applicatie E daarentegen heeft totaal geen
ingebouwde logica voor identiteit- en toegangsbeheer. Deze applicatie vertrouwt
volledig op centraal belegde functionaliteiten op dit gebied. Voordeel van de
aanpak van applicatie E is dat programmeurs zich tijdens het ontwikkelen van de
applicatie volledig hebben kunnen richten op de functionaliteit van de applicatie.
Zij hoeven zich niet druk te maken om zaken als authenticatie en autorisatie. Ook
tussenvormen zijn uiteraard mogelijk. Zo neemt applicatie D alle zaken op het
gebied van identiteitbeheer centraal af, maar geeft het een eigen invulling aan
toegangsbeheer. M.a.w.: het vaststellen van de identiteit vertrouwt de applicatie
toe aan een centraal mechanisme, maar het uitdelen van rechten aan deze
identiteit is voorbehouden aan de applicatie.
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.3 Voorbeelden
Er zijn verschillende producten op de markt die services op het gebied van
identiteit- en toegangsbeheer voor webapplicaties bieden. Onderstaand vindt u
een – alfabetisch – overzicht van producten die (geheel of gedeeltelijk) invulling
geven aan de functionaliteiten zoals deze in dit hoofdstuk worden beschreven:
• Entrust GetAccess;
• eTrust Siteminder;
• IBM Tivoli Access Manager (voorheen IBM Policy Director);
• Oblix NetPoint;
• RSA Cleartrust.
-Wachtwoord
-Passphrase
-PIN-code
-Token
-Smartcard
-Mobiele telefoon
- Biometrische
kenmerken
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.
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
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.
7.1 Inleiding
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
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.
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).
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
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.
8.1 Inleiding
8.2 Mechanismen
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.
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.
Een voor de hand liggende methode voor het bereiken van actieve
beveiligingsintegratie is de toepassing van webservices.
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:
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.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.
Het ontbreken van dit toezicht kan ertoe leiden dat kwaadwillenden misbruik
maken van webapplicaties zonder dat de organisatie dit detecteert.
Dit hoofdstuk sluit af met een reeks aan aanbevelingen op het gebied van
monitoring, logging en auditing.
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.
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.
• 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.
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.
• 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.
(FBI/CSI, 2005) Computer Security Institute, 2005 CSI/FBI Computer Crime and
Security Survey. San Francisco, 2005.
#################################################################
## 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 ##
#################################################################
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.
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:
Hyperlinks
http://support.microsoft.com/kb/912442
http://support.microsoft.com/kb/912918
http://www.sec-consult.com/268.html
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
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
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
Vertrouwelijkheid en onweerlegbaarheid
• Versleutel vertrouwelijke informatie §7.3.1
• Versleutel cookies §7.3.2
• Maak gebruik van digitale handtekeningen §7.3.3