Bij het beveiligen van websites en webapplicaties onderscheiden we verschillende niveaus. Welke niveaus dat precies zijn verschilt per situatie, maar doorgaans worden maatregelen in ieder geval op de volgende niveaus aangebracht:

• Applicatieniveau.
• Platformniveau.
• Netwerkniveau.
• Algemeen- en procesniveau.

Het is niet altijd mogelijk om een maatregel precies binnen één van de niveaus in te delen, maar dat is eigenlijk niet zo belangrijk, zo lang de maatregel maar wordt geïmplementeerd. In dit artikel benoemen we op elk niveau diverse maatregelen die de beveiliging van je webapplicatie ten goede komen. Het is belangrijk om op te merken dat onderstaande geen uitputtende lijst van maatregelen is. Als je zelf actief aan de gang gaat met het beveiligen van je webapplicatie, dan is het aan te raden om daarover advies in te winnen bij specialisten.

Het eerste niveau waar we naar kijken is dat van de webapplicatie zelf. Dit is het niveau waarmee een webdeveloper doorgaans het meest bekend zal zijn. Overigens is het goed om te weten dat moderne webapplicatieframeworks zoals Ruby on Rails standaard al een uitgebreide set van maatregelen bevatten om beveiligingsrisico’s te beperken.

Wanneer de webapplicatie gegevens van gebruikers verwerkt, dan moet je er als webdeveloper in beginsel van uitgaan dat die invoer “corrupt en foutief” is. Dat betekent dat alle gegevens genormaliseerd moeten worden en dat de software de invoer aan de serverzijde moet controleren. Verwacht de webapplicatie bijvoorbeeld een getal te ontvangen, maar komt er in plaats daarvan een stukje tekst binnen, dan moet dat afgevangen worden nog voor de software verdere bewerking op de gegevens uitvoert. Het enkel normaliseren en controleren van de invoer in de webbrowser is onvoldoende.

Een zwakke plek die vroeger nogal eens voorkwam, is dat een website of webapplicatie lokale bestanden inlaadt op basis van invoer van de gebruiker. Als de gebruiker de URL http://www.voorbeeld.nl/?pagina2 opvroeg, dan werd het bestand ‘pagina2’ van het bestandssysteem opgevraagd en de inhoud aan de gebruiker getoond. Daarmee is het echter ook mogelijk om bijvoorbeeld password-bestanden inzichtelijk te maken. Kortom: de webapplicatie mag de controle over welke bestanden geopend kunnen worden nooit uit handen geven aan de gebruiker.

Http headers bevatten informatie die noodzakelijk zijn voor de werking van het Http protocol. Dat is het systeem waarmee gegevens van de webserver naar de browser worden gestuurd, en vice versa. In de praktijk wordt er door de webapplicatie echter vaak teveel informatie in de headers meegestuurd, informatie die voor hackers bijzonder interessant is. Stuur vanuit de webapplicatie dan ook niet meer dan de strikt noodzakelijke informatie mee.

Om te voorkomen dat kwaadwillenden ongewenste commando’s op de databaseserver kunnen afvuren, moeten databasequeries geprepareerd en geparametriseerd worden. Dat wil zeggen dat de queries (commando’s) op voorhand zijn vastgelegd en dat alleen de specifieke variabelen of parameters die de query specifiek maken voor de gebruiker worden ingevoegd vlak voor het daadwerkelijk uitvoeren van het commando.

Wellicht een voor de hand liggende maatregel, maar toch bevatten niet alle webapplicaties deze mogelijkheid. Door gebruikers de mogelijkheid te bieden om uit te loggen, wordt voorkomen dat de webapplicatie toegankelijk blijft voor derden nadat de gebruiker klaar is met het gebruik van de applicatie.

Hoeveel beveiligingsmaatregelen je ook neemt, het is helaas altijd mogelijk dat iemand ongewenst toegang weet te krijgen tot de data van de webapplicatie. Om te voorkomen dat er schade wordt aangericht, is het aan te raden om gevoelige informatie zoals creditcardnummers en persoonsinformatie versleuteld op te slaan.

Het platform waar een webapplicatie en bijbehorende applicaties als databasesystemen op draaien is meestal het besturingssysteem van de server (Linux, Unix of Microsoft Windows). Net als de webapplicatie zelf is ook het platform kwetsbaar voor aanvallen van buiten.

