Ga naar hoofdinhoud

File Upload — High

Nu wordt het lastiger. De MIME-type header manipuleren werkt niet meer, want de server voert een dieptecontrole uit op het bestand.

1. Predict (Voorspel)​

De backend code splitst de naam van het bestand en eist dat het exact eindigt op .jpg, .jpeg of .png. Daarnaast gebeurt er dit:

// Haal afmetingen van het bestand op
if( !getimagesize( $_FILES[ 'uploaded' ][ 'tmp_name' ] ) ) {
    echo "Dit is geen geldige afbeelding!";
}

Vraag: De functie getimagesize() trekt de eerste paar bytes van het bestand open op zoek naar een Image Signature (de zogeheten Magic Bytes van een JPG of PNG) om te verifiëren dat het echt een foto is. Kun je dit omzeilen?

Antwoord

Je kunt de naam veranderen naar shell.jpg, maar de getimagesize() functie zal dan nog steeds falen. Echter... een hacker kan een compleet geldige JPG afbeelding downloaden, en met gespecialiseerde tools (zoals exiftool) PHP-code verstoppen in de metagegevens (bijv. in de auteur/copyright velden) van de afbeelding! De server scant de Magic Bytes: geldig! De extensie is .jpg: geldig! De gevaarlijke foto met PHP-code passeert het filter.

2. Run & Investigate​

Start het lab.

Laden...

⚠️ Labbeperking: Deze aanval vereist geavanceerde tools zoals exiftool en een combinatie met de File Inclusion kwetsbaarheid. Het lab hierboven simuleert de server-side logica, maar voor de volledige hands-on ervaring heb je een lokale DVWA-installatie nodig.

Probeer alle voorgaande trucs. Zelfs als je de extensie of de headers verandert, weigert hij. Je zult daadwerkelijk de Magic Bytes (zoals GIF89a) bovenaan in je Kladblok/bestand moeten zetten, of een echte foto moeten manipuleren, om de upload te laten slagen.

3. Modify & Make (Aanpassen & Maken)​

Stel dat het je gelukt is om een geldige afbeelding met PHP-code erin verstopt (hacked.jpg) op de server te uploaden.

Er is nog één probleem. De bestandsextensie is .jpg. Als we in onze browser naar http://localhost/.../hacked.jpg navigeren, toont de browser gewoon de foto en negeert de server onze verstopte PHP code, omdat de server denkt dat het alleen een afbeelding is!

Hoe activeer je de PHP-code in je bestand nu toch?

Tip

We moeten de webserver forceren om de .jpg in te laden alsof het een stuk broncode is. Denk terug aan de kwetsbaarheid van eerdere modules waarbij je bestanden van andere locaties kon inladen!

Antwoord

Je hebt een File Inclusion (LFI) kwetsbaarheid nodig om dit af te maken! Als je via de File Inclusion uitdaging de volgende URL opvraagt: ?page=../../hackable/uploads/hacked.jpg Dan zal de include() functie in de achtergrond de JPG-foto oppakken en klakkeloos als PHP-code op het scherm proberen te draaien! Dit is waarom het combineren van kwetsbaarheden het absolute meesterstuk is van een hacker.

4. ✓ Wat moest je zien?​

Controle
  • In een lokale DVWA-installatie: een gewone shell.php upload faalt nu met "Your image was not uploaded." — getimagesize() herkent geen Magic Bytes.
  • Een via exiftool geprepareerde JPG met PHP-code in de metadata wordt wél geaccepteerd; via File Inclusion (?page=../../hackable/uploads/hacked.jpg) voert de server de verstopte code uit.
  • In het iframe-lab hier: via Bekijk broncode zie je getimagesize() en de extensie-whitelist staan — dat is de logica die je in een lokale install daadwerkelijk omzeilt.

Lukt de upload niet eens met een echte JPG? Controleer dat de bestandsextensie écht .jpg, .jpeg of .png is en niet .JPG (sommige PHP-versies zijn hoofdlettergevoelig).