Inleiding

De stad zonder bestemmingsplan

Op 12 maart 1989 schreef een Britse natuurkundige genaamd Tim Berners-Lee een bescheiden voorstel van enkele pagina’s, getiteld “Information Management: A Proposal”. Zijn baas bij CERN schreef er “Vague, but exciting” op en legde het terzijde. Het is misschien de meest profetische marginale opmerking in de geschiedenis van de technologie, want dat vage-maar-opwindende voorstel werd het World Wide Web.

Wat Berners-Lee in gedachten had, was elegant in zijn eenvoud: documenten die naar elkaar konden verwijzen via hyperlinks, opgeslagen op servers die met elkaar konden communiceren via een simpel protocol. Het was bedoeld voor wetenschappers die onderzoeksresultaten wilden delen. Het was niet bedoeld voor internetbankieren, sociale media, of webshops die je op drie uur ’s nachts verleiden tot de aankoop van een opblaasbaar eenhoornskostuum.

Maar hier zijn we dan.

Als je het web zou vergelijken met een stad, dan is het een stad die gebouwd is zonder bestemmingsplan. De eerste paar straten waren keurig aangelegd – goed verlicht, overzichtelijk, met duidelijke borden. Dat was het web van de vroege jaren negentig: statische HTML-pagina’s, een paar afbeeldingen, en het overweldigende gevoel dat je deelnam aan iets nieuws en bijzonders.

Toen kwamen de winkeliers. En de bankiers. En de entertainmentindustrie. En ineens moesten er flatgebouwen komen waar huisjes hadden gestaan, werden er snelwegen dwars door woonwijken getrokken, en begon iedereen kelders te graven zonder te controleren of er misschien al leidingen lagen. Het web van vandaag is het resultaat: een metropool van onvoorstelbare omvang en complexiteit, gebouwd op fundamenten die ontworpen waren voor een dorpje.

HTTP, het protocol dat Berners-Lee ontwierp, was stateless. Elke keer dat je een pagina opvraagt, is de server alles vergeten wat hij over je wist. Het is alsof je elke dag naar dezelfde bakker gaat, maar hij je elke keer opnieuw vraagt wie je bent. Om dit op te lossen bedachten Netscape in 1994 cookies – kleine tekstbestandjes die je browser opslaat, zodat de server je de volgende keer herkent. Het is het digitale equivalent van een stempelkaart: de bakker weet niet echt wie je bent, maar als je die kaart laat zien, geeft hij je je gebruikelijke bestelling.

Dat klinkt onschuldig. Maar die cookies werden nu gebruikt voor sessiemanagement, authenticatie, tracking, personalisatie, en nog honderd andere dingen die Netscape in 1994 niet had voorzien. En als iemand je stempelkaart kan kopieren – of, in webtermen, je session cookie kan stelen – dan kan diegene zich voordoen als jou. Dat is, in essentie, de kern van veel aanvallen die we in dit boek zullen behandelen.

De afgelopen drie decennia is het web gegroeid van een netwerk van statische documenten naar een platform waarop de gehele menselijke beschaving draait. We doen ons bankzaken via het web. We beheren onze gezondheidsgegevens via het web. We besturen kritieke infrastructuur via het web. En de fundamentele architectuur onder dit alles is nog steeds een protocol dat ontworpen was om wetenschappelijke papers te delen.

Stel je voor dat je een stad bouwt op de fundamenten van een tuinhuisje. Dat is het moderne web. En het is de taak van de penetratietester om de scheuren in die fundamenten te vinden voordat het gebouw instort.

De OWASP Top 10: een catalogus van collectief falen

Als je een arts zou vragen wat de tien meest voorkomende ziekten zijn, zou je een lijst verwachten die af en toe verandert naarmate de medische wetenschap vordert. Nieuwe ziekten worden ontdekt, oude worden uitgeroeid, en de rangorde verschuift.

De OWASP Top 10 – de lijst van de tien meest kritieke beveiligingsrisico’s voor webapplicaties – zou op dezelfde manier moeten werken. Maar dat doet hij niet. De lijst verandert wel, maar niet omdat we oude problemen hebben opgelost. Hij verandert omdat we er nieuwe problemen bij hebben gekregen terwijl we de oude gewoon laten liggen. Het is alsof de medische wereld malaria nog steeds niet had weten te behandelen, maar ondertussen wel vijf nieuwe auto-immuunziekten had ontdekt.

