Hertest

Waarom een hertest na een pentest?

Uit de resultaten van een uitgevoerde pentest blijkt dat een webapplicatie, API of netwerk kwetsbaarheden bevat. Op basis van het pentest-rapport gaan ontwikkelaars of beheerders aan de slag om deze kwetsbaarheden te verhelpen of de risico’s te beperken.

Om zeker te weten dat de beveiligingsproblemen daadwerkelijk en op de juiste manier zijn opgelost, is het sterk aan te raden om een hertest uit te voeren. Zo voorkom je dat risico’s blijven bestaan en voldoe je aan de eisen van bijvoorbeeld klanten, auditors of certificeringsinstanties.

Wat is een hertest?

Een hertest is een gerichte controle van de eerder gevonden kwetsbaarheden uit een pentest. Het is géén volledige nieuwe pentest. Een ervaren security expert controleert of de aangebrachte beveiligingsmaatregelen effectief zijn én of deze op een structurele manier zijn geïmplementeerd. Bij een hertest wordt:

  • gecontroleerd of kwetsbaarheden correct zijn verholpen;
  • geverifieerd of de oplossing structureel is toegepast (niet ad-hoc);
  • een nieuwe rapportage opgesteld met bewijs van de opgeloste issues.

Deze hertest-rapportage sluit aan op het oorspronkelijke pentest-rapport en biedt duidelijkheid over de huidige status van de beveiliging.

Wat kost een hertest?

Een hertest wordt uitgevoerd op basis van nacalculatie tegen het standaard uurtarief. De benodigde tijd hangt af van:

  • het aantal opgeloste kwetsbaarheden;
  • het type kwetsbaarheden;
  • de kwaliteit en volledigheid van de aangeleverde informatie.

Indicatie: een hertest voor een middelgrote webapplicatie duurt gemiddeld tussen de 8 en 12 uur, mits de originele pentest is uitgevoerd door DongIT. Houd er rekening mee dat dit afhankelijk is van de complexiteit van de gevonden issues.

Hertest op pentest van een andere partij

Ook als de originele pentest is uitgevoerd door een andere partij, kun je bij ons terecht voor een onafhankelijke hertest. In dat geval is het belangrijk dat je het oorspronkelijke pentest-rapport aanlevert. Onze beveiligingsexpert:

  • beoordeelt de kwaliteit van het originele rapport;
  • controleert of de bevindingen valide en actueel zijn;
  • voert op basis daarvan een grondige hertest uit.

Op zoek naar zekerheid na een pentest? Laat je hertest uitvoeren door DongIT en ontvang een duidelijke, onderbouwde rapportage.

Hertest aanvragen via het Reporter-portaal

Wil je een hertest laten uitvoeren op bevindingen uit een eerdere pentest? Dit regel je eenvoudig via het DongIT Reporter-portaal.

  1. Log in op het Reporter-portaal.
  2. Ga naar de betreffende Finding van de pentest.
  3. Klik op "Request Retest" bij elke bevinding die je wilt laten controleren.
  4. Vul in het tekstveld in hoe je de kwetsbaarheid hebt verholpen of hoe het risico is gemitigeerd.

Request retest

Wat moet je aanleveren bij een hertest?

Voor een snelle en efficiënte afhandeling van de hertest is het belangrijk om volledige, duidelijke documentatie aan te leveren. Bij het aanvragen van een hertest, geef je per bevinding het volgende aan:

  • Wat is er gewijzigd? Beschrijf de oplossing concreet.
  • Waar is dit aangepast? Verwijs naar bestanden, regels of endpoints.
  • Hoe is het aangepast? Geef technische details of configuratiewijzigingen (bijv. screenshots van aangepaste code, referenties naar commits in Git en/of uitleg bij ontwerpkeuzes of geaccepteerde risico's.

Een pentester beoordeelt op basis hiervan of de kwetsbaarheid effectief is opgelost en of dit op een structurele manier is gebeurd.

Voorbeelden van correcte bewijsvoering bij een hertest

Hieronder zie je voorbeelden van hoe bevindingen en bewijsvoering idealiter worden gedocumenteerd:

1. Parameter-misbruik

Bevinding: Via de parameter jobalert_action op /nl/jobs/alert kunnen onbevoegde methodes worden aangeroepen.
Slechte aanlevering: Gefixed.
Goede bewijsvoering: Opgelost door het instellen van een whitelist met toegestane methoden. Zie bijgevoegd screenshot (Figuur 1).

whitelist_methods
Figuur 1: Toegestane methoden gewhitelist.

2. Cookie-attributen niet juist ingesteld

Bevinding: Attributen als secure en HttpOnly ontbreken op PHPSESSID.
Slechte aanlevering: Gefixed.
Goede bewijsvoering: Aangepast in php.ini. secure en HttpOnly zijn geactiveerd. Zie screenshot (Figuur 2).

cookie_settings
Figuur 2: Cookie-attributen settings.

3. SQL-injectie via onveilige query

Bevinding: Niet-geparametriseerde query op regel 89 in controllers/pagesController.php.
Slechte aanlevering: Advies toegepast.
Goede bewijsvoering: Query’s geparametriseerd met PDO. Zie screenshot (Figuur 3).

parametrisering_query
Figuur 3: Geparametriseerde queries.

4. Server-Side Request Forgery (SSRF)

Bevinding: SSRF mogelijk via url parameter in /include/seotool/index.php.
Goede bewijsvoering: Directory /include/seotool is volledig verwijderd.

5. Reflected Cross-Site Scripting (XSS)

Bevinding: Reflected XSS in /include/menuitem.demo.inc.php.
Goede bewijsvoering: Filtering toegepast op regel 10 van het script. Zie screenshot (Figuur 4).

reflected_xss
Figuur 4: Parameter gefilterd.

6. Wachtwoorden in plaintext opgeslagen

Bevinding: Inloggegevens worden in leesbaar formaat opgeslagen in dbacc2.auth_logs.
Goede bewijsvoering: Logregels zijn aangepast; wachtwoorden worden niet meer opgeslagen. Oude regels zijn verwijderd. Zie Figuur 5.

foutieve_inlogpogingen
Figuur 5: Regels met wachtwoorden zijn verwijderd.

7. Openbare NFS-share met inloggegevens

Bevinding: NFS-share op 10.0.0.118 bevat credentials.
Goede bewijsvoering: Toegang nu afgeschermd + wachtwoord op externe server gewijzigd.

8. Verouderde software in gebruik

Bevinding: Verouderde versie van jQuery in gebruik.
Goede bewijsvoering: Kwetsbaarheid nog niet opgelost. Staat op de planning (laag risico).

Let op

Hoe vollediger de informatie, hoe efficiënter de hertest uitgevoerd kan worden.

Bij twijfel of vragen over de benodigde informatie kun je contact opnemen via het Reporter-portaal of uw contactpersoon.