English
Waarom een hertest
Uit de resultaten van de penetratietest komt naar voren dat de onderzochte webapplicatie of een netwerk kwetsbaarheden bevatten. Aan hand van het pentestrapport gaan ontwikkelaars/beheerders aan de slag om de gevonden kwetsbaarheden en risico's te verhelpen of te beperken. Om er na de doorontwikkeling zeker van te zijn dat de gevonden kwetsbaarheden op de juiste manier zijn opgelost, is het aan te raden om een hertest uit te voeren.
Wat is een hertest
Een hertest is geen compleet nieuwe pentest. Met een hertest zal een beveiligingsexpert de wijzigingen nalopen en controleren of de kwetsbaarheden daadwerkelijk zijn verholpen. Hierbij wordt ook duidelijk of een kwetsbaarheid op de juiste manier is verholpen. Hierbij let de beveiligingsonderzoeker bijvoorbeeld ook op of de kwetsbaarheid structureel is verholpen en niet op een enkele plek (ad-hoc). Uit een hertest volgt een hertest-rapportage op basis van de eerdere pentestrapportage waarin staat of de risico's zijn weggenomen en de kwetsbaarheden zijn verholpen, ondersteund met bewijsvoering.
Wat zijn de kosten
Een hertest wordt gefactureerd op basis van nacalculatie tegen het standaard uurtarief. Het aantal benodigde arbeidsuren hangt sterk af van de hoeveelheid en type (opgeloste) kwetsbaarheden en/of de kwaliteit van de aangeleverde informatie (zie onderstaande voorbeelden). Ter indicatie: een gemiddelde hertest duurt 4 - 8 uur, op een pentest die initieel is uitgevoerd door DongIT.
Hertest op onderzoeksresultaten van andere partij
Voor een hertest op een penetratietest die is uitgevoerd door een andere partij, is het noodzakelijk om de oude pentestrapporten aan te leveren. Een security expert kan tevens de kwaliteit van de oude rapporten beoordelen en advies geven over de kwaliteit en nauwkeurigheid van de eerdere bevindingen.
Hertest aanvragen via Reporter-portaal
Om hertest uit te voeren op de bevindingen uit een eerder uitgevoerde penetratietest, dient de opdrachtgever via het Reporter-portaal onder elke Submission een hertest aan te vragen (Request a retest). In het tekstveld, zoals hieronder weergegeven, kan de opdrachtgever vervolgens aangeven hoe de bevinding is verholpen/verwerkt.
Welke informatie moet er aangeleverd worden bij een hertest?
- Geef aan per onderdeel en subonderdeel wat er exact is gewijzigd, waar dit is aangepast en hoe het is aangepast. Het aanleveren van volledige informatie bevordert de benodigde testtijd, omdat een hertest zo sneller en effectiever kan uitgevoerd worden.
- Indien een kwetsbaarheid voortkomt uit een ontwerpkeuze of een geaccepteerd risico bevat, dient dit ook aangegeven te worden. Een pentester zal de ontwerpkeuze of het commentaar beoordelen.
- Voeg eventueel ook screenshots toe (van de code met highlights) of referenties naar commits in GIT. Zie hieronder een aantal voorbeelden voor het goed documenteren en aanleveren van hertest-informatie.
Voorbeelden documentatie/aan te leveren bewijsvoering
1. Voorbeeld - Parameter
Bevinding initiële pentest: Via parameter "jobalert_action" op het pad "/nl/jobs/alert" kan elke methode van de class "JobsAlertController" aangevraagd worden. Hieronder vallen methoden waarvan het niet de bedoeling is dat deze aangeroepen kunnen worden.
Aangeleverde bewijsvoering door klant: Gefixed, methode van de class "JobsAlertController" kan niet meer aangevraagd worden.
Gewenste bewijsvoering door klant: Opgelost, er is een white-list ingesteld met toegestane methoden die kunnen worden aangeroepen. Zie bijgevoegd screenshot (Figuur 1).
2. Voorbeeld - Cookie-attributen
Bevinding initiële pentest: Cookie-attributen zijn niet correct ingesteld op het sessie-cookie "PHPSESSID".
Aangeleverde bewijsvoering door klant: Gefixed.
Gewenste bewijsvoering door klant: Aangepast, cookie-attributen zijn ingesteld op "secure" en "HttpOnly", dit is ingesteld in php.ini. Zie bijgevoegd screenshot (Figuur 2).
3. Voorbeeld - SQL-injectie
Bevinding initiële pentest: De database query op regel 89 in "controllers/pagesController.php" is niet geparametriseerd of wordt niet geescaped. Door het request aan te passen kan de query gemanipuleerd worden (SQL-injectie).
Aangeleverde bewijsvoering door klant: Gefixed, advies toegepast.
Gewenste bewijsvoering door klant: Opgelost, de queries zijn nu geparametriseerd. Zie bijgevoegd screenshot (Figuur 3).
4. Voorbeeld - Server-Side Request Forgery
Bevinding initiële pentest: Server-Side Request Forgery is geconstateerd op "/include/seotool/index.php" (url parameter).
Aangeleverde bewijsvoering door klant: Opgelost, Server-Side Request Forgery is niet meer mogelijk.
Gewenste bewijsvoering door klant: Opgelost, de directory "/include/seotool" is verwijderd uit het project, deze functionaliteit werd niet gebruikt.
5. Voorbeeld - Cross-Site Scripting
Bevinding initiële pentest: Reflected XSS op "/include/menuitem.demo.inc.php" (id parameter).
Aangeleverde bewijsvoering door klant: Aangepast, filtering is toegepast.
Gewenste bewijsvoering door klant: Aangepast, parameter wordt nu gefilterd in regel 10 van "/include/menuitem.demo.inc.php". Zie bijgevoegd screenshot (Figuur 4).
6. Voorbeeld - Opslag wachtwoord in leesbaar formaat
Bevinding initiële pentest: Foutieve inlogpogingen worden met gebruikersnaam en wachtwoord in leesbaar formaat opgeslagen in de databasetabel "dbacc2.auth_logs".
Aangeleverde bewijsvoering door klant: Gefixed.
Gewenste bewijsvoering door klant: Opgelost, foutieve inlogpogingen worden nu zonder wachtwoord gelogd in de database (Figuur 5). De bestaande regels in de database met wachtwoorden zijn verwijderd.
7. Voorbeeld - NFS-share publiekelijk toegankelijk
Bevinding initiële pentest: Op 10.0.0.118 is het mogelijk om een onbeveiligde NFS-share te benaderen. Op deze NFS-share werd in het bestand "log.txt" een gebruikersnaam en wachtwoord aangetroffen waarmee ingelogd kon worden op https://gw2012.acme.local/login.
Aangeleverde bewijsvoering door klant: Gefixed.
Gewenste bewijsvoering door klant: Opgelost. 1: de NFS-share is afgeschermd met een gebruikersnaam en wachtwoord. 2: het wachtwoord van het aangetroffen account is gewijzigd op gw2012.acme.local.
8. Voorbeeld - Verouderde software in gebruik
Bevinding initiële pentest: Verouderde, niet-ondersteunde versie van jQuery is in gebruik.
Aangeleverde bewijsvoering door klant: -
Gewenste bewijsvoering door klant: Deze kwetsbaarheid is nog niet opgelost, wordt begroot door klant. Of bijvoorbeeld: alle gevonden kwetsbaarheden met risicoclassificatie "laag" zijn nog niet verwerkt.