Laten we de huidige OWASP Top 10 doorlopen, niet als een academische exercitie, maar als een rondleiding door de schade die decennia van slordig programmeren hebben aangericht.

A1 – Broken Access Control

Dit staat op nummer een. Niet omdat het een nieuw probleem is, maar omdat het zo oud en zo wijdverspreid is dat het weigert om weg te gaan, als een huisgenoot die al lang geleden had moeten verhuizen maar nog steeds op de bank zit.

Broken Access Control betekent dat een applicatie niet goed controleert of een gebruiker daadwerkelijk mag doen wat hij probeert te doen. Mag Jan het profiel van Piet bekijken? De applicatie zegt: “Jan heeft een geldige sessie, dus ja.” Maar niemand heeft ooit geprogrammeerd dat Jan alleen zijn eigen profiel mag zien.

Het is het digitale equivalent van een gebouw waar alle deuren wel een slot hebben, maar waar iedereen dezelfde sleutel heeft gekregen.

A2 – Cryptographic Failures

Vroeger heette dit “Sensitive Data Exposure”, maar OWASP heeft het hernoemd omdat het probleem niet is dat data blootgesteld wordt – het probleem is dat de cryptografie die die data had moeten beschermen, niet deugt.

Dit gaat over wachtwoorden die als MD5-hash worden opgeslagen (MD5 is zo zwak dat je er beter een briefje op de monitor kunt plakken – het effect is hetzelfde). Het gaat over HTTPS-certificaten die verlopen zijn. Het gaat over encryptiesleutels die hardcoded in de broncode staan, als een geheime deur in een muur die iedereen kan zien.

A3 – Injection

SQL Injection. Command Injection. LDAP Injection. De naam verandert, het principe blijft: de applicatie neemt gebruikersinvoer en verwerkt die als code. Het is alsof je een bestelling opneemt in een restaurant en de klant zegt: “Ik wil graag een biefstuk, en doe de kluis ook maar open.” En de ober het gewoon doorgeeft aan de keuken.

We weten al meer dan twintig jaar hoe je dit voorkomt: parameterized queries, input validation, prepared statements. Het staat in elk handboek. Het staat in elke cursus. Het staat in elke code review checklist. En toch is het nog steeds op plek drie.

A4 – Insecure Design

Dit is een relatief nieuwe toevoeging, en het is de meest pijnlijke. Want Insecure Design betekent niet dat de implementatie een fout bevat – het betekent dat het ontwerp zelf onveilig is. Je kunt de code perfect schrijven, alle best practices volgen, en nog steeds een onveilige applicatie opleveren als het ontwerp niet klopt.

Het is het verschil tussen een huis dat slecht gebouwd is en een huis dat op de verkeerde plek staat. Je kunt het huis repareren, maar je kunt het niet verplaatsen.

A5 – Security Misconfiguration

De standaardinstellingen zijn onveilig. De foutmeldingen lekken informatie. De directory listing staat aan. De debug modus draait in productie. De admin console is toegankelijk via het internet. Het default wachtwoord is nooit veranderd.

Security misconfiguration is het bewijs dat de meeste organisaties hun software behandelen als een meubelstuk van IKEA: ze volgen de instructies net genoeg om het overeind te krijgen, maar al die extra schroeven die overblijven? Die gooien ze weg. Die extra schroeven zijn je beveiligingsinstellingen.

A6 – Vulnerable and Outdated Components

De gemiddelde webapplicatie is als een huis dat gebouwd is met materialen van de sloop. Stukjes jQuery van tien jaar geleden. Een logging library die al drie jaar niet meer onderhouden wordt. Een framework waarvan versie 2.3.1 een bekende kwetsbaarheid heeft, maar niemand heeft ooit gecontroleerd welke versie er draait.

Dit is geen technisch probleem. Dit is een managementprobleem. Iemand moet verantwoordelijk zijn voor het bijhouden van dependencies. Maar niemand wil die persoon zijn, want het is saai werk dat nooit complimenten oplevert – totdat het misgaat, en dan is het ineens ieders probleem.

