Het beveiligen van webapplicaties en de OWASP Top 10

Home / Blog / Applicatieontwikkeling / Het beveiligen van webapplicaties en de OWASP Top 10

Ransomware, phishing, identity theft, botnets, datalekken. Ze zijn aan de orde van de dag. Als software ontwikkelaar is het van belang dat je beveiliging op orde is. De beveiliging van je organisatie, je laptop, je servers en natuurlijk je webapplicatie zelf. Een van de hulpmiddelen om je webapplicatie veilig te bouwen is de OWASP Top 10.

OWASP Top 10 – 2021

OWASP is de  afkorting van Open Web Application Security Project. Dit is een open source project rondom beveiliging op het internet. Ze organiseren evenementen, geven trainingen, delen informatie en leveren tools. Elke 4 jaar publiceren ze de Top 10 van de grootste beveiligingsuitdagingen bij het bouwen van websites. Als ontwikkelaar dien je deze maar beter te kennen en op de hoogte te zijn van de maatregelen die je kunt nemen om de uitdagingen het hoofd te bieden. Eind 2021 is er een nieuwe versie van de OWASP Top 10 uitgekomen. Hoogste tijd om te kijken wat op dit moment de 10 grootste beveiligingsrisico’s zijn.

Een aantal opvallende zaken: Er is een nieuwe nummer 1! Sinds jaar en dag was de nummer 1 “Injection”. Nu is het niet zo dat injection niet meer voorkomt, maar deze uitdaging is gezakt naar plaats 3. Ook hebben we 3 nieuwe binnenkomers, zijn er enkele zaken samengevoegd en hebben een aantal onderdelen een andere naam gekregen.

Hieronder zie je de Top 10 en hoe de zaken veranderd zijn sinds 2017.

Laten we kijken naar de verschillende categorieën in de 2021 Top 10.

Nr.1 Broken Access Control

Een webapplicatie bevat over het algemeen een vorm van toegangsbeheer. Een gebruiker krijgt bepaalde toegangsrechten. Wanneer het mogelijk is dat een gebruiker toegang krijgt tot informatie zonder dat dit de bedoeling is, dan spreken we over “broken access control”.

Deze categorie is maar liefst 4 plekken gestegen van nr. 5 in 2017 naar nr. 1 in 2021. Van de geteste applicaties bevatte 94% een vorm van “broken access control”. Dat is schokkend veel! Het is wel een behoorlijk brede categorie. Je toegangsbeheer kan op verschillende manieren kwetsbaar zijn. Hierbij kun je denken aan:

• URL’s aanpassen om zo andere content te kunnen bekijken.
• Rechten aanpassen door het modificeren van tokens of client side objecten.
• API’s zonder de juiste beveiliging.
• Fouten in de Cross Origin configuratie.

Mogelijke oplossingen en tips:

• Informatie dient standaard beveiligd te zijn, tenzij het expliciet publiekelijk beschikbaar is gemaakt (in plaats van andersom).
• Bouw niet telkens een nieuw toegangsbeheersysteem, maar bouw 1 keer een betrouwbaar systeem en hergebruik dat. Onderhoud en beveiligingsupdates zijn zo beter uit te voeren.
• Log de toegang en breng de admin op de hoogte bij vermoedelijk misbruik.
• Limiteer het aantal keer dat een toegangsverzoek uitgevoerd kan worden, door bijvoorbeeld een wachtmechanisme toe te voegen bij een verkeerde inlogpoging.

Nr. 2 Cryptographic Failures

Informatie dient in de meeste situaties beveiligd te worden. Afhankelijk van de gegevens zijn er verschillende eisen voor wat betreft opslag en transport (over de lijn). Denk hierbij bijvoorbeeld aan de AVG. In de meeste gevallen zal de data versleuteld verstuurd worden (HTTPS), maar ook bij de opslag van gegevens komt vaak versleuteling kijken.

Hier kunnen veel fouten gemaakt worden:

• Versleuteling wordt niet afgedwongen (bijvoorbeeld een website die ook via HTTP benaderbaar is).
• De trust-chain van certificaten wordt niet goed gecontroleerd.
• De sleutel (zoals wachtwoord) voor de versleuteling is te ‘zwak’ of wordt hergebruikt op verschillende plekken.
• Verouderde of zwakke versleutelingsmechanismes worden gebruiken.

