Security testen

In het nieuws hoor je steeds vaker verhalen over beveiligingsproblemen bij allerlei bedrijven, van klein tot groot. Aan ontwikkelteams wordt steeds vaker de eis gesteld om ‘veilige’ software te ontwikkelen. Aan de andere kant wordt er tijdens de ontwikkeling van software steeds meer gestuurd op continuous integration(CI). Dat wil zeggen: De code wordt meerdere keren per dag geïntegreerd, functionele tests worden automatisch uitgevoerd en op deze manier streven organisaties ernaar om steeds sneller en vaker ‘live’ te gaan met een nieuwe versie van de software. Zou het niet mooi zijn als we een aantal security tools kunnen integreren in onze bouwstraat? In dit artikel beschrijven we een aantal tools die eenvoudig zijn op te nemen in een bestaande bouwstraat, zodat vulnerability checking een vast onderdeel wordt.

Hoe begin je met security?

Voordat je nu alle tools gaat loslaten op je applicatie is het van belang om te weten waar je de focus moet leggen. Als startpunt raden we ontwikkelteams onder andere aan om gebruik te maken van de ‘OWASP Cheat Sheet Series’ of de ‘OWASP Application Security Verification Standard’ (ASVS). Haal hier samen met het team de toepasbare controls uit en maak deze onderdeel van de ‘definition of done’ of neem ze op in de user-story.

Nu de requirements duidelijk zijn, kun je vervolgens gaan kijken of je de gewenste controles kunt automatiseren. Bijvoorbeeld, door het toepassen van securitytesten. In de praktijk worden securitytesten nog niet echt gezien als onderdeel van de ontwikkeling. Waar we als teams enorme stappen hebben gezet om volledige automatische functionele testen uit te voeren op onze applicaties, wordt dit nog niet gedaan op het gebied van securitytesten. Het uitvoeren van deze testen wordt vaak overgelaten aan een security expert. Typisch wordt aan het eind van het project een penetratietest uitgevoerd. Echter, er kan bij het vaststellen van de user stories al rekening worden gehouden met de zogenaamde ‘evil user stories’. Bijvoorbeeld: “Als een hacker kan ik ongeldige data meesturen in de URL, waardoor ik…….”

Het doel van deze ‘evil user stories’ is vooral om na te denken als een ‘aanvaller’ en te proberen om voor de hand liggende problemen vanaf het begin te vermijden. Vaak kan je op basis van deze 'evil user story' ook weer een control ontwerpen en opnemen als user story of als aanvulling op je huidige user story.

 

Niet voldoende

Het gebruik van security tools is niet zaligmakend en kan niet gezien worden als een vervanging van code reviews, audits en onafhankelijke penetratietesten. Het voordeel van het integreren van security tools tijdens het ontwikkelproces, is dat teams sneller feedback ontvangen over mogelijke problemen met betrekking tot security. Dit maakt het mogelijk om zoveel mogelijk voor de hand liggende problemen al te verwijderen, voordat een serieuze security test wordt uitgevoerd. Natuurlijk: de tools zullen proces-specifieke problemen niet detecteren, tenzij dit op technische basis duidelijk te detecteren is.

Een belangrijke eis voor een security tool is dat deze goed past binnen het ontwikkelproces en omgeving. Zoals al eerder is aangehaald, zijn er veel security tools beschikbaar. We kunnen natuurlijk de laatste versie van bijvoorbeeld ‘Kali Linux’ downloaden en handmatig de tools uitproberen. Deze Linux distributie kan een goed beginpunt zijn om bekend te raken met de tools, maar het helpt ons niet om de tools te integreren binnen het ontwikkelproces.

 

Behavior Driven Development (BDD)

Met BDD tests kunnen we op een goed leesbare manier onze test uitschrijven. Door middel van de vorm “Given-When-Then” (zie figuur 1) kunnen we pre-condities opgeven (“given”), onze actie (“when”) en het verwachtte resultaat (“then”). Het idee achter deze tests is dat ze direct leesbaar zijn voor iedereen en bruikbaar zijn als acceptatie criteria. Wat als we dezelfde stijl ook zouden toepassen voor het schrijven van securitytesten?

 

 

 

 

 