A7 – Identification and Authentication Failures

Zwakke wachtwoorden worden geaccepteerd. Brute force is niet geblokkeerd. Multi-factor authenticatie is “op de roadmap”. Session tokens worden niet geroteerd na het inloggen. Wachtwoord-reset tokens verlopen nooit.

Als Broken Access Control het probleem is dat je overal binnen kunt als je eenmaal binnen bent, dan is dit het probleem dat binnenkomen te makkelijk is. Het zijn twee kanten van dezelfde medaille, en die medaille is gemaakt van karton.

A8 – Software and Data Integrity Failures

Dit gaat over situaties waarin een applicatie aanneemt dat data die van buiten komt, te vertrouwen is. Ongevalideerde deserialisatie. CI/CD pipelines zonder integriteitscontroles. Automatische updates zonder signature verification.

Het is alsof je een pakketje aanneemt van een koerier die geen uniform draagt, geen identificatie heeft, en aanbelt bij het verkeerde adres. Maar het pakketje ziet er goed uit, dus je maakt het gewoon open.

A9 – Security Logging and Monitoring Failures

Als een inbreker je huis binnendringt en je hebt geen beveiligingscamera’s, geen alarm, en geen buren die opletten, dan weet je niet eens dat er ingebroken is tot je op een dag je sieraden mist.

De meeste webapplicaties loggen niet genoeg. Ze loggen niet de juiste dingen. Ze bewaren de logs niet lang genoeg. En als ze al loggen, kijkt er niemand naar. Security monitoring is het digitale equivalent van een rookmelder die je hebt geinstalleerd maar waarvan je de batterijen hebt verwijderd omdat hij af en toe een piepje gaf.

A10 – Server-Side Request Forgery (SSRF)

SSRF is de nieuwkomer die meteen op de A-lijst terechtkwam. Bij SSRF misleid je een server om namens jou verzoeken te doen naar plekken waar jij zelf niet bij kunt. Het is alsof je een medewerker vraagt om even een dossier uit de kluis te halen, en hij doet het zonder te vragen waarom jij dat dossier nodig hebt.

Met de opkomst van cloud computing is SSRF bijzonder gevaarlijk geworden, want die cloud metadata endpoints die alleen toegankelijk zouden moeten zijn vanaf de server zelf? Een SSRF-kwetsbaarheid geeft je precies die toegang.

Het fascinerende aan deze lijst is niet wat erop staat, maar hoe weinig hij verandert. Het is alsof de medische wereld jaar na jaar publiceert dat handen wassen ziektes voorkomt, en iedereen zegt “ja, goed punt”, en vervolgens niet zijn handen wast.

De reden dat penetratietesting als beroep bestaat, is niet dat aanvallen zo geavanceerd zijn. Het is dat verdediging zo slordig is.

Incompetent Bastard opzetten

Genoeg theorie. Laten we iets doen.

Incompetent Bastard is een Flask-applicatie die je lokaal draait. Het is bewust ontworpen om alleen op je eigen machine te draaien – niet op een server die bereikbaar is via het internet. Dit is een pentest-werkbank, geen productiesite.

Vereisten

Je hebt het volgende nodig:

• Python 3.10 of hoger
• pip (Python package manager)
• git (om de repository te klonen)
• Een terminal waarin je je thuisvoelt
• Optioneel: pandoc en LaTeX (voor rapportgeneratie)

Stap 1: Clone de repository

git clone <repository-url> incompetentbastard
cd incompetentbastard

Stap 2: Virtual environment aanmaken en activeren

python3 -m venv .venv && . .venv/bin/activate

Een virtual environment is het equivalent van een schone werkbank. Alles wat je installeert blijft in die omgeving, en je vervuilt je systeem-Python niet met dependencies die je over drie maanden vergeten bent.

Stap 3: Dependencies installeren

pip install -r requirements.txt

Dit installeert Flask, SQLAlchemy, Flask-Migrate, WTForms, de sh library voor pandoc-integratie, en een hele rits andere packages die IB nodig heeft.

Stap 4: De applicatie starten

