htmlentities() zerfetz die Umlaute

[bleicher]

Tagchen,
kleines Problemchen - zwecks sicherheit wird der Gästebucheintrag in meiner HP mit htmlentities() entschärft. Nur bekomme ich zugleich Hyeroglyphen anstelle der Umlaute (ö.üä,ß etc)
Lässt sich da was gegen machen oder muss ich auf htmlentites() verzichten und die EInträge anders entschärfen? (Wäre str_replace() für < > " ausreichender Schutz?)

thx in advance
MFG
bleicher

[Auge]

Hallo

kleines Problemchen - zwecks sicherheit wird der Gästebucheintrag in meiner HP mit htmlentities() entschärft. Nur bekomme ich zugleich Hyeroglyphen anstelle der Umlaute (ö.üä,ß etc)

Tja, das liegt - meiner Vermutung nach - daran, dass du offensichtlich schon beim Abspeichern der Einträge die Umlaute durch ihre HTML-Entities ersetzt. Vermute ich richtig?

Wenn ja, unterlasse dies und speichere die Einträge (sozusagen) roh. Erst bei der Ausgabe lässt du htmlentities über den Text laufen. Ansonsten werden die Umlaute doppelt maskiert.

Schema: Code -> Umwandlung(Ansicht des Quelltextes) -> Umwandlung(Ansicht im Browser)

beim Speichern: ä -> &auml; -> ä
beim Ausgeben: &auml; -> &amp;auml; -> &auml;

Tschö, Auge

[bleicher]

Wenn ja, unterlasse dies und speichere die Einträge (sozusagen) roh.

damit die Gäste schöne, bunte, SQLinsertions rienpressen? Evtl den Password für die CMS öffentlich machen? :(

MFG
bleicher

[Sven Rautenberg]

Moin!

Wenn ja, unterlasse dies und speichere die Einträge (sozusagen) roh.

damit die Gäste schöne, bunte, SQLinsertions rienpressen? Evtl den Password für die CMS öffentlich machen? :(

Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.

Escape immer kontextabhängig: in SQL anders als in HTML.

- Sven Rautenberg

[bleicher]

Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.

die löst bei mir seltsame Ergäbniße aus.. darf man eigtl auf dei verzichten und sich auf htmlenitites beschränken? oder sollte man sicherheitshalber noch beide einsetzen? JS-einschübe brauche ich ja auch nicht unbedingt :=)

MFG
bleicher

[Sven Rautenberg]

Moin!

Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.

die löst bei mir seltsame Ergäbniße aus.. darf man eigtl auf dei verzichten und sich auf htmlenitites beschränken? oder sollte man sicherheitshalber noch beide einsetzen? JS-einschübe brauche ich ja auch nicht unbedingt :=)

Die Reihenfolge ist eigentlich ganz einfach:

Rohtext kommt aus der Textarea.
-> mysql_real_escape_string()
 -> schreiben in die Datenbank.

Rohtext kommt aus der Datenbank.
-> htmlspecialchars()
 -> schreiben auf die HTML-Seite, z.B. auch in eine Textarea.

Auf diese Weise kommt immer genau das dort an, wo man es brauchen kann.

- Sven Rautenberg

[Auge]

Hallo

Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.

die löst bei mir seltsame Ergäbniße aus..

... die sich wie zeigen?

darf man eigtl auf dei verzichten und sich auf htmlenitites beschränken?

Nein, Sven schrieb nicht umsonst ausdrücklich "kontextabhängig". mysql_real_escape_string, wenn es um MySQL geht, htmlentities, wenn es um HTML geht.

oder sollte man sicherheitshalber noch beide einsetzen?

Beim speichern geht es um MySQL, also benutzte mysql_real_escape_string um die zu speichernden Strings von für MySQL schädlichen Zeichen zu befreien.

Bei der Ausgabe werden diese Maskierungen von MySQL selbsttätig entfernt. Dafür wird, wegen der Ausgabe in einer HTML-Seite, die Maskierung der in diesem Zusammenhang gefährlichen Zeichen wichtig. Und die entfernt/maskiert man mit htmlentities.

Alle Klarheiten beseitigt? :-)

Tschö, Auge

[dedlfix]

echo $begrüßung;

Beim speichern geht es um MySQL, also benutzte mysql_real_escape_string um die zu speichernden Strings von für MySQL schädlichen Zeichen zu befreien.

