Web Application Firewall: wat is het en hoe werkt het?
26 oktober 2020 | Beveiliging | Geschreven door: Matthijs Möhlmann
Tips om je site of applicatie optimaal te beveiligen
Wordt je site of applicatie regelmatig aangevallen? En doe je telkens kleine configuratieaanpassingen? Blijft het dan een paar dagen rustig en begint daarna het hele feest opnieuw?
Herkenbaar!
Een van onze klanten heeft een website waarop je beltegoed, iTunes-kaarten en gamecards kan kopen. Een website met veel privacygevoelige en financiële informatie en dus met een magnetische aantrekkingskracht op hackers.
We bleven zoeken naar oplossingen, maar konden moeilijk achterhalen waar de problemen ontstonden. De logs gaven ons te weinig duidelijkheid over wat er aan de hand was.
Maar er móést toch een manier zijn om aanvallen te voorkomen? Een werkwijze die ervoor zorgt dat een website veilig is en blijft?
We zochten een fundamentele oplossing. En die hebben we gevonden: Web Application Firewall (WAF).
Door de inzet van een WAF hebben de hackers geen succesvolle aanvallen meer gepleegd op de site van onze klant.
Yes! Dat is precies wat we wilden.
In dit artikel vertel ik je meer over wat een WAF is en wat je ermee kunt doen. Ik geef je ook inzage in de beperkingen en risico’s. En ik ga het hebben over het belang van testen.
Wat is een Web Application Firewall (WAF)
Een firewall is een systeem dat een site of applicatie beschermt tegen misbruik van buitenaf. Er zijn verschillende soorten firewalls en die houden allemaal malafide informatie tegen. In feite is een virusscanner of SPAM-filter ook een firewall. Die houden echter niet alles tegen, maar kijken naar de informatie die wordt opgehaald en verstuurd, en checken of het veilig is. Informatie wordt tegen gehouden op basis van bepaalde regels.
Dat is simpel gezegd ook wat een WAF doet.
Een WAF kijkt naar websites, e-commerceplatformen en webapplicaties. De WAF zitten tussen de browser en de server, dus vóór de applicatie of site. De WAF monitort en analyseert het verkeer en stuurt het verkeer door. Maar als de WAF wordt getriggerd door een bepaalde regel, dan zegt de WAF: ‘Ho, stop, niet verder.’
WAF: positive security model en negative security model
Er zijn twee soorten Web Applications Firewalls: het positive security model en negative security model.
Positive security model
Dit model wordt ook wel het ‘Whitelist model’ genoemd. Dit beveiligingsmodel houdt in feite alle verkeer tegen, maar staat bepaalde dingen toe, zoals het opvragen van de homepage, het versturen van contactgegevens via een contactpagina enzovoort. Daarnaast kun je ook bezoekers whitelisten op basis van geografische locatie. De beveiligingsgraad van het positive security model is hoog, maar dat geldt ook voor de implementatietijd. Het is een enorm karwei om dit model te implementeren en te controleren of het werkt.
Negative security model
Het negative security model is een ‘Blacklist model’. Het staat alle verkeer toe, maar houdt bepaalde zaken tegen op basis van regels. Hierdoor kunnen bedreigingen en frauduleuze interacties (denk hierbij aan cross-site scripting en SQL-injecties) worden gedetecteerd en tegengehouden voordat de aanval de applicatie of site bereikt.
Het negative security model is minder veilig dan het positive security model, maar het is wel veel gemakkelijker op te zetten. Daarom hebben wij ervoor gekozen om te werken op basis van het negative security model. We hebben een uitgebreide regelset en we weten inmiddels dat we daarmee goede bescherming bieden tegen hackers en andere aanvallen.
Extra voordelen én voorbeelden
Een WAF maakt het ook mogelijk om verkeer te monitoren. Het geeft realtime inzicht en laat zien waar het fout is gegaan. Dat betekent dat we ontwikkelaars kunnen vertellen waar ze codes moeten aanpassen om veiligheidsbreuken te repareren.
Daarnaast kun je een WAF ook prima gebruiken voor rate limiting.
Voorbeeld 1: WAF en SQL-injectie*
Bij deze SQL-injectie wordt de gebruikersinvoer niet (goed) gevalideerd waardoor het mogelijk is om meer data uit de database te halen dan de bedoeling is.
De variabele '$user_id' is in dit voorbeeld een vrij in te vullen veld; hierdoor is het mogelijk dat er in plaats van een getal iets anders ingevuld kan worden.
Als er bijvoorbeeld '105 OR 1=1' wordt ingevuld, wordt effectief de query aangepast en is er een mogelijkheid ontstaan dat alle data kan worden opgehaald.
SELECT * FROM users WHERE id = 105 wordt dus SELECT * FROM users WHERE id = 105 OR 1=1
In plaats van één gebruiker op te halen worden dan alle gebruikers opgehaald.
Dat is uiteraard niet de bedoeling en kan door een Web Application Firewall worden tegengehouden. Uiteraard is het beter om deze problemen helemaal te voorkomen door de gebruikersinvoer te valideren.
Voorbeeld 2: WAF en cross side scripting*
Een voorbeeld van een cross side scripting bug:
De gebruikersdata wordt (weer) niet gevalideerd waardoor het mogelijk is om allerlei data in de website in te voeren. Stel dat deze informatie in de database opgeslagen wordt, dan kunnen stukjes javascriptcode uitgevoerd worden op de systemen van bezoekers. Met alle gevolgen van dien.
Als het stukje code wordt aangeroepen als:
example.com/cross-side-scripting.php?request_id=<script>alert('hallo');</script> dan wordt de '$request_id' gevuld met een script dat vervolgens uitgevoerd wordt door de browser.
Uiteraard is dat niet de bedoeling. Je voorkomt het door gebruikersdata te valideren of de uitvoer naar de browser goed te valideren. Ook hierbij kan de Web Application Firewall helpen om een succesvolle aanval te voorkomen.
* Dit zijn twee heel eenvoudige voorbeelden die uitsluitend ter illustratie zijn bedoeld. Doorgaans komen wij veel complexere structuren tegen die allemaal met een WAF kunnen worden opgelost.
Een WAF is geen wondermiddel
Hoewel we een WAF een geweldige tool vinden, is het geen wondermiddel. Als er op applicatieniveau dingen misgaan of worden vergeten, dan kan ook een WAF niet alle frauduleuze verkeer tegenhouden.
- Als het authenticatieproces niet op orde is en er worden bijvoorbeeld zwakke encryptiemethoden gebruikt, dan krijgt frauduleus verkeer toch toegang.
- Als de toegangscontrole zwak is, dan kunnen mensen met minder rechten toch toegang krijgen tot andere gegevens.
- Als de meest kritieke beveiligingsrisico’s voor webapplicaties niet worden aangepakt of de reparatie ervan door tijdgebrek wordt uitgesteld, dan blijft de applicatie kwetsbaar.
- Een WAF is geen lapmiddel, maar een waardevolle aanvulling op de beveiligingsmaatregelen die al zijn genomen.
Een WAF is geen lapmiddel, maar een waardevolle aanvulling op de beveiligingsmaatregelen die al zijn genomen.
De risico’s van WAF
Het werken met een WAF brengt ook risico’s met zich mee.
Ken je het spreekwoord ‘Blaffende honden bijten niet’? Nou, een WAF doet ook geen vlieg kwaad als die te ruim is opgezet. Dan creëert de firewall slechts schijnveiligheid. Dat kan gevaarlijk zijn, omdat je niet de maatregelen treft die ervoor zorgen dat je site of webapp optimaal beschermd is tegen aanvallen van buitenaf.
Als je een WAF ondoordacht inzet, kan je website zelfs omrollen. Dat wil je natuurlijk koste wat kost voorkomen. Het is daarom belangrijk om de WAF eerst in de ontwikkelomgeving te testen. Probeer het uit en onderzoek of het werkt: plaats een bestelling, verstuur een ingevuld contactformulier enzovoort. Pas als het werkt, zet je de WAF door naar de productieomgeving. Gebruik bij voorkeur een OTAP-ontwikkelstaat om de WAF te testen.
Meer weten over WAF?
Wil je meer weten over Web Application Firewalls en welke andere beveiligingsmaatregelen je kunt nemen om je site of applicatie optimaal te beveiligen? Neem dan contact op. We adviseren en helpen je graag bij het opzetten van beveiligingsmaatregelen en het beheren van online applicaties.