Mogelijke oplossingen en tips:

• Zorg voor een juiste classificatie van de gegevens en bepaal hoe de data versleuteld dient te worden.
• Sla geen overbodige gegevens op (Zie ook ons artikel over Privacy by design).
• Gebruik moderne en sterke versleuteling.
• Versleutel ook de opgeslagen data (in databases en in bestanden).
• Gebruik sterke en unieke sleutels, die veilig worden opgeslagen.

Nr. 3 Injection

Ondanks dat deze categorie 2 plekken gezakt is, wil dat niet zeggen dat Injection minder voor komt. Sterker nog: 94% van de geteste applicaties was kwetsbaar voor een vorm van Injection.

Er zijn een aantal bekende manier van injection. 

• Bij SQL Injection worden SQL opdrachten geïnjecteerd in een andere SQL opdracht waardoor de database ongeoorloofd gegevens uitleest, aanpast of verwijdert. Over SQL injection heb ik eerder een uitgebreid artikel geschreven.
• Bij Cross-site Scripting injecteert iemand een stuk JavaScript in een webpagina zodat de applicatie ongeoorloofde acties uitvoert. Hierdoor kunnen bijvoorbeeld gegevens van andere gebruikers gestolen worden of een website onbruikbaar worden gemaakt.

Mogelijke oplossingen en tips:

• Zorg ervoor dat de input van gebruikers altijd gevalideerd en opgeschoond wordt (op de server).
• Gebruik geparametriseerde queries.

Nr. 4 Insecure design

De hoogste nieuwe binnenkomer in de 2021 Top 10 is onveilig ontwerp. Bij een onveilig ontwerp kan er natuurlijk ontzettend veel mis gaan. Dit onderwerp is daarom meer gericht op het proces dan op specifieke technische zaken. Bij het ontwerpen van software wordt hoofdzakelijk gedacht aan functionaliteiten en infrastructuur. Het wordt echter steeds belangrijker om vanaf het allereerste stadium rekening te houden met en na te denken over beveiliging. Dus voordat er code geschreven wordt, moet de beveiligingsoplossing duidelijk zijn.

Mogelijke oplossingen en tips:

• Plan een “Thread modelling workshop” aan het begin van het project. Hierbij betrek je de verschillende stakeholders en breng je de mogelijke kwetsbaarheden in beeld. Je krijgt hierdoor een goed overzicht van de mogelijke “aanvallen” die bewust of onbewust uitgevoerd kunnen worden, hoe groot het risico is en wat de omvang van de schade is. Naar aanleiding van de thread modeling workshop kun je rekening houden met deze bedreigingen in het ontwerp van de applicatie.
• Maak het nadenken over beveiliging een onderdeel van je werkproces. Bijvoorbeeld: voeg bij het aanmaken van product backlog items een verplicht veld toe waar beveiligingsoverwegingen ingevuld dienen te worden.

Nr. 5 Security Misconfiguration

In deze categorie worden de beveiligingsproblemen ondergebracht die te maken hebben met verkeerde configuratie. Over het algemeen zijn dit dus geen fouten in de programmacode, maar door verkeerde of ontbrekende instellingen van frameworks of servers ontstaat er een onveilige situatie. Voorbeelden hiervan zijn:

• Ongebruikte features die toch beschikbaar zijn. Bijvoorbeeld mogelijkheden van een webserver, poorten op een firewall of services die actief zijn op een server.
• “Standaard” accounts die nog actief zijn (en eventueel met het standaard wachtwoord), zoals een admin account op een database server.
• Foutmeldingen met gedetailleerde informatie op het scherm van de gebruiker tonen. In sommige gevallen kun je zelfs stukken code of de call stack te zien krijgen. Uit deze informatie kunnen hackers over het algemeen heel veel bruikbare informatie halen.

Mogelijke oplossingen en tips:

• Schakel ongebruikte onderdelen uit.
• Zorg voor identieke omgevingen voor Test, Acceptatie en Productie.
• Gebruik Infrastructure as Code om installaties herhaalbaar te maken en identiek te houden.
• Toon geen technische details in foutmeldingen die eindgebruikers te zien krijgen.

Nr.6 Vulnerable and outdated components