flask --app app:create_app run --host 127.0.0.1 --port 5000

Let op het adres: 127.0.0.1. Dat is localhost. Dat is alleen jouw machine. Dit is bewust. IB luistert standaard niet op 0.0.0.0 omdat het niet de bedoeling is dat je pentest-dashboard bereikbaar is voor het hele netwerk.

Stap 5: Open je browser

Navigeer naar http://127.0.0.1:5000/dashboard. Als alles goed is gegaan, zie je het IB dashboard. Als je geen dashboard ziet maar een pagina met “Een moment a.u.b.” en een script tag, dan werkt de beveiliging: je benadert IB niet vanaf localhost, en de applicatie serveert je in plaats daarvan het XSS beacon script.

Ja, je leest dat goed. Als je IB benadert vanaf een ander IP-adres dan localhost, krijg je een XSS hook geserveerd in plaats van het dashboard. Dat is een bewuste ontwerpkeuze. IB is tegelijkertijd het dashboard voor de pentester en een payload delivery platform voor doelwitten. Meer hierover in het hoofdstuk over XSS.

Omgevingsvariabelen

IB wordt geconfigureerd via environment variables. De belangrijkste:

Als SECRET_KEY niet is gezet, genereert IB bij elke herstart een nieuwe. Dat betekent dat alle sessies ongeldig worden. Voor ontwikkeling is dat prima. Voor een langlopende engagement wil je een vaste key instellen.

Welkom op het dashboard

Als je IB opent op http://127.0.0.1:5000/dashboard, betreed je de cockpit van je pentest. Laten we een rondleiding maken.

Het hoofdscherm

Het dashboard is opgebouwd uit meerdere panelen die je in een oogopslag een overzicht geven van je engagement:

• Hooked Clients – bovenaan zie je hoeveel browsers momenteel “hooked” zijn via het XSS beacon. Dit zijn browsers die het x.js script hebben geladen en nu actief data terugsturen naar IB.
• Cookies – een lijst van gestolen cookies van hooked clients, met datum, IP-adres, en de inhoud van de cookie.
• Keylogger – toetsaanslagen die zijn vastgelegd door het XSS beacon.
• LocalStorage – de inhoud van localStorage van hooked browsers.
• Findings – een overzicht van alle bevindingen die je hebt vastgelegd, met hun OWASP-categorie en CVSS-score.
• Notes – vrije notities die je tijdens het testen kunt maken.

De navigatie

Via de navigatiebalk heb je toegang tot alle modules:

• Commands – de Command Library met 194 commando’s, doorzoekbaar en gecategoriseerd. Van web_sqli_union tot ad_bloodhound_collect, van shell_powercat tot tunnel_ssh_socks.
• Findings – het findings management systeem waar je bevindingen aanmaakt, bewerkt, categoriseert, en exporteert.
• Tasks – de Task Runner waarmee je voorgedefinieerde taken kunt uitvoeren: network scans, brute force aanvallen, exploit scripts.
• Screen – een terminal interface voor het bekijken van screen sessies.
• Notes – een notitiesysteem dat je kunt koppelen aan je rapport.
• Recordings – opnames van terminal sessies.
• Files – bestandsbeheer voor payloads en tools.

De labs

Naast het dashboard heeft IB vijf interactieve labs, elk met een eigen blueprint:

1. XSS Lab (/xxs/) – een compleet Cross-Site Scripting platform met cookie stealing, keylogging, localStorage exfiltratie, en command & control voor hooked browsers.
2. XXE Lab (/xxe/) – XML External Entity out-of-band data exfiltratie.
3. CSRF Lab (/csrf.) – Cross-Site Request Forgery injection endpoints.
4. SQLi Lab (/sqli2/) – SQL Injection oefenomgeving.
5. SSRF Lab (/ssrf/) – Server-Side Request Forgery redirect endpoints voor cloud metadata simulatie.

Elk lab is ontworpen als een functioneel aanvalsplatform. Dit zijn geen speelgoedvoorbeelden – dit zijn werkende tools die je inzet tijdens een echte pentest.

Finding templates

IB wordt geleverd met veertien standaard finding templates, gebaseerd op de meest voorkomende webapplicatie-kwetsbaarheden:

