Ich war bisher immer ein Verfechter der „jeglichen Input sofort encoden“-Schiene. Heißt: Bevor ich Benutzereingaben in der Datenbank abspeichere / eine Bestätigungsemail versende etc. werden die Daten encodet (htmlentities oder ähnliches). Nun bin ich auf diesen sehr interessanten Artikel gestoßen (inspiriert durch einen Post zur ungarischen Notation beim phphacker), der folgende Position vertritt:
For example maybe you want to store these user strings in a database somewhere, and it doesn’t make sense to have them stored HTML-encoded in the database, because they might have to go somewhere that is not an HTML page, like to a credit card processing application that will get confused if they are HTML-encoded. Most web applications are developed under the principle that all strings internally are not encoded until the very last moment before they are sent to an HTML page, and that’s probably the right architecture.
Macht irgendwie auch Sinn wenn man mal so drüber nachdenkt. Ich fühle mich aber wohler, wenn ich davon ausgehen kann, dass sämlicher Inhalt der Datenbank clean ist und ich ihn bedenkenlos ausgeben kann. Man kann natürlich auch vor jeglicher Ausgabe von Strings erst das Encoding vollziehen – aus oben genannten, nachvollziehbaren Gründen. Man sollte sich wohl – wie so oft – nur auf eine Art einigen.
Mein Name ist
Ich bevorzuge die Codierung direkt bei der Ausgabe, da man bei dieser Lösung die eingaben auch nachträglich besser verarbeiten kann, wenn man etwas mit den codierten Zeichen machen will.
Du hast dann auf die Weise halt potentiell unsichere Daten in der Datenbank und musst voll drauf setzen, dass beim Ausgeben jeder der Beteiligten Entwickler das weiss.
Du definierst Text mit html entities als „clean“ ? Ich würde das Gegenteil behaupten, und durch diese „Verunreinigung“ lässt sich eben auch nichts anderes mehr mit dem Inhalt anfangen als ihn als HTML auszugeben. Und das ist in der Praxis einfach nicht überall so. Wenn jeder beteiligte Entwickler das gängige Prinzip kennt, genau dort zu escapen/codieren wo es nötig ist ist das auch kein Problem in der Praxis.
Umgekehrt ist es für den Frontend-Entwickler eine Qual, immer nachschauen zu müssen ob vielleicht schon in der Datenbank HTML steht oder eben nicht, weil bestimmter Inhalt auch anderweitig benötigt wird.
„clean“ war hier im Sinne von „XSS-Safe“ gemeint. Hatte wie erwähnt andere Einsatzzwecke außer der Ausgabe der Daten auf einer Webseite bisher nicht auf der Rechnung. Aber macht schon durchaus Sinn.
Muss dem Fabian zustimmen. Klar kann man html-entities auch wieder zurück codieren – aber sauber ist es wohl nur in der Ursprungsform.
Gruß Xandi
Hm. Die Frage hab ich mir vor langer Zeit auch gestellt. Man muss sich denke ich vielmehr die Frage stellen, ob der Datenbankeintrag ein Datensatz ist, mit dem hauptsächlich gearbeitet werden muss (Userdaten für einen Shop, Arbeitszeiterfassung – was auch immer), oder ob es reiner Content ist, der grundsätzlich eher für die HTML-Ausgabe gedacht ist.
Grundsätzlich nutze ich an keiner Stelle htmlentities, außer an den stellen, wo definitiv kein HTML erlaubt ist.
Was allerdings Pseudocode wie BB-Codes betrifft, da parse ich _grundsätzlich_ und ausnahmslos vor dem Schreiben des Datensatzes den jeweiligen Text auf solche Codes und ersetze diesen mit entsprechenden HTML-Replacements. Wenn der jeweilige Text bearbeitet werden muss, übersetze ich lieber den HTML-Code zurück in den BB-Code, denn Texte werden weit seltener überarbeitet als ausgelesen – das gibt einen gewaltigen Performanceschub bei jedem Seitenaufruf, wo sonst erst der Pseudocode geparst werden müsste.
Es ist bei lastintensiven Seiten auch eine Frage der Rechenzeit. Wenn ich die Daten immer zur Ausgabe umwandele, habe ich je Ausgabe eine Umwandlung, wenn ich sie bei der Eingabe umwandele, nur eine einzige. Decoding fuer die Weiterverarbeitung bzw. das Editieren der Daten ist nun auch kein Hexenwerk.