Een webapplicatie kan functioneel volledig klaar zijn voor gebruik en toch beveiligingsproblemen bevatten. Een succesvolle acceptatietest zegt immers vooral iets over de vraag of functionaliteiten werken zoals bedoeld. Het zegt veel minder over wat er gebeurt wanneer iemand de applicatie juist op een onverwachte manier gebruikt.
Dat maakt beveiliging een belangrijk aandachtspunt voordat een nieuwe applicatie in productie wordt genomen. Zeker wanneer gebruikers kunnen inloggen, er diverse rollen zijn, persoonsgegevens worden verwerkt of de applicatie via API’s met andere systemen communiceert.
Volledige zekerheid dat een applicatie geen enkele kwetsbaarheid bevat, bestaat niet. Wel zijn er verschillende manieren om het risico vóór de livegang aanzienlijk te verkleinen.
Security begint al tijdens de ontwikkeling
Beveiliging zou idealiter niet pas vlak voor de productierelease aandacht krijgen. Hoe eerder kwetsbaarheden worden gevonden, hoe eenvoudiger ze doorgaans zijn op te lossen.
Tijdens de ontwikkeling kunnen bijvoorbeeld maatregelen worden genomen om onveilige code en kwetsbare componenten vroegtijdig te signaleren. Denk aan code reviews, static application security testing (SAST), dependency scanning en controles op secrets die per ongeluk in broncode of repositories terechtkomen.
Ook het ontwerp van de applicatie speelt een belangrijke rol. Hoe wordt authenticatie geregeld? Welke gebruikersrollen zijn er? Welke gegevens mag een gebruiker bekijken of wijzigen? En welke systemen mogen onderling communiceren?
Wanneer dit soort vragen pas aan het einde van het ontwikkeltraject wordt gesteld, kunnen beveiligingsproblemen inmiddels diep in de architectuur of businesslogica van de applicatie zijn verwerkt.
Een vulnerability scan is een nuttige eerste controle
Geautomatiseerde vulnerability scanners kunnen relatief snel bekende technische kwetsbaarheden detecteren. Ze kunnen bijvoorbeeld verouderde software, bepaalde configuratiefouten en bekende kwetsbaarheidspatronen herkennen.
Dat maakt vulnerability scanning waardevol, maar niet voldoende om vast te stellen dat een webapplicatie veilig is.
Een vulnerability scanner begrijpt namelijk niet altijd hoe een applicatie echt zou moeten functioneren. Stel dat een gebruiker zijn eigen facturen mag downloaden. Technisch werkt het endpoint correct en bevat het misschien geen bekende softwarekwetsbaarheid. Maar wat gebeurt er als de gebruiker het nummer van een factuur in het verzoek verandert?
Als daarmee de factuur van een andere klant kan worden opgehaald, is sprake van een ernstig autorisatieprobleem. Juist dit soort kwetsbaarheden vereist inzicht in de werking en context van de applicatie.
Besteed extra aandacht aan authenticatie en autorisatie
Bij applicaties met gebruikersaccounts is het niet alleen belangrijk om te controleren of iemand kan inloggen, maar vooral wat die gebruiker daarna kan doen.
Een veelvoorkomende fout is dat toegangsbeperkingen voornamelijk in de gebruikersinterface worden afgedwongen. Een bepaalde knop is bijvoorbeeld niet zichtbaar voor een gewone gebruiker, terwijl het achterliggende API-endpoint nog wel rechtstreeks kan worden aangeroepen.
Daarom moeten autorisatiecontroles aan de serverzijde worden afgedwongen.
Bij meerdere gebruikersrollen wordt dit al snel complexer. Een medewerker mag bijvoorbeeld gegevens bekijken, een manager mag deze wijzigen en alleen een beheerder mag accounts verwijderen. Voor iedere gevoelige actie moet worden gecontroleerd of de gebruiker daadwerkelijk over de benodigde rechten beschikt.
Daarnaast moet horizontale autorisatie worden getest. Een gebruiker met de juiste rol mag immers nog steeds niet automatisch toegang krijgen tot gegevens van een andere gebruiker, klant of organisatie.
Vergeet de API niet
Moderne webapplicaties bestaan zelden alleen uit een frontend en een traditionele backend. Functionaliteit en gegevens worden vaak via REST- of GraphQL-API’s beschikbaar gesteld en daarnaast kunnen externe diensten worden geïntegreerd.
Daardoor vormt de API een belangrijk onderdeel van het aanvalsoppervlak.
Het is niet voldoende om alleen via de normale gebruikersinterface te testen. Een aanvaller kan rechtstreeks requests naar API-endpoints sturen en daarbij parameters, identifiers, headers en andere invoer aanpassen.
Belangrijke vragen zijn bijvoorbeeld:
- kan een gebruiker gegevens opvragen die niet voor hem bedoeld zijn?
- zijn gevoelige acties voldoende geautoriseerd?
- kan invoer worden gemanipuleerd om controles te omzeilen?
- geven foutmeldingen onnodig technische of gevoelige informatie prijs?
- kunnen endpoints worden aangeroepen buiten de workflow waarvoor ze zijn ontworpen?
Een frontend kan bepaalde acties onmogelijk maken, terwijl de achterliggende API ze nog gewoon accepteert.
Businesslogica verdient afzonderlijke aandacht
Niet iedere beveiligingsfout is een technische kwetsbaarheid.
Een webshop kan technisch bijvoorbeeld uitstekend beveiligd zijn tegen SQL-injectie en cross-site scripting, maar alsnog toestaan dat een kortingscode onbeperkt wordt gebruikt. Of een gebruiker kan een proces in een onverwachte volgorde doorlopen waardoor een betaling of controle wordt overgeslagen.
Dit zijn kwetsbaarheden in de businesslogica.
Welke scenario’s relevant zijn, verschilt sterk per applicatie. Bij een webshop kunnen prijzen, kortingscodes en bestelprocessen belangrijk zijn. Voor een SaaS-platform ligt de nadruk mogelijk op gebruikersrollen en de scheiding tussen verschillende klanten. Bij een financieel platform zijn transacties en goedkeuringsprocessen weer belangrijker.
Juist omdat deze kwetsbaarheden afhankelijk zijn van de specifieke werking van een applicatie, zijn ze lastig volledig geautomatiseerd te detecteren.
Controleer ook de productieconfiguratie
Veilige code kan alsnog onveilig worden uitgerold.
Daarom verdient ook de configuratie rondom de applicatie aandacht. Denk bijvoorbeeld aan verkeerd ingestelde toegangsrechten, publiek bereikbare beheerinterfaces, gevoelige informatie in foutmeldingen, onvoldoende beveiligde cookies of secrets die op een verkeerde plaats worden opgeslagen.
Ook het verschil tussen ontwikkel-, test- en productieomgevingen is relevant. Testaccounts, debugfunctionaliteit en tijdelijke configuraties horen niet ongemerkt in productie terecht te komen.
Een goede securitycontrole kijkt daarom verder dan alleen de broncode.
Test de applicatie vanuit het perspectief van een aanvaller
Voor belangrijke webapplicaties kan het verstandig zijn om vóór de livegang een pentest uit te voeren.
Bij een pentest probeert een securityspecialist kwetsbaarheden daadwerkelijk te vinden en waar mogelijk gecontroleerd te misbruiken. Daarbij wordt niet alleen gekeken naar bekende technische kwetsbaarheden, maar ook naar bijvoorbeeld authenticatie, autorisatie, API’s, gebruikersrollen en businesslogica.
Het voordeel daarvan is dat verschillende zwakke plekken ook in samenhang kunnen worden onderzocht. Een afzonderlijke configuratiefout heeft misschien beperkte impact, maar kan in combinatie met een autorisatieprobleem ineens toegang geven tot gevoelige gegevens.
Een goede pentest van een webapplicatie kijkt daarom niet alleen naar een standaardlijst met kwetsbaarheden, maar naar de aanvalspaden die specifiek voor de betreffende applicatie relevant zijn.
Wanneer is een applicatie klaar voor productie?
Er bestaat geen certificaat waarmee kan worden gegarandeerd dat een webapplicatie volledig veilig is. Het doel is daarom niet om ieder denkbaar risico uit te sluiten, maar om voldoende zekerheid te krijgen dat belangrijke beveiligingsrisico’s zijn geïdentificeerd en beheerst.
Voor een productie-release zou in ieder geval duidelijk moeten zijn dat:
- beveiliging tijdens ontwikkeling structureel aandacht heeft gekregen
- dependencies en bekende kwetsbaarheden worden beheerd
- authenticatie en autorisatie aantoonbaar correct functioneren
- API’s dezelfde toegangscontroles afdwingen als de applicatie zelf;
- relevante businesslogica op misbruikscenario’s is getest
- gevoelige gegevens en secrets voldoende zijn beschermd
- de productieomgeving veilig is geconfigureerd
- belangrijke bevindingen uit securitytests vóór livegang zijn opgelost of bewust als risico zijn geaccepteerd.
Hoe uitgebreid deze controles moeten zijn, hangt af van het risicoprofiel van de applicatie. Een eenvoudige interne applicatie zonder gevoelige gegevens vraagt om een andere testdiepgang dan een SaaS-platform met duizenden gebruikers, verschillende rollen en persoonsgegevens.
Veilig naar productie betekent risico’s beheersen
De vraag of een webapplicatie veilig genoeg is voor productie kan uiteindelijk niet met één scan of checklist worden beantwoord.
Een veilige release ontstaat uit meerdere lagen: veilig ontwerp, secure development, geautomatiseerde controles, goede configuratie en handmatige securitytests waar dat nodig is.
Daarbij is vooral de context van belang. Welke gegevens verwerkt de applicatie? Welke rechten hebben gebruikers? Welke systemen zijn gekoppeld? En wat zou een aanvaller daadwerkelijk kunnen bereiken wanneer een beveiligingsmaatregel niet werkt zoals bedoeld?
Door die vragen vóór de livegang te beantwoorden, wordt security geen laatste controle aan het einde van het project, maar een onderdeel van een gecontroleerde en verantwoorde productie-release.