Op het gebied van BDD security frameworks zijn er drie beschikbaar:

• Gauntlt (https://github.com/gauntlt/gauntlt);
• Mittn (https://github.com/F-Secure/mittn);
• BDD-security (https://github.com/continuumsecurity/bdd-security).

De principes achter deze drie frameworks lijken op elkaar. Ze ontsluiten een aantal security tools en door middel van BDD scenario’s definieer je wat je wilt gaan testen. Het framework handelt de interactie af met de onderliggende security tools. Hierdoor wordt het mogelijk om een test op het gebied van security op te schrijven in een leesbaar scenario op basis van een DSL.

De meeste frameworks ontsluiten security tools uit de volgende categorieën:

• Web application pentest tools (ZAP, Arachni, SQLmap);
• Netwerk tools (nmap, Nessus);
• SSL tools (sslyze, Heartbleed, testssl).

Pas op: Mittn heeft geen ondersteuning voor netwerk tools.

 

ASVS guide

Laten we, om te experimenteren, met deze frameworks proberen om een aantal requirements vanuit de ASVS van OWASP te implementeren. Het voordeel is dat veel van deze scripts al beschikbaar zijn binnen de drie frameworks. Je kunt direct aan de slag. Laten we beginnen met:

Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”).

Dit kunnen we met BDD-security controleren door middel van het volgende script:

Scenario: Default admin passwords should not work
  Given a new browser or client instance
  And the login page
  And the username admin
  And the password password
  And the user logs in
  Then the user is not logged in

BDD-security maakt gebruik van de Selenium driver voor het communiceren met de webpagina. Hieronder een voorbeeld van hoe je vanuit een scenario kunt communiceren met ZAP:

Scenario: Present the login form itself over an HTTPS connection
  Given a new browser instance
  And the client/browser is configured to use an intercepting proxy
  And the proxy logs are cleared
  And the login page
  And the HTTP request-response containing the login form
  Then the protocol should be HTTPS

Vanuit het BDD scenario wordt via Selenium met de browser gecommuniceerd, de browser requests worden door ZAP onderschept en aan het eind van de test communiceer je vanuit het scenario met ZAP om te vragen welke request er is uitgevoerd om na te gaan of dit echt HTTPS was.

 

Http methods

Verify that the application accepts only a defined set of required HTTP request methods, such as GET and POST are accepted, and unused methods (e.g. TRACE, PUT, and DELETE) are explicitly blocked.

Dit scenario wordt gedefinieerd door gebruik te maken van het `curl` commando. Het script wordt dan als volgt:

Feature: Evaluate responses to various HTTP methods.
Background:
  Given "curl" is installed
  And the following profile:
    | name | value |
    | hostname | google.com |
 
Scenario Outline: Verify that the application accepts only a defined set of required HTTP request  
  When I launch a "curl" attack with:
 
    """
    curl -i -X <method> <hostname>
    """
 
  Then the output should contain "<response>"
  Examples:
    | method | response |
    | delete | Error 405 (Method Not Allowed) |
    | patch  | Error 405 (Method Not Allowed) |
    | trace  | Error 405 (Method Not Allowed) |

Dit scenario is te vinden in de repository van Gauntlt. In de scenario's van Gauntlt is er minder sprake van abstractie: je communiceert in deze test eigenlijk bijna direct met het ‘curl’ commando.

 

TLS

Er zijn de afgelopen jaren heel wat problemen geweest op het gebied van TLS. Natuurlijk kan je de staat van je TLS/SSL valideren via SSL Labs (Online), maar je kan dit gelukkig ook via een BDD scenario doen. Alhoewel de ASVS guide geen aanbevelingen geeft over TLS configuraties, kunnen we hiervoor de cheat sheet gebruiken:

Weaknesses have been identified with earlier SSL protocols, including SSLv2 and SSLv3, hence SSL versions 1, 2, and 3 should not longer be used

Scenario: Weaknesses have been identified with earlier SSL protocols 
  Given the SSLyze command is run against the secure base Url
  Then the following protocols must not be supported
    |protocol   |
    |SSLV1      |
    |SSLV2      |
    |SSLV3      |

De tool die wordt gebruikt heet ‘sslyze’ en is ontwikkeld voor het testen van SSL configuraties op een server.

 

Cookies

Alhoewel steeds meer frameworks overstappen op een juiste configuratie voor cookies, zien we in de praktijk toch nog steeds foutieve cookie-configuraties langskomen. Volgens de ASVS guide geldt:

Verify that session ids stored in cookies have their path set to an appropriately restrictive value for the application, and authentication session tokens additionally set the “HttpOnly” and “secure” attributes

De HttpOnly vlag is zo bedoeld dat JavaScript geen toegang heeft tot de cookies. Het is natuurlijk geen definitieve oplossing, maar het maakt het stelen van cookies via een XSS kwetsbaarheid lastiger. De secure vlag is bedoeld, zodat een browser de cookies alleen verstuurt via TLS. We kunnen dit als volgt testen:

 

Scenario: Set the 'secure' flag on the session cookie
  Given a new browser or client instance
  And login with default user
  Then the session cookie should have the secure flag set
 
 
Scenario: Set the 'httpOnly' flag on the session cookie
  Given a new browser or client instance
  And the client/browser is configured to use an intercepting proxy
  And login with default user
  Then the session cookie should have the httpOnly flag set

Natuurlijk kunnen we de web analyzers via een BDD scenario ook aan het werk zetten om cross-site scripting problemen te vinden:

Scenario: The application should not contain Cross Site Scripting vulnerabilities
  Given a scanner with all policies disabled
  And all existing alerts are deleted
  And the Cross-Site-Scripting policy is enabled
  And the attack strength is set to High
  And the alert threshold is set to Low
  When the scanner is run
  And the XML report is written to the file xss.xml
  Then no Medium or higher risk vulnerabilities should be present
 
Feature: Look for cross site scripting (xss) using arachni against a URL
Scenario: Using the arachni, look for cross site scripting and verify no issues are found
  Given "arachni" is installed
  And the following profile:
    | name | value |
    | url | http://scanme.nmap.org |
  When I launch an "arachni-simple_xss" attack
  Then the output should contain "0 issues were detected."

In het eerste geval wordt ZAP gebruikt om te scannen voor mogelijke XSS kwetsbaarheden. In het tweede geval wordt Arachni gebruikt.

 

Integratie

Door de BDD frameworks wordt de interactie met de security tools geïntegreerd waardoor je de focus kunt leggen op het schrijven van scenario’s. De frameworks zorgen ervoor dat verwachtingen getoetst kunnen worden over de uitkomsten van de security tools. De output van de BDD frameworks is eenvoudig te integreren. Net zoals de meeste BDD achtige frameworks wordt de output in de vorm van HTML of XML gegenereerd, zodat je buildserver ze kan archiveren en op de resultaten kan acteren. Zo kan je een build laten falen als één van de scenario's faalt.

Het gebruik van de BDD scenario’s levert ook een abstractie laag op. Je kunt hetzelfde scenario vandaag met tool X testen en morgen met tool Y. Het scenario verandert hierdoor niet, alleen de integratie met het nieuwe testtool moet in de step definities (code) verwerkt worden.

 

Conclusie: test zelf, maar vergeet de penetration tester niet

We hebben in dit artikel laten zien dat we met behulp van BDD eenvoudig securitytesten kunnen uitvoeren. Zo kunnen we een aantal simpele zwakheden in de applicatie zien en kan een penetration tester tijdens een pentest zich echt concentreren op de complexe gevallen. We verwachten van een penetration tester dan ook geen standaard rapport meer met eenvoudige resultaten die bijna rechtstreeks uit een tool komen. In plaats daarvan zal de security tester moeten komen met bevindingen die niet direct door deze tools gevonden kunnen worden. De tester kan de scenario’s van het team als input gebruiken bij zijn werk.