Entwicklertools · URL-Encoder und -Decoder
URL-Codierung ist keine Bereinigung: Decodierte Parameter müssen weiterhin maskiert werden
· Warum es wichtig ist
URL-Kodierung Sicherheit xss
Prozentkodierung schützt die URL-Struktur, nicht Ihr HTML, SQL oder Ihre Shell. In diesem Beitrag wird erläutert, warum ein korrekt codierter Wert in dem Moment, in dem er decodiert wird, wieder gefährlich wird und welches Escapezeichen wohin gehört.
Warum URL-Verschlüsselung allein XSS-Angriffe nicht stoppen kann
Ein „sicherer“ Parameter kann ein Skript ausführen, wenn er für die Übertragung codiert, aber vor dem Rendern decodiert wird. Betrachten Sie XSS-Nutzdaten wie das img-Tag mit dem prozentualen Code des Onerror-Handlers als %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E. Wenn dies in der URL übertragen und vom Anwendungscode dekodiert wird, bevor es in HTML eingefügt wird, sieht der Browser das ursprüngliche Markup und führt den Handler aus. Prozentkodierung ist eine Darstellungsebene; ändert nichts an der zugrunde liegenden Bedrohung.
Die Nutzlast ist nur während der Übertragung sicher, wenn es sich um eine codierte Zeichenfolge ohne besondere Bedeutung für HTTP oder URL-Parser handelt. Sobald es entschlüsselt wird, wird es wieder gefährlich, da es in seine ursprüngliche Form zurückkehrt. Jeder nachgelagerte Kontext muss seine eigenen Escape-Regeln anwenden, die der Art und Weise entsprechen, wie er Daten verwendet. Die URL-Codierung ist kein Ersatz für HTML-Escape, SQL-Parametrisierung oder Shell-Argumentbehandlung.
Der Zweck der Prozentkodierung besteht darin, Trennzeichen auf der Leitung eindeutig zu halten, nichts weiter
Die prozentuale Kodierung schützt die URL-Struktur präzise. Das kaufmännische Und bleibt Teil der Abfragezeichenfolgensyntax und wird nicht als Trennzeichen uminterpretiert. Schrägstrich wird nicht zum Pfadtrennzeichen. Das Fragezeichen startet das Fragment nicht. Durch die Codierung reservierter Zeichen als %XX behandelt der Parser sie als Daten und nicht als Syntax. Dies funktioniert für einen einzigen Zweck: die Eindeutigkeit der URL-Struktur im Internet sicherzustellen.
Durch die Dekodierung wird diese Einbahnstraße genau umgekehrt. Die wiederhergestellten Bytes sind genau das, was codiert wurde, nicht mehr und nicht weniger. Gefährliche HTML-Zeichenfolgen bleiben gefährlich, SQL-Injection-Vektoren bleiben gefährlich und Shell-Befehle bleiben gefährlich. Prozentkodierung ist keine Eingabevalidierung, keine Bereinigung und keine Sicherheitsgrenze. Es handelt sich lediglich um ein Darstellungsformat.
Durch die Dekodierung werden die ursprünglichen Bytes wiederhergestellt, sodass jeder Downstream-Kontext den Rohwert wieder sieht
Beim kontextspezifischen Entkommen kommt echter Schutz wirklich zum Tragen. Der HTML-Kontext benötigt Entitäten: „kleiner als“ wird zu „<“, „größer als“ wird zu >, Anführungszeichen werden zu „, kaufmännisches Und wird zu &. Der SQL-Kontext benötigt parametrisierte Abfragen, die die Struktur von den Daten trennen und verhindern, dass Angreifer ausbrechen. Der Shell-Kontext benötigt Argumentarrays, die Wortaufteilung und Globbing vollständig vermeiden.
Jeder Kontext hat unterschiedliche gefährliche Charaktere und genau unterschiedliche Fluchtregeln. HTML-Entitäten sind in SQL-Abfragen harmlos, aber für den Schutz dort unbrauchbar. Backslash verhindert die SQL-Injection in einigen Datenbanken, in anderen jedoch nicht. Das Shell-Escape hängt vom Zitierstil ab. Der Entwickler muss das Ziel verstehen, bevor er entscheidet, wie mit Daten umgegangen werden soll.
Kontextspezifisches Escapen – HTML-Entitäten für Markup, parametrisierte Abfragen für SQL, Argumentarrays für Shells
Funktioniertes Beispiel: Das Verfolgen der Nutzlast vom Link zum Protokoll zur Seite zeigt, wo Codierung und Escape erfolgen müssen. Der Link enthält codierte XSS-Nutzdaten als Abfrageparameter. Der Server empfängt es weiterhin codiert im HTTP-Anfragetext. Die Anwendung dekodiert den Abfrageparameter, um ihn auf der Seite anzuzeigen. Ohne dass die Ausgabe entweicht, rendert der Browser die Nutzlast als HTML und führt sie aus.
Wenn derselbe Parameter in einer Datei protokolliert wird, enthält der Protokolleintrag eindeutig dekodierte Nutzdaten. Die zweite Anwendung liest das Protokoll, dekodiert es erneut und fügt es ohne Escapezeichen in die HTML-Seite ein. Nutzlast wird zum zweiten Mal ausgeführt. Bei jedem Schritt wurde vom Kontext bestimmt, was sicher war. Die URL-Dekodierung war sicher. Die Dateispeicherung war sicher. Aber die HTML-Ausgabe ohne Escape war fatal.
Funktioniertes Beispiel: Verfolgen einer Nutzlast vom Link zum Protokoll zur Seite – wo sie codiert wird, wo sie decodiert wird und wo sie maskiert werden muss
Die Kodierung als Tool zur Filterumgehung zeigt, warum Angreifer doppelt kodieren und Hex-Groß-/Kleinschreibung erheblich vermischen. Wenn die Firewall nach dem IMG-Tag sucht, sendet der Angreifer %3Cimg und hofft, dass die Anwendung einmal dekodiert, die Firewall jedoch nicht. Wenn die Validierung %3Cimg ablehnt, aber eine andere Groß-/Kleinschreibung zulässt, werden dieselben Bytes in dieselbe Nutzlast dekodiert. Die Sicherheit abhängig von der durch Mustervergleich codierten Eingabe ist fraglich.
Die Dekodierung muss absolut exakt und vorhersehbar sein. Die kanonische Form (kleiner Hexadezimalbuchstabe, bekannte Kodierung) ermöglicht eine konsistente Richtlinie, löst jedoch nicht das zugrunde liegende Problem. Der einzige zuverlässige Ansatz besteht darin, bei Bedarf die Dekodierung zuzulassen und unmittelbar vor der Verwendung kontextspezifisches Ausgabe-Escape-Verfahren anzuwenden. Die Dekodierung ist niemals sicher; nur für die Übertragung notwendig.
Kodierung als Werkzeug zur Filterumgehung – warum Angreifer doppelt kodieren und Hex-Groß-/Kleinschreibung mischen und warum die Dekodierung exakt sein muss
Eine vollständige XSS-Verteidigung erfordert ein vollständiges Verständnis der Datenströme, der Kontexte, die sie bei jedem Schritt durchlaufen, und der Anforderungen, die die einzelnen Kontexte erfüllen müssen. Die URL-Codierung ist ein kleiner Teil: Sie behält die Struktur nur während der Übertragung bei. Aber eine einzelne Figur allein ist noch nie eine Verteidigung. Viele Entwickler verwechseln Codierung mit Bereinigung, da beide das Ersetzen von Zeichen beinhalten, aber völlig unterschiedliche wichtige Aufgaben erfüllen.
Die Web Application Firewall kann Muster in Anforderungsnutzlasten erkennen, aber die Codierung umgeht einfache Mustervergleichstechniken leicht. Die WAF-Optimierung ist komplex und geht über die URL-Kodierung hinaus. Zuverlässiger Schutz besteht darin, dass die Ausgabe im Anwendungscode maskiert wird, gepaart mit der Eingabevalidierung, sofern dies für Ihren spezifischen Kontext und Ihre Anforderungen sinnvoll ist.
Was dies nicht abdeckt – ein vollständiger XSS-Verteidigungsleitfaden oder die Optimierung der Webanwendungs-Firewall
Für eine vollständige XSS-Verteidigung ist ein vollständiges Verständnis der Datenströme, der Kontexte, die sie bei jedem Schritt durchlaufen, und der Anforderungen an die Escape-Funktion jedes Kontexts in der gesamten Anwendung erforderlich. Die URL-Kodierung ist ein kleiner Teil: Sie behält die Struktur nur während der Übertragung bei. Aber eine einzelne Figur allein ist noch nie eine Verteidigung. Viele Entwickler verwechseln Kodierung mit Bereinigung, da beide das Ersetzen von Zeichen beinhalten, während der Entwicklung jedoch völlig unterschiedliche wichtige Aufgaben erfüllen.
Testen Sie die Nutzlast durchgängig, um zu sehen, wo Kodierung und Escapeing im gesamten Prozess wirklich eine Rolle spielen. Fügen Sie %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E in den URL-Decoder ein und beobachten Sie, wie eine Zeichenfolge wie Markup aussieht. Fügen Sie dann das Ergebnis in den HTML-Entity-Escaper ein, um zu sehen, wie es zu sicherem Text wird. Zwei Werkzeuge zeigen deutlich sichtbare Schichten.
Takeaway: Codieren für die URL, Escape für die Ausgabe – wie der URL-Encoder und -Decoder und der HTML-Entity-Escaper in einem Produkt für die beiden verschiedenen Aufgaben nebeneinander sitzen
Die Schlussfolgerung ist, dass Codierung und Escape immer auf verschiedenen Ebenen getrennte Anliegen sind. Die URL-Verschlüsselung schützt nur die übertragene Struktur. Ausgabe-Escape schützt gerenderte Inhalte. Bei korrekt codierten Werten muss die Ausgabe immer noch maskiert werden, wenn sie HTML erreichen. Eine korrekt maskierte Zeichenfolge benötigt nie eine URL-Codierung, wenn sie nicht in die URL eingefügt wird.
Wenden Sie die richtige Verteidigung wirklich auf der richtigen Ebene an. Verlassen Sie sich nicht auf die URL-Verschlüsselung, um XSS-Angriffe zu stoppen. Verlassen Sie sich nicht auf HTML-Escape, um die URL-Struktur beizubehalten. Verstehen Sie Ihren Datenfluss und wenden Sie bei jedem Schritt die entsprechende Transformation an. Mit dem URL-Encoder können Sie sehen, was die Codierung bewirkt. Verwenden Sie dann den HTML-Entity-Escaper für den Ausgabeschritt.