Elke template bevat een volledige beschrijving van de kwetsbaarheid, de impact, de aanbeveling, CVSS 4.0 vectoren, CWE-referenties, en MITRE ATT&CK technique ID’s. Wanneer je een bevinding aanmaakt, selecteer je de template en vult je de specifieke details in: de locatie, het bewijs, de exploitstappen.

CVSS 4.0 Calculator

IB bevat een ingebouwde CVSS 4.0 calculator die je kunt gebruiken bij het aanmaken van findings. Je stelt de elf base metrics in – Attack Vector, Attack Complexity, Attack Requirements, Privileges Required, User Interaction, en de zes impact metrics – en IB berekent de score en severity rating automatisch.

De calculator is beschikbaar via de API op /api/cvss4/calculate en is geintegreerd in het findings formulier. Je hoeft niet meer naar een externe website te gaan om je CVSS-score te berekenen.

Rapportgeneratie

Wanneer je klaar bent met testen, genereert IB een rapport op basis van je bevindingen en notities. Het rapport wordt gegenereerd in LaTeX, geconverteerd naar Markdown via pandoc, en kan van daaruit naar elk gewenst formaat.

Het rapport bevat: - Een verkenningssectie op basis van je notities - Alle bevindingen, gegroepeerd per template - OWASP-categorisatie en CVSS-scores - Kruisverwijzingen tussen bevindingen - Screenshots en evidence

De methodologie: hoe een webpentest eruitziet

Een penetratietest is geen willekeurige aanval. Het is een gestructureerd proces, net zo methodisch als een wetenschappelijk experiment. Je hebt een hypothese (dit systeem is kwetsbaar), een methode (zo ga ik dat testen), resultaten (dit heb ik gevonden), en conclusies (dit moet er veranderen).

De methodologie die we in dit boek volgen, bestaat uit vijf fasen. Elke fase bouwt voort op de vorige, en het overslaan van een fase is het equivalent van een arts die een diagnose stelt zonder de patient te onderzoeken.

Fase 1: Scope en planning

Voordat je ook maar een enkele byte over het netwerk stuurt, moet je weten wat je mag testen. De scope definieert de grenzen van je engagement:

• Welke domeinen en IP-adressen zijn in scope?
• Welke applicaties mag je testen?
• Zijn er systemen die expliciet uitgesloten zijn?
• Wat zijn de tijdsvensters waarbinnen je mag testen?
• Wie is je aanspreekpunt bij de opdrachtgever?
• Wat doe je als je kritieke kwetsbaarheden vindt?

Dit is het moment waarop je de schriftelijke toestemming regelt. Geen scope, geen toestemming, geen test. Zo simpel is het.

Fase 2: Verkenning (reconnaissance)

Dit is de fase waarin je alles leert over je doelwit zonder het daadwerkelijk aan te vallen. Je verzamelt informatie uit publieke bronnen: DNS-records, WHOIS-data, certificaattransparantielogs, sociale media, vacatureteksten (die verrassend veel onthullen over de technologie-stack van een bedrijf).

Je brengt de aanvalsoppervlakte in kaart: welke poorten zijn open? Welke services draaien er? Welke technologieen worden gebruikt? Welke versies?

Fase 3: Scanning en analyse

Nu ga je actiever te werk. Je gebruikt scanners om kwetsbaarheden te identificeren. Je test de applicatie handmatig: hoe reageert hij op onverwachte invoer? Wat gebeurt er als je een enkele quote in een zoekveld typt? Wat als je de waarde van een hidden field verandert? Wat als je een verzoek stuurt zonder session cookie?

Dit is de fase waarin je de OWASP Top 10 als checklist gebruikt. Niet als een afvinklijst, maar als een denkraamwerk: voor elke categorie vraag je je af of de applicatie kwetsbaar zou kunnen zijn, en dan test je die hypothese.

Fase 4: Exploitatie

Je hebt kwetsbaarheden gevonden. Nu ga je bewijzen dat ze daadwerkelijk misbruikt kunnen worden. Dit is niet het moment voor theoretische risico’s – dit is het moment waarop je laat zien wat een aanvaller echt zou kunnen doen.

