Nö. Ein String wird immer nur fürs Ziel vorbehandelt. Für daten die in die Datenbank sollen -> real_escape, oder besser noch gleich PDO nehmen und Prepared-Statements nehmen

Für Daten die auf einer HTML-Seite ausgegeben werden htmlspecialchars

ist dabei nicht aber die gefahr größer, dass man irgendwo z.b. htmlspecialchars vergisst als wenn man es einfach gleich zu beginn reinpackt?
z.b. wenn ich in die DB schreibe und real_escape($_POST['usereingabe']) nutze kann es doch sein, dass ich später irgendwann mal die DB auslese und dann ausgeben möchte. da könnte ich ja schon vergessen haben, dass das was nun in der DB steht irgendwann mal von nem user stammte und ganz ausversehen einfach nur echo $variable_aus_datenbank schreiben.

gibt es denn gefahren oder probleme wenn ich eine usereingabe direkt nach dem empfang behandle?

EDIT: ein problem ist mir gerade dabei schon begegnet: strlen gibt natürlich eine andere länge für htmlspecialchars-behandelte strings aus als beim originalstring. der user könnte sich natürlich wundern, wenn er ne fehlermeldung bekommt, dass sein name zu lang ist obwohl er sich doch an die begrenzung gehalten hat

Da ist man dann als Programmierer selbst schuld. Aber wenn du dir unsicher bist, hau den input halt durch nen duzend Escaping und filterfunktionen, wird schon gut gehn

strlen() ist sowieso ungeeignet um die Länge eines Strings (in Zeichen) zu bekommen, da zeichensatzbabhängig. Kannst ja mal probieren wie lange der Username "Erklärbär" ist.*

Zu dem "alles gleich bei der Eingabe machen", hier mal eine kleine Analogie: Das ist in etwa so wie im Sommer die Winterjacke anziehen. VERMUTLICH wirst du sie irgendwann brauchen. Im Moment brauchst du sie aber nicht. Und wenn du nach Thailand ziehst wirst du sie niemals brauchen. Dort hast du dann Probleme damit. Warum also nicht einfach warten bis es kalt wird?

* Nachtrag: Tatsächlich ist die Länge abhängig davon mit welchem Zeichensatz du dein PHP-Dokument sicherst. Wenn es UTF-8 ist, belegt die 2 "ä" jeweils 2 Bytes, strlen() liefert also 11. Falls du einen Zeichensatz benutzt bei dem "ä" nur ein Byte benötigt wirst du 9 erhalten. Siehe: http://www.php.net/manual/en/languag...string.details

Gefahren: Hm, eigentlich nicht, aber wer weiß, was du mit den Daten anstellst. Für den Eintrag in die DB ist halt nur wichtig, dass dieser Kontextwechsel korrekt behandelt wird. Soll heißen: Wenn du eine entsprechende DB-Escape-Funktion zuletzt und korrekt anwendest, ist das an der Stelle cool.

Wenn du als vorletzte Funktion die passende (!) HTML-Escape-Funktion korrekt anwendest und wenn die Charsets übereinstimmen und so, sollte es auch bei Ausgabe im passenden HTML-Kontext keine Probleme geben.

Probleme: Ja, gibt es. Siehe etwa die vielen Relativierung im vorherigen Absatz. Wenn du dein HTML als UTF-8 ausgibst, müssen die Daten entsprechend für UTF-8 escapet abgelegt werden. Wenn du das Ausgabe-Charset nachträglich ändern willst (okay, nicht realistisch), musst du erstmal rückkonvertieren (UTF-8-Escaping rückgängig machen) und dann noch mal korrekt konvertieren. Wenn du zwei verschiedene Ausgabe-Escapings auf Basis derselben Daten nutzen willst (warum auch immer), musst du rückkonvertieren und korrekt konvertieren. Wenn die Daten nicht auf eine HTML-Seite sollen, sondern in ein PDF, ein LaTeX-Dokument, ein Office-Dokument, eine Grafik, eine Textdatei, … musst du rückkonvertieren und korrekt konvertieren. Wenn du nicht UTF-8 nutzt (warum auch immer) und eine Datenbanksuche nach Wörtern/Buchstaben machen willst, die teilweise in Entities umgewandelt wurden, musst du rückkon– nein, dann hast du einfach ein Problem.

Wenn die Datenbankfelder meinetwegen 255 Zeichen fassen sollten, werden sie keine 255 Zeichen fassen, sobald die Eingabe wenigstens <, >, &, " und vermutlich ' enthält (denn das wird zu Entities und dadurch länger).[1]

Wenn du die effektive Zeichenlänge einer Eingabe ermitteln willst, musst du auch umkonvertieren.

Kurzum: Wenn du mit den Daten etwas tun willst, was nicht „Ausgabe in HTML ist“, wird es mitunter zumindest mal semi-problematisch.

Was tkausl sagt, stimmt aber schon:

Das kann schon gut gehen, wenn du wirklich nur diesen einen Anwendungsfall hast, aber zu empfehlen ist das eben nicht, weil du dich da jedweder Flexibilität beraubst.

Das Schema F ist es, für den entsprechenden Ausgabekontext (SQL, HTML, PDF, …) zu escapen/konvertieren, sobald die jeweilige Ausgabe generiert wird.

Wenn du etwa eine Template Engine wie Twig nutzt, escapet die übrigens die zugewiesenen Werte selbstständig und du musst es explizit angeben, wenn du das nicht haben willst. Das wäre vielleicht interessant.



1: So was in der Art führt ohnehin manchmal zu lustigen Effekten.