Diese Funktion entfernt keine 'schädlichen' Zeichen. Es gibt im Kontext eines SQL-Statements bestimmte Zeichen mit einer Sonderbedeutung. Damit man solche Zeichen auch als Datenbestandteil verwenden kann, müssen sie entsprechend präpariert werden. Einigen wird ein Backslash vorangestellt (", ' und ), andere werden in einer Ersatzdarstellung notiert (z.B. \r und \n).

Bei der Ausgabe werden diese Maskierungen von MySQL selbsttätig entfernt.

Sie werden schon beim Parsen des SQL-Statements von MySQL dekodiert, denn sie sind nur dazu da, den Transport innerhalb des Textes des SQL-Statments zu überstehen. In der Datenbank landen sie in - sagen wir mal - reiner Form. (Wie genau das abgelegt wird ist MySQLs Angelegenheit.)

Das Abfrageergebnis eines Statements kommt auf anderem Weg aus der Datenbank. Für diesen Weg (Kontext) sind keine Maskierungen erforderlich. Hier werden die Zeichen in ihrer ursprünglich gemeinten Form übertragen.

Dafür wird, wegen der Ausgabe in einer HTML-Seite, die Maskierung der in diesem Zusammenhang gefährlichen Zeichen wichtig.

Von "gefährlichen" oder "schädlichen" Zeichen zu sprechen ist nicht richtig, denn diese Eigenschaften haben diese Zeichen nicht. Sie haben einfach nur eine Sonderbedeutung in einem bestimmten Kontext. Wenn sie diese Sonderbedeutung nicht mehr haben sollen, müssen sie entsprechen den Vorschriften des Kontextes behandelt werden.

Und die entfernt/maskiert man mit htmlentities.

htmlentities() behandelt viel mehr Zeichen als für HTML notwendig ist. htmlspecialchars() ist im Prinzip ausreichend.

echo "$verabschiedung $name";

[Auge]

Hallo

Beim speichern geht es um MySQL, also benutzte mysql_real_escape_string um die zu speichernden Strings von für MySQL schädlichen Zeichen zu befreien.

Diese Funktion entfernt keine 'schädlichen' Zeichen.

Nein, sie maskiert sie und sie sind nicht schädlich, sondern aufgrund ihrer Sonderbedeutung zu maskieren (wie du schon schriebst), damit mit ihnen kein Code in das Statement eingeschleust werden kann. Entschuldigung für die unkonkrete Ausdrucksweise.

Bei der Ausgabe werden diese Maskierungen von MySQL selbsttätig entfernt.

Sie werden schon beim Parsen des SQL-Statements von MySQL dekodiert, denn sie sind nur dazu da, den Transport innerhalb des Textes des SQL-Statments zu überstehen. In der Datenbank landen sie in - sagen wir mal - reiner Form.

Aha.

Von "gefährlichen" oder "schädlichen" Zeichen [im HTML-Kontext] zu sprechen ist nicht richtig, denn diese Eigenschaften haben diese Zeichen nicht. Sie haben einfach nur eine Sonderbedeutung in einem bestimmten Kontext.

Als Zeichen ansich sind sie natürlich nicht schädlich, sie hätten aber eventuell eine schädliche Wirkung, wenn sie dem Zweck dienten, z.B. JavaScript-Code in einen Gästebucheintrag einzubetten. Und um dies zu verhindern, werden sie halt maskiert. Da man in diesem Zusammenhang oft von "unschädlich machen" spricht, lag der Begriff vom "schädlichen" Zeichen - zumindest für mich - nicht fern.

Auge

[Johannes Zeller]

Hallo bleicher,

Das kann ja nicht passieren, weil du da ja mysql_real_escape_string() benutzt, um in die Datenbank zu schreiben.

die löst bei mir seltsame Ergäbniße aus.. darf man eigtl auf dei verzichten und sich auf htmlenitites beschränken?

Dürfen schon, zu empfehlen ist das aber keinesfalls, da htmlentities ja nicht unbedingt dafür sorgt, dass nicht irgendwelche unbeabsichtigen MySQL-Befehle ausgeführt werden.

Schöne Grüße,

Johannes

[Sven Rautenberg]

Moin!

kleines Problemchen - zwecks sicherheit wird der Gästebucheintrag in meiner HP mit htmlentities() entschärft. Nur bekomme ich zugleich Hyeroglyphen anstelle der Umlaute (ö.üä,ß etc)

Welche Codierung benutzt du? UTF-8?

Lässt sich da was gegen machen oder muss ich auf htmlentites() verzichten und die EInträge anders entschärfen? (Wäre str_replace() für < > " ausreichender Schutz?)

htmlspecialchars() ist vollkommen ausreichend in 99,999% der Fälle.

- Sven Rautenberg

[bleicher]

Moin!

hi

Welche Codierung benutzt du? UTF-8?

ja - sonst werden kyrillische zeichen zu "???" konvertiert ;(

htmlspecialchars() ist vollkommen ausreichend in 99,999% der Fälle.

thx
was ist mit 0,00001%^^?  oder ist es der prozent der gleich mit dem hostserver gehackt wird?

MFG
bleicher

[Maxx]

Hallo,

... mit htmlentities() entschärft. Nur bekomme ich zugleich Hyeroglyphen anstelle der Umlaute (ö.üä,ß etc)

welchen Zeichensatz (charset, der dritte Parameter) verwendet htmlentities() und welchen der Browser zur Anzeige?
Suchst du nicht eigentlich htmlspecialchars()?

Grüße,

Jochen

[bleicher]

welchen Zeichensatz (charset, der dritte Parameter) verwendet htmlentities() und welchen der Browser zur Anzeige?

Browser bekommt UTF-8 header.. 3er parameter? k ich lese mal im handbuch nach.

MFG
bleicher

[bleicher]

Danke, das war die Lösung^^

'UTF-8'als charset ;)

MFG
bleicher