OWASP top 10
Wat ontwikkelaars over de OWASP top 10 moeten weten om goede én veilige webapplicaties te bouwen!
De OWASP top 10 is een handig overzicht van de meest kritieke beveiligingsrisico’s voor webapplicaties. Wat mij betreft is het een ideale basis om (geautomatiseerde) tests uit te voeren, zodat het je niet alleen goedwerkende, maar ook veilige applicaties oplevert.Bij Cacholong monitoren we de servers continu. Ik zie dagelijks dat webapplicaties worden aangevallen. Gelukkig richten de meeste van deze aanvallen geen schade aan (vanwege goede beveiliging), maar als de beveiligingsrisico’s van een webapplicaties niet goed zijn afgedicht, kan het misgaan.
Jammer en vaak niet nodig!
Daarom raad ik alle ontwikkelaars met klem aan om tijdens de ontwikkelfase rekening te houden met de beveiliging. Gebruik daarbij de OWASP top 10 om te controleren of je de meest voorkomende beveiligingsrisico’s goed hebt afgedicht.
Wat is OWASP top 10
OWASP staat voor het Open Web Application Security Project. OWASP is een wereldwijde non-profitorganisatie die sinds 2004 werkt aan het continu verbeteren van softwarebeveiliging. OWASP stelt onder andere ontwikkelaars in staat om betrouwbare en veilige applicaties te bedenken, ontwikkelen en onderhouden.Alle tools, documenten, fora en afdelingen zijn gratis toegankelijk en onmisbaar voor iedereen die geïnteresseerd is in het verbeteren van applicatiebeveiliging.
Eén van de projecten waar OWASP aan werkt, is de OWASP top 10. De OWASP top 10 is bedoeld om de beveiligingsrisico’s van webapplicaties tot een minimum te beperken. Het gebruik van deze top 10 is een eerste stap om de software-ontwikkelcultuur binnen organisaties te veranderen in een cultuur waarin veiligheid voorop staat.
Wat zijn 10 meest kritieke beveiligingsrisico’s voor webapplicaties?
In deze blog licht ik de 10 meest kritieke beveiligingsrisico’s toe en geef ik advies over hoe je deze risico’s kunt beperken.A1 – 2017 | Injection
Injection is het misbruiken van een bug door het verwerken van ongeldige gegevens. Denk hierbij aan NoSQL-, OS-, LDAP- en SQL-injections. SQL-injections komen vaak voorbij, omdat steeds meer websites worden gebouwd met databases.Bij injection gaat het om user supplied data, gegevens die door gebruikers worden ingevoerd. Door deze gegevens worden soms onbedoeld opdrachten uitgevoerd door de applicatie, waardoor bijvoorbeeld een hacker toegang krijgt tot informatie die afgeschermd hoort te zijn of de website zelfs onbereikbaar wordt.
Deze aanvallen zijn relatief eenvoudig te detecteren en te stoppen door gebruik te maken van een Web Application Firewall (WAF). Een WAF is een systeem dat een applicatie beschermt tegen aanvallen door malafide informatie tegen te houden.
Wil je meer weten over Web Applications Firewalls en hoe je een WAF effectief inzet? Lees dan de blog Web Application Firewall: wat is het en hoe werkt het?
Let op: Een WAF houdt niet alle injection-aanvallen tegen!
Wil je misbruik door injection-aanvallen voorkomen, zorg er dan voor dat je grondig test. Denk hierbij aan (geautomatiseerde) unit tests, feature tests en voer ook statische analysetests uit.
Tip: maak hierbij gebruik van een OTAP-ontwikkelstraat.
A2 – 2017 | Broken Authentication
Applicatiefuncties met betrekking tot authenticatie en sessiebeheer worden vaak onjuist geïmplementeerd, waardoor aanvallers wachtwoorden, sleutels of sessietokens kunnen achterhalen. Andere fouten zorgen ervoor dat hackers de identiteit van andere gebruikers kunnen aannemen. Dit noemen we broken authentication.Vaak beschikt een hacker over veel combinaties van gebruikersgegevens en wachtwoorden, bijvoorbeeld door phishingmails of een hack van een socialemediaplatform. Herinner je je die LinkedIn-hack in 2012 nog? Oplichten via een Vraag & Antwoord-functie komt ook regelmatig voor. Het overkwam Tweakers, zo valt te lezen op hun blog van begin januari 2020.
Gelukkig gebruiken steeds meer mensen een passwordmanager, waardoor er gelukkig meer unieke wachtwoorden worden gebruikt en hackers veel minder snel oneigenlijk toegang krijgen.
Wat je kan doen om de veiligheid te borgen, is eisen stellen aan wachtwoorden: geef bijvoorbeeld aan dat een wachtwoord altijd een bepaalde minimum lengte moet hebben en moet worden opgebouwd uit een combinatie van letters, cijfers en vreemde tekens. Simpel, maar uiterst effectief!
Wil je brute force attacks tegen gaan? Zorg er dan voor dat er restricties worden gesteld aan het aantal inlogpogingen per tijdseenheid. Bijvoorbeeld maximaal 30 pogingen per minuut en hooguit 100 per uur.
Het is ook slim om wachtwoorden versleuteld op te slaan in de applicatie. Vaak wordt hiervoor de hashfunctie MD5 (Message Digest Algortihm 5) of SHA-1 gebruikt, maar houd er rekening mee dat deze functies verouderd en onveilig zijn. Je kunt beter een ander algoritme gebruiken, zoals SHA-2 of Argon. Ik geef de voorkeur aan Argon, want dit hashing algoritme is nog niet zolang geleden gebouwd en is bestand tegen de moderne aanvallen.
Belangrijk: Houd de ontwikkeling op het gebied van de hashing algoritmes goed in de gaten, want een algoritme dat nu goed werkt kan over niet al te lange tijd achterhaald zijn.
A3 – 2017 | Sensitive Data Exposure
Gevoelige informatie - financiële gegevens, zorgdata en Persoonlijke Identificeerbare Informatie (PII) - worden door veel webapplicaties en API’s niet goed beschermd. Aanvallers kunnen deze gegevens stelen of wijzigen en daarmee misdrijven plegen, zoals creditcardfraude en identiteitsdiefstal.Voorkom dat gevoelige informatie wordt aangetast of misbruikt door speciale voorzorgsmaatregelen te treffen bij het uitwisselen van informatie met een browser. Je kunt onder meer de browser instrueren om het verkeer uitsluitend over een veilige verbinding (https) in te laden.
Maak je al gebruik van SSL? Doe de SSL-test en ontdek hoe veilig je website of applicatie is.
Als ontwikkelaar kun je veel beveiligingsrisico’s beperken door bepaalde maatregelen te treffen, maar in het geval van Sensitive Data Exposure heeft de gebruiker ook zijn eigen verantwoordelijkheid. Ondanks intensieve campagnes van de Rijksoverheid om mensen te wijzen op de gevaren en gevolgen van phishingmails, gebeurt het regelmatig dat hackers bijvoorbeeld geld overmaken van een rekening.
Heel vervelend.
Laten we hopen dat meer en meer mensen verstandig omgaan e-mail, whatsappberichten en andere informatie die ze ontvangen.
A4 – 2017 | XML External Entities (XXE)
Met XML, de afkorting voor Extensible Markup Language, worden gegevens op een gestructureerde manier vastgelegd. De indeling die daarbij gebruikt wordt, maakt dat de gegevens zowel door de mens als door een machine te begrijpen zijn. Het wordt gebruikt voor het overzetten, ophalen, wegschrijven en exporteren van data.Dit biedt mogelijkheden voor een hacker om verzoeken op afstand uit te voeren en interne systemen te scannen. De mogelijkheid om externe (XML-)documenten in te laden wordt ook wel 'XML External Entities' genoemd. Als een XML-processor verouderd of niet goed afgesteld is, kan dit voor veel problemen zorgen.
Het is lastig om XML External Entities te voorkomen, omdat je afhankelijk bent van de geïnstalleerde XML-processor. Heel vaak wordt voor de uitwisseling van informatie gebruik gemaakt van SOAP (Simple Object Access Protocol). SOAP is gebaseerd op XML en is daardoor gevoelig voor dit type aanvallen. Ik adviseer dan ook om, waar mogelijk, een minder complexe gegevensindeling te gebruiken, bijvoorbeeld JSON (JavaScript Object Notation).
Bij Cacholong zien we regelmatig dit soort XXE-aanvallen voorbijkomen. Ik wijs nogmaals op het belang van testen om de kwaliteit en veiligheid van de webapplicatie te borgen. En maak gebruik van een goed ingerichte WAF; die herkent en blokkeert in de meeste gevallen malafide XML-opdrachten.
A5 – 2017 | Broken Access Control
Beperkingen op wat geautoriseerde gebruikers mogen doen, worden vaak niet goed vastgelegd. Hierdoor kunnen hackers toegang krijgen tot functionaliteiten of gegevens. Denk onder meer aan toegang tot gegevens van andere gebruikers, gevoelige informatie bekijken, gegevens wijzigingen, toegangsrechten aanpassen, enzovoort.Een klassiek voorbeeld van Broken Access Control is een lek in een webshop waardoor eerdere bestellingen van klanten konden worden opgezocht door – simpelweg – de url te veranderen.
Toegangscontrole is alleen effectief als deze wordt afgedwongen zodat de aanvaller de toegangscontrole of metadata niet kan wijzigen.
Stel dat je een webshop bouwt en in de url bijvoorbeeld ‘winkelwagen ID=80’ ziet staan. Probeer dan eens of je dit getal kunt aanpassen. Kijk wat er gebeurt. Kun je het getal wijzigen en zie je vervolgens een winkelwagen van iemand anders, dan is er sprake van broken access control.
Wat je als ontwikkelaar dus moet doen, is de rechten goed instellen in de applicatie. En ook hier geldt: blijf testen! Neem unittest, featuretests en integratietest op in je testprotocol.
Daarnaast is het slim om te rate limiten waardoor het aantal geautomatiseerde aanvallen tot een minimum worden beperkt. Via de rate limiter hebben wij Google op de vingers getikt waardoor het aantal requests van Googlebot is beperkt. Een request van Google is natuurlijk geen hack, maar je kunt er wel last van hebben.
A6 – 2017 | Security Misconfiguration
Een verkeerde configuratie van de beveiliging is misschien wel het meest voorkomende probleem. Dit beveiligingsrisico is meestal het gevolg van onveilige standaardconfiguraties, open cloudopslag, onjuist ingestelde HTTP-headers, enzovoort. Het is van groot belang dat besturingssystemen, frameworks, libraries en applicaties veilig worden geconfigureerd én tijdig worden gepatcht en bijgewerkt.Dit beveiligingsrisico heeft te maken met hosting. Het is belangrijk om na te gaan hoe jouw hostingpartij hiermee omgaat. Er zijn een aantal zaken waarop je kunt letten. Vraag bijvoorbeeld of er beleid is op het voorkomen van standaard wachtwoorden (zoals ‘123welkom’). Ga ook altijd na of er een goede firewall is ingesteld, eentje die zowel het inkomende verkeer als het uitgaande verkeer controleert. Overbodig openstaande poorten kunnen immers gebruikt worden om aanvallen uit te voeren. En stem af dat het platform alleen de hoogstnodige functies, componenten en documentatie bevat. Alle overbodige functies en frameworks geven alleen maar meer beveiligingsrisico’s.
Het is ook essentieel dat jouw hostingpartij een geautomatiseerd proces heeft om de configuraties te testen.
Bij Cacholong gebruiken we een configuratiemanagementsysteem waarbij met grote regelmaat checks worden uitgevoerd. Want wij willen voorkomen dat problemen schade aanrichten. Trouwens, als een probleem ontdekken, lossen we dat altijd onmiddellijk op! We werken hierbij op basis van processen conform ISO 27001 en NEN 7510.
A7 – 2017 | Cross-site Scripting XXS
XXS-fouten ontstaan wanneer een toepassing onbetrouwbare gegevens op een nieuwe pagina opneemt zonder validatie of controletoets. Of wanneer een bestaande webpagina met gebruikersgegevens wordt bijgewerkt. XXS stelt aanvallers in staat om scripts uit te voeren in de browser van de gebruiker waardoor gebruikerssessies gekaapt worden, websites worden beschadigd of gebruikers worden omgeleid naar malafide websites. Een goed voorbeeld van XXS-fouten is ‘cookie diefstal’.Gelukkig zijn er veel maatregelen die je als ontwikkelaar kunt nemen om cross-site scripting XXS te voorkomen:
- Maak gebruik van een Web Application Firewall (WAF) waarbij aanvallen worden geblokkeerd;
- Instrueer je browser om CSS-aanvallen te blokkeren;
- Regel inputvalidatie goed in (zie A2 – 2017 | Broken Authentication)
- Maak gebruik van een CSRF token
A8 – 2017 | Insecure Deserialization
Insecure deserialization ofwel onveilige deserialisatie leidt vaak tot uitvoering van externe code, maar wordt ook gebruikt om aanvallen uit te voeren, zoals replay attacks en injection attacks.Insecure deserialization kom je vooral tegen bij apps die gebouwd zijn met de programmeertaal JAVA. Bij websites die gebouwd zijn met php kom het minder vaak voor.
Om insecure deserialization te voorkomen is het van groot belang dat de input goed gevalideerd is. Ook voor dit beveiligingsrisico raad ik je aan om een WAF in te zetten.
A9 – 2017 | Using Components with Known Vulnerabilities
Als kwetsbare componenten, zoals libraries, frameworks en andere softwaremodules, worden misbruikt, kan een aanval leiden tot ernstig gegevensverlies of serverovername. Gebruik maken van applicaties en API’s waarvan de kwetsbaarheden bekend zijn, is vragen om moeilijkheden.Zorg er daarom voor dat je:
- Altijd de laatste versie van de software gebruikt;
- Controlechecks uitvoert op de versiegeschiedenis van libraries;
- Gebruik maakt van beveiligingscontroles die je informeren over onveilige componenten.
A10 – 2017 | Insufficient Logging & Monitoring
Elke organisatie moet ervoor zorgen dat er doorlopend gelogd en gemonitord wordt. Zonder logboekregistratie, monitoring en een goed ingericht proces hoe met incidenten om te gaan, geef je hackers de ruimte om je applicaties te beschadigen, saboteren of zelfs uit te schakelen. Helaas hebben veel organisaties – en hostingpartijen – deze processen niet op orde.Kies daarom je hostingpartij zorgvuldig. En zorg ervoor dat je logboeken bijhoudt, zodat je precies weet waar wat misgaat en wie (welke gebruiker) dat (per ongeluk) heeft veroorzaakt.
Uit onderzoek blijkt dat een inbreuk op de beveiliging pas na 200 dagen wordt ontdekt. En dan wordt de ontdekking meestal ook nog eens gedaan door externe partijen in plaats van door het correct toepassen van interne processen.
Probeer jij na 200 dagen nog meer eens te achterhalen waar het is misgegaan.
Kortom: loggen is extreem belangrijk om een audit trail in kaart te brengen. Het helpt je bij het ‘spoorzoeken’ en traceren.
Ook in dit geval kan een WAF je helpen. Een Web Applicatie Firewall beschermt je applicatie niet alleen tegen misbruik van buiten af, maar maakt het ook mogelijk om verkeer te monitoren. Het geeft je dus realtime inzicht en helpt je te achterhalen waar het is misgegaan.
Samenvatting: voorkomen is beter dan genezen
Het voorkomen van beveiligingsinbreuken is beter dan na een aanval de schade herstellen. Toch lukt het niet altijd om hacks te voorkomen. Maar als je bij het ontwikkelen al rekening houdt met de beveiliging, uitentreuren test en rekening houdt met OWASP top 10, dan heb je er alles aan gedaan om te zorgen voor optimale veiligheid.Wil je een keer met mij van gedachten wisselen over hoe je de veiligheid verder kunt optimaliseren? Neem dan contact op. Voor een goed gesprek over softwarebeveiliging maak ik graag tijd!
