Security testen kan eng voelen. Je moet namelijk erg veel weten om een security expert te zijn. Om een security expert te helpen, heb je daarentegen veel minder kennis nodig. In dit artikel staan enkele praktische tips waarmee jij jouw lokale security experts kunt ondersteunen.

Aanvallers

Softwarebeveiliging is verdediging. Als verdedigers creëren we een schild voor onze applicaties, zodat aanvallers hun einddoelen niet kunnen bereiken. Die einddoelen zijn onder andere geld, data, jou laten lijden en de kick. Dit zijn moeilijke zaken om tegen te verdedigen.

In plaats daarvan kunnen we ons beter richten op de tussendoelen van de aanvaller. Wat het einddoel ook is, ze zullen constant een van de tussendoelen moeten bereiken om verder te komen. Aanvallers willen:

1. Ontdekken hoe je systeem werkt
2. Hun code op jouw machine uitvoeren
3. Data verzamelen

Als we aanvallers de kans ontnemen om deze tussendoelen te bereiken, kunnen ze je systeem niet hacken.

Wat te verdedigen

De OWASP top 10 is een uitstekende plek om te beginnen voor elk security kennisniveau. Het somt de meest voorkomende security problemen in de echte wereld op. De top 10 bevat een mix van basis- en geavanceerde security concepten. Ik neem enkele security problemen met je door die je redelijkerwijs kunt testen als je geen security expert bent.

Broken Access Control

Broken access control staat op nummer 1 van de lijst en is daarmee het meest voorkomende security probleem. Het heeft betrekking op data die zichtbaar is voor de verkeerde gebruiker. Bijvoorbeeld, je kunt data zien die bedoeld is voor je supervisor. Of misschien kun je een pagina zien zonder in te loggen.

Security experts zonder gedetailleerde domeinkennis en geautomatiseerde tools kunnen niet alle broken access control problemen detecteren. Je hebt domeinkennis nodig om te weten wie toegang zou moeten hebben waartoe. Voor het testen van dit security probleem heb je geen testtools nodig. Tijdens het testen zoek je naar data die je kunt benaderen zonder een account of met het verkeerde account.

Voor meer informatie over dit security probleem, zie de OWASP-cheatsheets:

• Authorization Cheat Sheet
• Insecure Direct Object Reference Prevention Cheat Sheet
  Insecure Direct Object Reference is de jargon versie van ‘handmatig een URL wijzigen en kijken of je iets kunt vinden.’

Injection

Injectie aanvallen stellen aanvallers in staat hun code op jouw machine uit te voeren. Het gebeurt wanneer je applicatie gebruikersinvoer behandelt als applicatiecode.

Er zijn veel soorten injectie aanvallen. Het exacte type injectie waarvoor je applicatie kwetsbaar kan zijn, hangt af van je tech stack. Bijvoorbeeld, als je applicatie een SQL-database gebruikt, kan deze kwetsbaar zijn voor SQL-injectie. Bij aanvallen moet je het exacte type injectie weten. Bij het testen is dat minder belangrijk.

Ongeacht het type injectie is de mitigatie altijd hetzelfde: Sanitize alle gebruikersinvoer. Bij het sanitizing van tekst vervang je strategisch enkele karakters. Het vervangen van een paar karakters is voldoende om deze aanvallen te voorkomen. Welke karakters je moet vervangen hangt af van het type injectie, dit staat in de cheatsheet.

Injectie aanvallen kunnen behoorlijk geavanceerd zijn. Met testen controleren we echter alleen op gebruikersinvoer-sanitisatie. Ontbrekende sanitisatie betekent dat er een potentiele aanvalsvector is om te fixen. Zo kunnen we de technische details van aanvallen negeren. Tijdens het testen, controleer je of alle gebruikersinvoer gesanitized is. Test de sanitisatie van alle formulier invoervelden, URL-parameters en API-parameters. Geen van deze door gebruikers controleerbare invoervelden mag ooit als code worden uitgevoerd.

Geautomatiseerde tools kunnen je helpen niet-gesanitized invoeren te vinden. Een interessante tool is  OWASP ZAP. Let op, deze tool kan een behoorlijk rabbit hole zijn. Het kan een goed idee zijn om een ontwikkelaar of security expert om hulp vragen.

Voor meer informatie over dit security probleem, zie de OWASP-cheatsheets:

• Injection Prevention Cheat Sheet

Vulnerable dependencies

Wanneer je je applicatie released, release je ook al diens dependencies. Omdat deze dependencies ook code zijn, kunnen ze security problemen bevatten.

Gelukkig hoef je deze dependencies niet zelf te testen of te beoordelen. We kunnen vertrouwen op een netwerk van security experts die Common Vulnerabilities and Exposures (CVEs) in dependencies vinden en rapporteren. We kunnen deze database van problemen gebruiken bij het testen. De gerapporteerde security problemen worden vaak opgelost in een nieuwere versie van de applicatie. Wij hoeven alleen onze dependencies bij te werken.

Er zijn een hoop geautomatiseerde tools die vulnerable dependencies kunnen testen. Sommige van deze tools zijn open source, terwijl andere commercieel zijn. Voor een volledige en up-to-date lijst van tools, zie de cheatsheet.

Voor meer informatie over dit beveiligingsprobleem, zie de OWASP-cheatsheet:

• Vulnerable Dependency Management Cheat Sheet

Conclusie

Je moet over heel veel kennis beschikken om een security expert te zijn. Maar met basiskennis kunnen we de experts helpen zodat zij zich kunnen concentreren op de complexe dingen. Als je geen security expert bent, zijn er nog steeds dingen die je redelijkerwijs wel kunt testen. Onder andere broken access control, injection aanvallen en vulnerable dependencies.

Welke security problemen ga jij testen?