Bij het ontwikkelen van software wordt zeer veelvuldig gebruik gemaakt van externe frameworks en libraries. Dit maakt het mogelijk om effectief software te ontwikkelen en gebruik te maken van herbruikbare software onderdelen waarbij complexe functionaliteit door een specifiek component wordt uitgevoerd. Dit kunnen open-source componenten zijn, maar ook componenten van betaalde leveranciers. Dergelijke componenten krijgen functionele updates, maar ook beveiligingsproblemen worden opgelost. Het is een groot gevaar dat de componenten in de webapplicatie niet worden bijgewerkt naar de laatste versie wanneer dergelijke (beveiligings)updates worden uitgebracht. Er is immers een bekend beveiligingslek en de webapplicatie is dus kwetsbaar. Het is een grote uitdaging om van alle gebruikte componenten in de gaten te houden:

• welke versies er gebruikt worden;
• of er beveiligingsrisico’s zijn;
• of er breaking-changes zijn wanneer het component bijgewerkt wordt.

Toch is het aan te raden om gebruik te maken van externe componenten. Omdat ze vaak een specifiek probleem oplossen en er met een (grote) groep ontwikkelaars aan gewerkt wordt, is de beveiliging vaak goed op orde. Als er problemen mee zijn worden die snel opgespoord en opgelost.

Mogelijke oplossingen en tips:

• Verwijder niet-gebruikte componenten.
• Controleer regelmatig of er (beveiligings)updates beschikbaar zijn.
• Automatiseer dit proces zodat er ook waarschuwingen zijn voor applicaties waaraan niet ontwikkeld wordt, maar die wel online zijn. Hier is vaak tooling voor zoals “NPM audit” en “Dependabot”.
• Plan sprints om upgrades met breaking-changes uit te voeren.

Nr. 7 Identification and Authentication Failures

In deze categorie vallen alle zaken rondom authenticatie, oftewel problemen bij het achterhalen wie de gebruiker is. Dit heeft hoofdzakelijk te maken met problemen rondom het inlogproces.

Denk hierbij aan:

• De mogelijkheid om grote hoeveelheden inlogpogingen uit te voeren.
• Toestaan van zwakke of veel voorkomende wachtwoorden.
• Niet versleutelen van login gegevens.
• Makkelijk te achterhalen sessie-informatie (bijvoorbeeld in de URL).
• Ontbreken van of onvolledige functionaliteit om uit te loggen.
• Het ontbreken van multi-factor authenticatie.

Mogelijke oplossingen en tips:

• Maak (verplicht) gebruik van multi-factor authenticatie.
• Controleer op sterke wachtwoorden.
• Bouw een (progressieve) vertraging in tussen inlogpogingen.
• Zorg dat accounts en/of wachtwoorden nooit mee worden gedeployed van een testomgeving naar een productieomgeving.

Nr. 8 Software en Data integrity failures

Deze categorie is nieuw in de OWASP Top 10. De beveiligingsproblemen in deze categorie hebben betrekking op het gebruik maken van externe software, zoals componenten, data of CI/CD pipelines zonder de integriteit te controleren. 

• Wanneer een applicatie gebruik maakt van een externe bron (zoals via een CDN) moet goed gecontroleerd kunnen worden of deze bron ook betrouwbaar is. 
• De integriteit van de CI/CD pipelines is ook belangrijk om er zeker van te zijn dat er geen ongeoorloofde aanpassingen doorgevoerd kunnen worden aan het release-proces.
• Data integriteit is ook belangrijk wanneer er data van de client naar de server wordt gestuurd. Denk hierbij bijvoorbeeld aan JSON objecten die naar de server worden gestuurd en daar gebruikt worden zonder controle op de integriteit.

Mogelijke oplossingen en tips:

• Gebruik componenten met digitale signature waar mogelijk.
• Gebruik betrouwbare leveranciers van componenten.
• Beveilig de CI/CD pipelines goed.
• Dwing een 4 ogen principe af door verplichte Pull Request reviews.
• Controleer de integriteit van ontvangen gegevens.

Nr. 9 Security Logging and Monitoring Failures

