2011-01-07 6 views
5

Lets sagen, ich habe eine Web-Anwendung, die Latin1 oder eine Standard-englische Sprachcodierung verwendet. Ich möchte die Anwendung ändern, um UTF-8 oder eine andere Sprachcodierung zu verwenden. Können Sie beweisen, dass diese Änderung XSS einführen wird?Kann XSS eingeführt werden, indem die Sprachkodierung geändert wird?

Dies ist keine PHP-spezifische Frage, aber in PHP können Sie einen Fall zeigen, in dem htmlspecialchars($var,ENT_QUOTES); anfällig für XSS ist und htmlspecialchars($var,ENT_QUOTES,'UTF-8'); nicht ist.

Antwort

1

Von RFC 3629:

10. Sicherheitsüberlegungen

Implementers von UTF-8 Notwendigkeit die Sicherheitsaspekte zu berücksichtigen, wie sie illegal UTF-8-Sequenzen verarbeiten . Es ist denkbar, dass unter bestimmten Umständen ein Angreifer einen unvorsichtigen UTF-8-Parser ausnutzen könnte, indem er eine Octet-Sequenz sendet, die nicht durch die UTF-8-Syntax erlaubt ist.

Eine besonders feine Form dieses Angriff gegen einen Parser ausgeführt werden, die sicherheitskritische Validitätsprüfungen gegen die UTF-8-codierte Form seines Eingang führt, deutet aber bestimmte illegal Oktett-Sequenzen als Zeichen . Für Beispiel könnte verbieten ein Parser die NUL-Zeichen, wenn sie als single-Oktett-Sequenz 00 codiert, aber irrtümlicherweise die illegale zwei Oktett-Sequenz C0 80 erlauben und interpretieren als NUL Charakter.Ein anderes Beispiel könnte ein Parser sein, der die Oktettreihenfolge 2F 2E 2E 2F ("/../") verbietet, jedoch die illegale Oktettreihenfolge 2F C0 AE 2E 2F erlaubt. Dieser letzte Exploit wurde tatsächlich in ein weit verbreitetes Virus verwendet, das Web Server in 2001 angriff; so ist die Sicherheit Bedrohung sehr real.

es ist also von entscheidender Bedeutung, um sicherzustellen, dass Ihre Daten ist gültige UTF-8.

Aber sobald Sie dies getan haben, sind Sicherheitsbedenken im Zusammenhang mit der Codierung minimal. Alle HTML-Sonderzeichen sind in ASCII und UTF-8 wie ISO-8859-1 ist vollständig ASCII-kompatibel. htmlspecialchars verhält sich so, wie Sie es erwarten.

Es gibt mehr ein Problem mit nicht-ASCII-kompatiblen Kodierungen. Zum Beispiel können in GB18030 die ASCII-Bytes 0x30 und höher innerhalb der Codierung eines Multi-Byte-Zeichens auftreten. Das HYPHEN-Zeichen (U + 2010) ist als A9 5C codiert, das einen ASCII-Backslash enthält. Dies macht es schwieriger, Backslash-Escapes korrekt zu handhaben, indem Sie SQL injection einladen.

+0

Das ist eine sehr gute Antwort. Vielen Dank. – rook

4

Hier ist ein dummes Beispiel, das betrügt, indem es htmlspecialchars von, wie Sie beabsichtigten, mißbraucht.

<?php 
$s = htmlspecialchars($_GET['x'], ENT_QUOTES); 
$s_utf8 = htmlspecialchars($_GET['x'], ENT_QUOTES, 'UTF-8'); 

if(!empty($s)) 
    print "default: " . $_GET['x'] . "<br>\n"; 

if(!empty($s_utf8)) 
    print "utf8: " . $_GET['x'] . "<br>\n" 
?> 

Senden Sie alle XSS-Nutzdaten und fügen Sie ein ungültiges UTF-8-Byte, z.

http://site/silly.php?x=<script>alert(0)</script>%fe

htmlspecialchars kautionen auf einer ungültigen UTF-8-Byte-Sequenz und einen leeren String zurück. Drucken der $_GET Wert ist ein offensichtliches Loch, aber ich habe einen Punkt zu machen.

Kurz gesagt, werden Sie Byte-für-Byte-Prüfungen mit Latin1 und UTF-8 bekommen, so dass mir ein sprachabhängiges Beispiel nicht bekannt ist, bei dem htmlspecialchars ein gefährliches Byte in einer Codierung auslässt, aber nicht Ein weiterer.

Der Punkt meines Beispiels ist, dass Ihre Frage allgemeiner war (und vielleicht ein bisschen zu vage) zu den Gefahren von XSS, wenn Kodierungsschemas geändert werden. Wenn der Inhalt mit der unterschiedlichen Multi-Byte-Codierung beginnt, können Entwickler Validierungsfilter auf Basis von strchr(), strlen() oder ähnlichen Überprüfungen, die nicht Multi-Byte-fähig sind und durch eine% 00 in der Nutzlast vereitelt werden, verfälschen. (Hey, einige Entwickler halten sich immer noch daran, Regexes zu verwenden, um HTML zu parsen und zu bereinigen.)

Im Prinzip denke ich, dass die beiden Beispielzeilen in der Frage die gleiche Sicherheit haben wie Schaltcodierung. In der Praxis gibt es noch viele Möglichkeiten, andere Fehler mit mehrdeutiger Codierung zu machen.

+0

+1, interessant. – rook

+0

Ich denke, ein weiterer Punkt, den ich hätte machen können, ist "Kennen Sie Ihre Fehlerbehandlung" - es kann ziemlich schwierig werden, sich mit ungültigen Byte-Codes zu befassen oder durch unerwartetes Verhalten überrascht zu werden. – Mike

+0

yeah Ich stimme zu, andere Funktionen können Fehler aus und geben eine leere Zeichenfolge zurück, wenn Sie versuchen, ihnen ein Array übergeben? Pass [] = 1, aber ich wusste nicht über ungültige UTF8, das ist cool. – rook

Verwandte Themen