Sollte ich überlange UTF-8-Zeichenfolgen in ihre kürzeste Normalform umwandeln?

Question

Ich habe gerade mein Encoding::FixLatin Perl-Modul überarbeitet, um mit überlangen UTF-8-Byte-Sequenzen umzugehen und sie in die kürzeste Normalform zu konvertieren.

Meine Frage ist ganz einfach "ist das eine schlechte Idee"?

Verschiedene Quellen (einschließlich diesem RFC) legen nahe, dass jedes überlange UTF-8 als Fehler behandelt und abgelehnt werden sollte. Sie warnen vor "naiven Implementierungen" und geben mir den Eindruck, dass solche Dinge grundsätzlich unsicher sind.

Da der gesamte Zweck meines Moduls darin besteht, unordentliche Datendateien mit gemischten Codierungen zu bereinigen und in schönes, sauberes utf8 zu konvertieren, scheint es mir nur eine weitere Sache zu sein, die ich bereinigen kann, damit die Anwendungsebene nicht damit umgehen muss. Mein Code kümmert sich nicht um irgendwelche semantische Bedeutung, die die resultierenden Zeichen haben könnten, er konvertiert sie einfach in eine normalisierte Form.

Entgeht mir etwas? Gibt es eine verborgene Gefahr, die ich nicht in Betracht gezogen habe?

Answer 1

Ja, das ist eine schlechte Idee.

Vielleicht wurde bei einigen der Daten in einer dieser unordentlichen Datendateien überprüft, ob sie keine gefährliche Sequenz von ASCII-Zeichen enthalten.

Das kanonische Beispiel, das viele Probleme verursacht hat: '\xC0\xBCscript>'. 'Beheben' Sie die zu lange Sequenz auf einfaches ASCII < und Sie haben versehentlich ein Sicherheitsloch erstellt.

Kein Werkzeug hat jemals zu lange Sequenzen für einen legitimen Zweck generiert. Wenn Sie versuchen, gemischte Codierungsdateien zu reparieren, sollten Sie das Auftreten einer solchen Sequenz als Zeichen dafür betrachten, dass Sie die Codierung falsch eingeschätzt haben.

Answer 2

Ich denke nicht, dass dies aus Sicherheits- oder Benutzbarkeitsperspektive eine schlechte Idee ist.

Von Sicherheitsperspektive aus sollten Sie Benutzereingaben vor der Verwendung bereinigen. So können Sie Ihre Bereinigungsroutinen ausführen und dann sicherstellen, dass die Daten keine größer- oder kleiner-als-Symbole <> enthalten, bevor sie ausgegeben werden. Sie sollten auch sicherstellen, dass Sie mysql_real_escape_string() aufrufen, bevor Sie es in die Datenbank einfügen. Beachten Sie, dass Sprachcodierungsprobleme wie GBK vs. Latin1 zu SQL-Injektionen führen können, wenn Sie mysql_real_escape_string() nicht verwenden. (Dieser Funktionsname sollte unabhängig von den plattformspezifischen Bindungen Ihrer MySQL-Bibliothek ziemlich ähnlich sein)

Die Bereinigung aller Benutzereingaben ist im Allgemeinen eine schlechte Idee, weil Sie nicht wissen, wie die spezifische Variable verwendet wird. Zum Beispiel sind bei SQL-Injektionen und XSS sehr unterschiedliche Steuerzeichen beteiligt, und eine gleichartige Sensibilisierung für beide führt häufig zu Sicherheitslücken.

Answer 3

Ich weiß nicht, ob es in Ihrem Szenario eine schlechte Idee ist, da diese Art von Änderung nicht bijektiv ist und zu Datenverlust führen kann.

Wenn Sie die Codierung Ihrer Daten falsch erkannt haben, könnten Sie Daten fälschlicherweise als legitime UTF-8 Überlängen interpretieren und sie in die kürzeste Normalform ändern. Es wird keine Möglichkeit geben, die Originaldaten später wiederherzustellen.

Als persönliche Erfahrung weiß ich, dass wenn solche Dinge passieren können, sie WERDEN und Sie werden den Fehler möglicherweise nicht bemerken, bevor es zu spät ist...