Multipart Parser verstehen: Wie Angreifer Validierungsmechanismen bei Datei-Uploads umgehen

Krypto-Events Krypto-Startups und Risikokapital

Datei-Uploads sind aus modernen Webanwendungen nicht mehr wegzudenken. Sie ermöglichen Nutzern das Hochladen von Bildern, Dokumenten oder anderen Dateien, um interaktive und personalisierte Erlebnisse zu schaffen. Gleichzeitig bergen sie aber auch erhebliche Sicherheitsrisiken. Besonders bei Multipart/Form-Data Parsers treten Probleme auf, die Angreifer gezielt ausnutzen können, um Validierungsmechanismen bei Datei-Uploads zu umgehen. Diese Sicherheitslücken sind oft auf inkorrekte oder unvollständige Implementierungen der RFC-Standards zurückzuführen und stellen eine ernsthafte Gefahr für die Integrität und Sicherheit von Webanwendungen dar.

Multipart/Form-Data ist das Format, das verwendet wird, um Dateien und Formulardaten über HTTP zu übertragen. Es besteht aus mehreren Teilen, die jeweils durch einen Boundary-String voneinander getrennt sind. Jeder Teil enthält zudem Header wie Content-Disposition und Content-Type, welche Metainformationen über die übermittelten Daten liefern. Trotz der festgelegten Standards gibt es jedoch zahlreiche Abweichungen und Interpretationsspielräume, welche zu Parsing-Inkonsistenzen zwischen unterschiedlichen Systemen und Sicherheitseinrichtungen wie Web Application Firewalls (WAFs) oder Load Balancern führen können. Ein Hauptproblem liegt darin, dass viele Multipart-Parser zu flexibel gestaltet sind, um mit unterschiedlichsten Nutzereingaben umgehen zu können.

Diese Flexibilität heißt in der Praxis oft, dass nicht jeder Schritt der RFC genau eingehalten wird. Während dies auf den ersten Blick hilfreich erscheint, öffnet es Angreifern eine breite Palette an Angriffsmöglichkeiten. Besonders kritisch ist die Validierung von Dateinamen und deren Erweiterungen, die häufig genutzt wird, um das Hochladen von Schadcode wie PHP-Skripten zu verhindern. Verschiedene Bypässe zeigen auf, wie Angreifer diese Schwachstellen ausnutzen. Beispielsweise kann das Duplizieren von Parametern im Content-Disposition Header wie „name“ oder „filename“ dazu führen, dass der Validator einer WAF einen anderen Wert liest als die eigentliche Anwendung im Backend.

Dadurch werden Filterregeln umgangen, da die Prüfestelle falschen oder harmlos erscheinenden Daten sieht, während die Anwendung gefährliche Dateien verarbeitet. Ein weiteres Beispiel ist die manipulierte Trennung zwischen Header und Body eines Multipart-Formparts. Der RFC schreibt eine präzise Folge von CRLF-Zeichen (Carriage Return + Line Feed) vor, um diese Abgrenzung zu markieren. Entfernt ein Angreifer einzelne CR-Zeichen oder verändert diese Sequenz, so kann es sein, dass der Parser einer WAF fehlschlägt, während das Backend mit einer robusteren Parser-Implementierung doch die Datei korrekt akzeptiert. Solche strukturellen Inkonsistenzen ermöglichen es Angreifern, die eigentliche Validierung zu umgehen.

Auch das Entfernen von Anführungszeichen um Parameterwerte an Stellen wie im Content-Disposition Header führt in vielen Fällen zu unterschiedlich interpretierten Eingaben. Backend-Parser, beispielsweise in PHP oder Node.js, sind meistens toleranter und akzeptieren auch ungequotete Werte. Dabei können WAFs, die strengere Parser einsetzen, diese Eingaben nicht ordnungsgemäß erkennen oder filtern. Die Folge ist, dass gefährliche Dateien mit beispielsweise .

php-Endungen unentdeckt durchgeschleust werden. Darüber hinaus wird zunehmend die Nutzung des Parameters „filename*“ im Content-Disposition Header problematisch. Dieser erlaubt die Verwendung von UTF-8 kodierten und URL-kodierten Dateinamen. Validatoren und Sicherheitsmechanismen, die keine korrekte Dekodierung durchführen, erkennen hiermit getarnte Datei-Endungen wie .php oder .

exe nicht und lassen somit schadhafte Uploads zu. Insbesondere beliebte Node.js Parser wie Busboy oder Python Flask unterstützen „filename*“ und sind daher anfällig für solche Bypässe. WAFs wie FortiWeb, Barracuda oder ModSecurity versuchen vielfach, solche Angriffe zu erkennen und abzuwehren. Allerdings besitzen sie oft eine eigene Multipart-Parser-Implementierung, die selbst wieder von den genannten Inkonsistenzen betroffen ist.