Eén van de belangrijkste maatregelen op dit niveau is om altijd alle beveiligingsupdates op het platform door te voeren. Leveranciers van besturingssystemen doen veel moeite om eventuele beveiligingsproblemen zo snel mogelijk aan te pakken met updates. Zodra een update beschikbaar is, moet deze door de systeembeheerder getest en doorgevoerd worden. Naast het controleren van de gerealiseerde functionaliteit wordt de tester vaak ook vooraf betrokken bij het uitwerken van de wensen en eisen. Hij vervult dan de rol van functioneel analist en helpt de product owner om goede user stories op te stellen.

Moderne platformen zijn zeer uitgebreide en geavanceerde collecties van verschillende services. Vaak is maar een deel van deze services nodig voor het online aanbieden van de webapplicatie. Schakel daarom alle ongebruikte services uit, zodat die geen onnodig beveiligingsrisico vormen. Op een Microsoft Windows server gaat het dan bijvoorbeeld om de services Print Spooler en FTP

Vrijwel elk platform biedt de mogelijkheid om op lokaal niveau een firewall te configureren. Met een firewall wordt ongewenst dataverkeer automatisch tegengehouden

Heeft u weleens meegemaakt dat u naar een URL surfde en toen terecht kwam op een overzicht van mappen en bestanden, enigszins vergelijkbaar met die van de Explorer in Windows of de Finder in OS X? Als het mogelijk is om de mappen en bestanden van een server op die manier te bekijken, dan vormt dat een groot risico. Hackers kunnen op die manier immers meer te weten komen over de structuur van de server en soms zelfs belangrijke bestanden openen en uitlezen (zoals een wachtwoordbestand). Om die reden mag het nooit mogelijk zijn om een lijst van directories en files te bekijken.

Naast het applicatie- en het platformniveau is er nog een derde technisch niveau, namelijk dat van het netwerk. Het netwerk stelt de webapplicatie niet alleen beschikbaar aan de buitenwereld, maar zorgt er ook voor dat eventuele subsystemen (webserver, databaseserver, fileserver, caching server) met elkaar kunnen communiceren.

Een Single-Point-of-Failure is een enkel onderdeel dat, als het uitvalt, het complete systeem uit de lucht haalt. In missiekritieke systemen is het belangrijk dat alle onderdelen dubbel uitgevoerd worden. Mocht er één onderdeel uitvallen, dan kan het reserve-onderdeel het overnemen en blijft de dienstverlening beschikbaar.

Bij een “distributed denial of service”-aanval probeert de aanvaller om de website of webapplicatie plat te krijgen door er zoveel verkeer op af te sturen dat de systemen bezwijken. Er zijn verschillende soft- en hardwarematige oplossingen om het risico van een dDoS aanval te beperken.

Naast de maatregelen op de technische niveaus applicatie, platform en netwerk, zijn er ook meer algemene maatregelen. Deze hebben te maken met de wijze waarop de organisatie omgaat met de beveiliging van webapplicaties.

Hoe goed webdevelopers hun werk ook doen, het is altijd mogelijk dat er een beveiligingsrisico in de software voorkomt. Daarom is het belangrijk om regelmatig reviews op de broncode uit te voeren. Ook kunnen (geautomatiseerde) penetratietests en security scans van grote waarde zijn, zeker bij webapplicaties die te maken hebben met persoons- en/of patiëntgegevens.

Een werkende backup voorkomt niet dat er zich problemen voordoen, maar helpt wel om weer snel “up and running” te zijn mocht er onverhoopt wel iets mis gaan. Zorg er dus voor dat alle belangrijke onderdelen van het systeem gebackupped worden én dat de backup ook echt werkt, bijvoorbeeld door eens per maand een noodactie te simuleren.

Naast de bovenstaande aandachtspunten, die het risico op zwakke plekken in webapplicaties verminderen, zijn er tal van andere voorzorgsmaatregelen die genomen kunnen worden om de beveiliging van webapplicaties te verhogen. Wil je meer weten over de ontwikkeling van veilige webapplicaties, dan vertellen wij je daar graag meer over.