Dit onderwerp heeft betrekking op het loggen van gebeurtenissen en het monitoren van deze logs. Naast het loggen van foutmeldingen is het ook erg belangrijk om authenticatie te loggen. Wanneer er zich een beveiligingsprobleem heeft voorgedaan, is het belangrijk te weten wie, waar en wat er gebeurd is. Ook is het goed om te beseffen dat alleen het loggen niet de oplossing is. Er moet ook naar de log gekeken worden en dan bij voorkeur geautomatiseerd, zodat continu in de gaten gehouden wordt of er (combinaties van) gebeurtenissen plaatsvinden waarop actie ondernomen moet worden. Ook volgens wet- en regelgeving zoals AVG is logging in veel gevallen verplicht. Deze moet dus ook op een adequate wijze worden opgeslagen en beveiligd.

Bij beveiligingsproblemen kun je denken aan:

• Ontbreken van logging voor logins (mislukte én geslaagde logins).
• Ontbreken van AVG verplichte logging zoals wijzigingen in persoonlijke gegevens.
• Logbestanden worden niet op de juiste (veilige) manier opgeslagen en/of bevatten persoonlijke data zonder dat daar een goede reden voor is.
• Ontbreken van een alarmeringssysteem bij verdachte gebeurtenissen.

Mogelijke oplossingen en tips:

• Log niet alleen de mislukte logins (deze zijn er blijkbaar toch niet in geslaagd om binnen te komen), maar ook alle geslaagde logins (deze hebben wel toegang gehad tot de applicatie).
• Log volgens wet- en regelgeving:
  • Vermijd persoonlijke data in logbestanden zoveel mogelijk. 
  • Logbestanden waarin persoonlijke data wordt opgenomen (zoals een audit log met wijzigingen van persoonlijke data) dient alleen toegankelijk te zijn volgens vastgelegde protocollen.
• Ontwikkel monitoring en alarmering of gebruik software die dit voor je uit handen neemt.

Nr. 10 Server-Side Request Forgery (SSRF)

Niet te verwarren met de bekende Cross-Site Request Forgery die in de OWASP Top 10 van 2013 nog aanwezig was.

Het komt vaak voor dat verschillende software systemen met elkaar communiceren. Het is ook niet ongebruikelijk dat het mogelijk is om in een webapplicatie een URL op te geven naar een extern systeem (API), waar de betreffende applicatie gegevens kan uitvragen. Een “Server-side request” wordt dan dus uitgevoerd. Echter wanneer de URL niet afdoende gecontroleerd of gelimiteerd wordt, is het mogelijk om hier misbruik van te maken:

• De request bevat interne (IP) adressen om zo het interne netwerk in kaart te brengen.
• De request bevat specifieke poorten om te controleren welke poorten open staan op interne servers of op de firewall.
• De request bevat een pad naar een bestand op de server (om zo bijvoorbeeld configuratiebestanden met connection strings en andere geheimen uit te lezen).
• De webserver werkt onbedoeld mee aan een DDoS aanval.

Mogelijke oplossingen en tips:

• Segmenteer het netwerk zodat de webapplicatie niet bij de rest van het netwerk kan komen.
• Laat alleen verkeer toe dat expliciet is toegestaan (bijvoorbeeld alleen poort 443).
• Log alle communicatie.
• Valideer de verstuurde en ontvangen gegevens.
• Sta geen HTTP Redirection toe.

Verdere overwegingen

De OWASP Top 10 is dus belangrijke kennis voor elke ontwikkelaar. Maar daar moet het natuurlijk niet bij blijven. 

• Houd elkaar scherp en probeer de adviezen van de OWASP top 10 ook goed na te leven. 
• Werk volgens Security-by-Design en Privacy-by-Design.
• Start projecten met een Thread modeling workshop en herhaal dit periodiek aangezien er telkens nieuwe code en nieuwe bedreigingen bij komen.
• Het inhuren van gespecialiseerde Penetratietest bedrijven is ook zeker aan te raden.

Meer informatie over beveiliging van webapplicaties?

De OWASP Top 10 is een belangrijk hulpmiddel, maar uiteraard is het van belang om professionele software ontwikkelaars en/of beveiligingsspecialisten te betrekken bij de ontwikkeling en het onderhoud van software oplossingen. Wilt u meer inzicht in uw (software) situatie? Met onze Senet Scan kunnen wij uw bestaande software scannen op kwetsbaarheden maar ook op kwaliteit en interacties met andere applicaties.