Kun je via die SQL Injection bij de database? Kun je via die XSS session cookies stelen? Kun je via die SSRF de cloud metadata bereiken?

Het doel is niet om zoveel mogelijk schade aan te richten. Het doel is om de impact te demonstreren op een manier die de opdrachtgever begrijpt en serieus neemt. Een screenshot van admin:admin als werkende credentials is overtuigender dan een pagina uitleg over waarom zwakke wachtwoorden een risico vormen.

Fase 5: Rapportage

Dit is de fase die de meeste pentesters het minst leuk vinden en die de opdrachtgever het belangrijkst vindt. Je rapport is het enige tastbare resultaat van je werk. Als je rapport slecht is, maakt het niet uit hoe briljant je exploits waren.

Een goed pentest-rapport bevat:

• Een management samenvatting die een niet-technisch persoon begrijpt
• Een gedetailleerde beschrijving van elke bevinding
• De impact in zakelijke termen
• Reproduceerstappen zodat het ontwikkelteam het kan verifieren
• Concrete aanbevelingen, geprioriteerd op risico
• Verwijzingen naar standaarden (OWASP, CWE, MITRE ATT&CK)

De cyclus herhaalt zich

Een pentest is geen eenmalige gebeurtenis. Het is een momentopname. De applicatie verandert, nieuwe features worden toegevoegd, dependencies worden geupdate (of niet). Een goede pentest levert niet alleen een rapport op, maar ook een baseline waartegen toekomstige tests gemeten kunnen worden.

Een noot over automatisering en handmatig testen

Er is een hardnekkige mythe in de beveiligingsindustrie dat je kwetsbaarheden kunt vinden door een scanner te draaien en het rapport te lezen. Het is dezelfde mythe als beweren dat je een taal leert door Google Translate te gebruiken.

Scanners zijn nuttig. Ze vinden de voor de hand liggende dingen. Ze vinden de standaardfouten, de bekende CVE’s, de laaghangend fruit. Maar ze begrijpen geen context. Een scanner weet niet dat die specifieke parameter in die specifieke context leidt tot een chain van kwetsbaarheden die samen veel erger zijn dan elk afzonderlijk. Een scanner weet niet dat die ogenschijnlijk onschuldige redirect functie misbruikt kan worden om interne services te bereiken.

Handmatig testen is waar het echte werk zit. En dat is precies waarom IB ontworpen is als een werkbank en niet als een scanner: het helpt je bij het handmatige werk, het automatiseert het saaie deel (rapportage, categorizering, evidence management), en het laat het denkwerk aan jou.

Hoe de rest van dit boek is opgebouwd

De komende hoofdstukken volgen een logische volgorde die de methodologie weerspiegelt:

• Hoofdstuk 2-3: Verkenning en scanning – het in kaart brengen van je doelwit
• Hoofdstuk 4-10: De kwetsbaarheden – per type, met theorie, praktijk, en IB-oefeningen
• Hoofdstuk 11: Payload generatie en delivery
• Hoofdstuk 12: Rapportage en findings management
• Hoofdstuk 13: Geavanceerde technieken en chaining

Elk hoofdstuk bevat: - Historische context en achtergrond - Technische uitleg met voorbeelden - Praktische oefeningen met IB - IB Tips voor efficient gebruik van de tool - Referenties naar OWASP, CWE, en MITRE ATT&CK

Samenvatting en referentietabel

We hebben in dit hoofdstuk de fundamenten gelegd: de geschiedenis van het web en waarom het inherent onveilig is, de OWASP Top 10 als catalogus van steeds terugkerende fouten, het opzetten van Incompetent Bastard, een rondleiding door het dashboard, en de methodologie die we door het hele boek zullen volgen.

Hier is een referentietabel die de onderwerpen uit dit hoofdstuk koppelt aan de bijbehorende IB features:

In het volgende hoofdstuk beginnen we met de verkenningsfase. We gaan kijken hoe je een webapplicatie in kaart brengt, welke informatie je kunt verzamelen zonder ook maar een enkele aanval uit te voeren, en hoe je die informatie gebruikt om je teststrategie te bepalen.

Maar eerst: zorg dat IB draait. De rest van dit boek is praktijk.