FortiWeb zeigt sich beispielsweise verwundbar gegen Duplikate von Headern oder Parameter-Manipulationen und Barracuda kann durch gezielt duplizierte Content-Disposition Header getäuscht werden. Auch Load Balancer wie HAProxy sind keine Ausnahme. HAProxy bietet zwar die Möglichkeit, mit Access Control Lists (ACLs) gewisse Parameter in HTTP-Requests zu prüfen, tut dies jedoch nur für x-www-form-urlencoded Anwendungen. Multipart/Form-Data-Requests werden von HAProxy nicht analysiert. Angreifer wandeln Anfragen folglich einfach in Multipart-Formate um, um ACL-Bedingungen zu umgehen.

Darüber hinaus können Mehrfach-Parameter in Multipart-Requests verwendet werden, um HAProxy-ACLs zu verwirren, während das Backend, etwa eine PHP-Anwendung, immer den letzten Parameterwert verarbeitet. Das Problem zieht sich durch viele Ebenen moderner Webinfrastrukturen. AWS WAF oder Lambda-Funktionen zum Schutz von APIs leiden im Wesentlichen unter denselben Einschränkungen wie HAProxy. Fehlende oder ungenaue Multipart-Parsing-Unterstützung führt dazu, dass Sicherheitsregeln umgangen werden können, was besonders gefährlich ist, da diese Dienste oft als letzte Schutzbarriere fungieren. Aufseiten der Server spiegelt sich die Unterschiedlichkeit des Parsings ebenfalls wider.

So ist der PHP-Eingabeparser relativ tolerant bei unvollständigen oder fehlerhaft formatierten Multipart-Anfragen, etwa wenn der schließende Boundary-String fehlt oder Dopplungen von Headern vorkommen. Diese Nachsicht führt jedoch dazu, dass nicht konforme Anfragen verarbeitet werden, die von einer WAF vielleicht abgelehnt worden wären. Aus Entwickler- und Sicherheitsperspektive ergibt sich daraus die dringende Notwendigkeit, Multipart-Parser strenger anhand der RFC-Spezifikationen zu gestalten oder zusätzliche Validierungsschichten einzuführen. Für viele WAF-Entwickler bedeutet dies, die Parser so zu verbessern, dass duplizierte Parameter und Header konsequent erkannt und abgelehnt werden, ebenso wie eine strengere Prüfung der Header-Syntax inklusive Anführungszeichen. Darüber hinaus ist es sinnvoll, neben statischen Prüfungen der Dateiendung auch die Dateiinhalte via Magic Bytes zu analysieren.

Eine weitere Schutzmaßnahme kann der Einsatz spezialisierter Antivirus-Scanner sein, die Uploads zusätzlich überprüfen. Es ist zudem ratsam, auf der Netzwerkebene mit Load Balancern oder Proxies Multipart-Parsing sicherzustellen oder zumindest Anfragen mit auffälligen Multipart-Mustern zu blockieren. Da viele Parser mit Abweichungen der CRLF-Trennung sowie dem Fehlen von Boundary-Endungen Probleme haben, sollten diese Besonderheiten im Abwehrkonzept berücksichtigt werden. Nicht zuletzt müssen Anwendungsteams sensibilisiert werden, dass allein auf die Validierung des Content-Type Headers oder den Dateinamen kein vollständiger Schutz besteht. Es bedarf eines ganzheitlichen Ansatzes, der Parsing, String-Validierungen, inhaltliche Prüfungen und gegebenenfalls eine Filterung auf verschiedenen Ebenen kombiniert.

Die Analyse moderner Multipart-Form-Data-Parser zeigt, dass die Komplexität und Flexibilität des Standards eine Herausforderung für die sichere Implementierung bildet. Angreifer nutzen implizite und explizite Unterschiede in der Behandlung von Multipart-Anfragen, um Sicherheitsfilter zu umgehen und schädliche Dateien hochzuladen. Um diesen Risiken entgegenzusteuern, müssen Entwickler und Sicherheitsberater bestehende Tools hinterfragen, eigene sorgfältige Prüfmechanismen aufbauen und kontinuierlich auf dem neuesten Stand der Technik bleiben. Mit Blick auf die Zukunft sind mutmaßlich neue Parser-Implementierungen gefordert, die strenger sind und komplexe Szenarien wie multiple gleiche Parameter, manipulierte Trennungen und internationale Dateinamen besser verarbeiten können. Dabei dürfen sie jedoch nicht zu restriktiv sein, um nicht legitime User-Aktionen unnötig zu blockieren.

Es gilt also ein sorgfältiges Gleichgewicht zwischen Kompatibilität und Sicherheit zu finden. Zusammenfassend lässt sich sagen, dass Multipart/Form-Data Parser heute eine entscheidende Schwachstelle im Bereich der Webanwendungssicherheit darstellen. Die inkonsistente Umsetzung der RFC-Standards in Kombination mit vielfältigen Bypass-Techniken machen sie zu einem bevorzugten Angriffspunkt für Hacker. Nur durch verbesserte Parser, umfassende Validierung und mehrschichtige Schutzmaßnahmen lassen sich Upload-Validierungen effektiv stärken und Sicherheitslücken vermeiden.