Web Application Security Testing

In een recent LinkedIn bericht hebben we kort het verschil tussen web application security testing en web application pentesting behandeld. In dit blog wordt uitgebreider ingegaan op web application security testing en het belang van dit soort testen voor een organisatie.

We zullen kort toelichten wat web application security testing is, waarom het een goed idee is, wat de consequenties kunnen zijn als er niet getest wordt en we sluiten af met hoe web application security testing de gevolgen van een aanval beperkt. Dit alles uiteraard met nog een mooi stukje nawoord van de afdeling sales.

Web application security testing is een proces waarbij, op gestructureerde wijze, diverse kwetsbaarheden worden geïdentificeerd, voorkomen en gemitigeerd in webapplicaties. De eerste vraag die dan misschien opkomt is: wat is dan precies een webapplicatie?

Nu is er altijd enige discussie mogelijk, want is een compleet statische informatieve website echt een applicatie? Maar laten we aannemen dat anno 2025 dit soort websites voornamelijk draait in een Content Management Systeem hetgeen ook een webapplicatie is. Als definitie zullen we dan ook voor het gemak aannemen: eigenlijk alles wat middels de webbrowser werkt is een webapplicatie.

Met kwetsbaarheden worden zwaktes bedoeld in een webapplicatie die door een aanvaller misbruikt kunnen worden om een succesvolle aanval uit te voeren. Deze kunnen bijvoorbeeld ontstaan door programmeerfouten, falende logica, kwetsbare componenten en configuratiefouten.

In een tijd waarbij nagenoeg elke organisatie afhankelijk is van webgebaseerde applicaties (en cloud infrastructuur, maar dat is weer een ander verhaal) is het testen van de beveiliging van deze webapplicaties dan ook cruciaal.

Voor sommige organisties gelden er verplichtingen vanuit zelf (of vanuit de branche) opgelegde normen zoals de ISO 27001 en NEN 7510. Soms volgen er verplichtingen vanuit wet- en regelgeving zoals bijvoorbeeld de NIS2 en DORA verordeningen. Zelfs als het niet op een dergelijke wijze verplicht is, geldt er eigenlijk een morele verplichting voor iedere aanbieder van webapplicaties.

De gevolgen en schade van een succesvolle aanval kunnen namelijk enorm zijn voor klanten, cliënten, medewerkers en de organisatie zelf. 

Een geslaagde aanval kan vele gevolgen hebben en meestal blijft het niet beperkt tot één gevolg maar is het een combinatie van gevolgen. Al deze gevolgen zorgen voor schade bij de organisatie zelf en in sommige gevallen ook voor aansprakelijkheid voor de schade bij derden. Denk bijvoorbeeld aan:

Operationele schade.
Dit kan zich op verschillende wijze openbaren denk bijvoorbeeld aan een website die beklad wordt, beschadigd (en in sommige gevallen zelfs misbruikt wordt om schade bij derden aan te richten) of slecht en in sommige gevallen helemaal niet meer bereikbaar is. Uiteraard brengt herstel ook weer de nodige financiële schade met zich mee.

Bezoekers en klanten hebben snel een oordeel. Recentelijk is er in korte tijd sprake geweest van een storing waardoor een bankapplicatie in korte tijd meerdere malen niet beschikbaar was. Het commentaar op internet was niet mals en als je die betaling die vandaag moest gebeuren niet kan uitvoeren dan wordt er al snel aan een andere aanbieder gedacht. Vertrouwen komt te voet en gaat te paard, al helemaal als gegevens van gebruikers en klanten op straat komen te liggen.
 
Financiële schade
Dit vindt eigenlijk in alle gevallen plaats. Het kost tijd en geld om de webapplicatie te herstellen, door het niet bereikbaar zijn loopt de organisatie omzet mis en door het lekken van gegevens gaat vertrouwen in de organisatie verloren. Denk ook aan boetes die toezichthouders op kunnen leggen  indien er niet voldaan is aan de zorgplicht, die zijn niet mals.

 Al met al reden genoeg om als organisatie al het mogelijke te doen om de risico’s te beperken.

Er zijn geen garanties en risico’s zijn ook nooit volledig uit te sluiten. Wel is het mogelijk om middels web application security testing deze risico’s te minimaliseren en daarmee ook invulling te geven aan een zorgplicht om informatiebeveiliging serieus te nemen.

Door het kijken naar en testen van verschillende aspecten van de webapplicatie kunnen veel voorkomende kwetsbaarheden op voorhand worden geïdentificeerd en verholpen in plaats van achteraf de schade te verhelpen. 

Zeer belangrijk is om dit op een gestructureerde wijze te doen zodat ook echt alles onder de loep wordt genomen en er geen belangrijke onderdelen worden overgeslagen. Binnen StackSecure wordt daarom gebruik gemaakt van bekende en erkende frameworks en standaarden welke worden gecombineerd met een flinke dosis eigen ervaring. 

Het proces begint met het vaststellen van de scope, dit betekent eigenlijk het bepalen van de spelregels (wat gaan we doen en wat niet) in overleg met de opdrachtgever. Als dit duidelijk is worden de tests uitgevoerd binnen een afgesproken termijn en uiteindelijk worden de resultaten met de adviezen opgenomen in een gedegen rapport waar het management, beheerders en ontwikkelaars mee aan de slag kunnen. 

Let wel, het is een continu proces en geen eenmalige exercitie. Zeker in het speelveld van de informatiebeveiliging waar dagelijks nieuwe kwetsbaarheden worden gevonden en nieuwe technieken worden bedacht. Om deze reden wordt dan ook verplicht of geadviseerd om dit proces minimaal elk jaar te herhalen.

Bij StackSecure hebben we een passie voor informatiebeveiliging in al zijn aspecten. Van het zorgen voor awareness bij medewerkers tot het schrijven en implementeren van beleid en alles daartussenin.  

De ethische hackers van StackSecure onderwerpen uw applicatie (en onderliggende infrastructuur) dan ook graag aan een grondige test zodat uw organisatie weerbaar is en blijft tegen kwaadwillenden met vervelende intenties.

Ongeacht de omvang van de applicatie of applicaties denken we graag met mee over de juiste aanpak. Neem gerust contact met ons op.