File-Upload-Schwachstellen ausloten, ohne Gesetze zu brechen
Wie man Upload-Validierungen im eigenen Lab umgeht, Bugklassen kartiert und Webserver gegen RCE per Datei haertet.
Ein fehlkonfigurierter Upload-Endpunkt bleibt eine der billigsten Methoden, ein simples Formular in RCE zu verwandeln. In einem Lab aus DVWA, OWASP Juice Shop und einem Nginx 1.25 als Reverse Proxy kamen wir vom Avatar-Upload zur www-data-Shell in unter 40 Minuten. Vor jedem Payload zaehlt der Vertrag: Ziel ist die eigene VM, isoliert in einem Netz 10.10.0.0/24 ohne Internetroute, und das Endziel sind Hardening-Regeln, keine Trophaen. Wer diese Umgebung noch nicht stehen hat, sollte zuerst Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen durcharbeiten, bevor er weitermacht.
Die erste Bugklasse, die auftaucht, ist die Extension-Pruefung auf Client-Seite. Legacy-PHP liefert oft eine Blacklist (.php, .phtml, .php5) und keinerlei echte Content-Type-Pruefung. shell.php in shell.pHp.jpg umzubenennen, mit Burp abzufangen und Content-Type image/jpeg zu erzwingen, schlaegt rund 80 Prozent der Amateurfilter, die ich in Corporate-CTFs sehe. In einem juengsten Test gegen ein Lebenslauf-Modul reichte ein .gif mit GIF89a; , umbenannt in .phtml, fuer volle Ausfuehrung. Gescheitert ist nicht die Regex, sondern die Architektur: Apache hatte AddHandler an alles geheftet, was in irgendeinem Ordner auf .phtml endete.
Die zweite spannende Schicht ist das doppelte Parsing in altem Nginx (CVE-2013-4547 und moderne Abkoemmlinge). Eine Datei namens shell.jpg\x00.php taeuscht weiter Stacks aus Nginx + PHP-FPM mit schlampigem pathinfo. Im Lab habe ich das Szenario mit nginx:1.14-alpine und php:7.2-fpm rein historisch nachgebaut; mit Nginx 1.25 und cgi.fix_pathinfo=0 stirbt derselbe Payload. Diese Uebung passt gut zu SQL Injection in der Praxis: Ausnutzen, Erkennen und Mitigieren im Kontrollierten Lab: eine einzelne CVE zu jagen ist sinnlos, wenn man die komplette Request-Pipeline vom Load Balancer bis zum Interpreter nicht versteht.
Sobald das Backend Magic Bytes prueft, dreht sich das Spiel. GIF/PHP-Polyglots schlagen getimagesize(), scheitern aber an finfo plus Imagick mit Reprocessing. Der Trick ist, die Transformations-Pipeline anzugreifen: ImageMagick mit lockerer Policy verarbeitet weiter MVG und SVG, und die ImageTragick-Familie taucht in LMS-Forks immer wieder auf. Bei einem Fintech-Kunden fand ich einen Beleg-Upload, der convert ohne -limit memory und mit leerer policy.xml aufrief; ein 12 KB grosses SVG mit xlink:href auf file:///etc/passwd leakte den Inhalt in das generierte PDF. Fuer die reine SSRF-Webseite davon deckt SSRF Entmystifiziert: Cloud Metadata im Lokalen AWS-Lab Ausnutzen den fast identischen AWS-Fall ab.
Eine unterschaetzte Angriffsflaeche ist, wo die Datei landet. /var/www/uploads direkt von Apache ausgeliefert ist der Klassiker, doch das gleiche Problem zeigt sich in S3-Buckets mit falschem Content-Disposition und in CDNs, die HTML reprocessen. Path Traversal im Dateinamen (../../tmp/cron.d/pwn) funktioniert noch gegen Node-Middlewares, die dem Multer-originalname vertrauen. Fuer eine formellere Test-Checkliste, vor allem bei JSON-APIs mit eingebettetem Base64, vergleichen Sie mit Pentest von REST und GraphQL APIs: Technische Checkliste fur legales Bug Bounty und pruefen Groessenlimits, deklarierten vs erkannten Mimetype und Quoten pro authentifiziertem Nutzer.
Defensiv sind die Regeln, die ich in Reports schreibe, langweilig und wirksam: Zufallsname (UUIDv7), Ablage ausserhalb des Document Root, Auslieferung ueber einen Handler, der Content-Disposition: attachment und Content-Type: application/octet-stream erzwingt, serverseitige Mimetype-Pruefung mit libmagic und das Sperren doppelter Endungen direkt in Nginx mit location ~* \.(php|phtml|phar)\. { deny all; }. In Containern mounte ich das Upload-Volume als noexec,nosuid und fahre clamav als Sidecar. Kontinuierliche Pruefung gehoert in AppSec Shift-Left: SAST, SCA und Secrets Scanning ohne das Team auszubremsen, wo Semgrep schwache Validierungs-Regex schon vor dem Deploy einfaengt.
Ein ethischer Punkt, den ich in Schulungen wiederhole: diese Techniken gegen ein produktives SaaS 'nur zum Testen' nachzuspielen, ist kein Bug Bounty, sondern ein Verstoss gegen Paragraph 202c StGB in Deutschland und Aequivalente anderswo. Legitime Programme veroeffentlichen expliziten Scope, und selbst darin ist das Exfiltrieren von /etc/passwd unnoetig, wenn die VM-ID den Bug bereits beweist. Der Unterschied zwischen Forscher und Beschuldigtem ist meist der VM-Snapshot plus schriftliche Autorisierung. Praktisches Takeaway: nehmen Sie naechsten Sprint einen Upload-Endpunkt Ihres Produkts, schreiben Sie einen Integrationstest, der shell.phtml, .htaccess, ein GIF/PHP-Polyglot und ein SVG mit xlink hochzuladen versucht, und lassen Sie die Pipeline scheitern, wenn auch nur einer durchgeht. Das ist mehr wert als hundert Stunden Lektuere.