Der Martin: POST und UTF8 -> Sonderzeichen

Beitrag lesen

Hallo,

Ich glaube ich habe den Übeltäter gefunden:

anscheinend nicht ganz - aber zumindest den Codeblock, in dem er steckt.

Den der Filter soll eigentlich XSS unmöglich machen:

Okay - dann aber bitte richtig.

$data = trim(htmlentities(strip_tags($data)));

Was genau versprichst du dir hier von htmlentities()? - Diese Funktion ist dafür gedacht (aber dennoch nicht geeignet), Daten zu behandeln, wenn sie in den Kontext HTML gebracht werden. Für andere Zwecke ist diese Funktion völlig ungeeignet. Und selbst für die Aufbereitung für HTML ist htmlspecialchars() besser geeignet.
Übrigens ist strip_tags() auch nicht immer schlau, weil diese Funktion radikal alles löscht, was mit '<' beginnt und mit '>' endet. Das ist nicht immer erwünscht; hier wäre htmlspecialchars() günstiger. Das wandelt '<' in &lt; und '>> in &gt;, so dass diese Zeichen risikolos im HTML-Kontext wieder ausgegeben werden können und die Eingabedaten exakt erhalten bleiben.

Genau diese Funktion htmlentities() verstümmelt dir tatsächlich deine Eingaben. Denn sie behandelt jedes Byte als ein Zeichen und geht dabei von einer ISO-8859-x-Codierung aus. Aus zwei Bytes, die eigentlich *ein* UTF-8-Zeichen darstellen, macht die Funktion zwei HTML-Entities. Und das ist Murx.

$data = mysql_real_escape_string($data);

Okay, mysql_real_escape_string() ist die richtige Funktion, um Strings für den Kontext SQL zu maskieren. Der Ordnung halber sollte diese Maskierung aber erst an der Stelle erfolgen, an der der String auch an eine mysql*-Funktion übergeben wird, und nicht "auf Verdacht" irgendwo in der Verarbeitungskette.

Und nach dem Filter passiert das ÖÄÜ Problem.

Ja, und nicht nur das - du hast anstatt UTF-8-codierter Klartext-Zeichen sogar noch unnötig HTML-Entity-Referenzen im Quellcode stehen.

Ciao,
 Martin

--
Das einzige Problem beim Nichtstun: Man weiß nie, wann man damit fertig ist.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(