Test engineering

Security testen kan als eng voelen. Je moet namelijk zoveel 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 een verdediging. Als verdedigers creëren we een schild voor onze applicaties, zodat aanvallers hun einddoelen niet kunnen bereiken. De einddoelen zijn onder andere geld, data, je 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. 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 bespreek enkele security problemen 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 problemen. 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 intieme domeinkennis en geautomatiseerde tools kunnen niet alle broken access control problemen detecteren. Je hebt domeinkennis nodig om te weten wie toegang zou moeten hebben tot wat. 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:

Injection

Injectie aanvallen stellen aanvallers in staat hun code op je 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 en staat in de cheatsheet.

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

Geautomatiseerde tools kunnen je helpen niet-gesanitized invoeren te detecteren. 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:

Vulnerable dependencies

Wanneer je je applicatie released, release je ook al zijn 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 dependency. Wij hoeven alleen onze dependencies bij te werken.

Er zijn een hoop geautomatiseerde tools die dit 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:

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 kunt testen. Onder andere broken access control, injection aanvallen en vulnerable dependencies.

Welke security problemen ga jij testen?

 

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Ontwerp zonder titel (19)

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz