Warum Daten nicht bei der Speicherung bereinigen


Jan-Frederik Stieler

Monsterator
Moderator
Hallo,
ich lese überall das man htmlentities() und ähnliches immer bei der Ausgabe verwenden soll.
Warum nicht schon beim Datenschreiben?
Dann hätte ich die Daten doch schon bereinigt in der Datenspeicherung drinnen und muss bei der Ausgabe nicht immer dran denken.

Grüße
 

ComFreek

Mod | @comfreek
Moderator
Das hatte ich hier schon mal irgendwo länglich geschrieben, finde es aber gerade nicht.

Dann hätte ich die Daten doch schon bereinigt in der Datenspeicherung drinnen
Du weißt aber nie, was du mit den Daten noch machen willst. Du willst Daten bei der Speicherung immer im allgemeinst möglichen Format speichern. Was, wenn du die Daten statt direkt ins HTML auszugeben, mal als JSON ausgeben möchtest? Oder als CSV?
Ich würde soweit gehen und sagen, dass Speicherung von Daten in einer maskierten Form -- zumindest am Primärspeicherort zumindest; in spezialisierten Caches wäre es mitunter sinnvoll -- ein kaputtes Datenmodell aufweist.

Auch philosophisch macht es viel mehr Sinn bei der Ausgabe zu maskieren: das Problem ist in fast allen Fällen das naive Interpolieren von Kontext und Daten. Bei XSS ist der Kontext HTML und die Daten Nutzereingaben. Das Problem tritt immer dann auf, wenn die Zielsprache keine Unterscheidung dafür bieten kann. HTML kann es nicht, weil es sowieso eine wenig ausdrucksstarke Sprache ist. Hingegen SQL -- oder präziser gesagt: SQL Driver -- können es via Prepared Statements zumindest bedingt. Bei LIKE-Anfragen mit variablem Wildcard hast du dann dasselbe Problem wie vorher bei SQL Injections trotz Prepared Statements.

Maskieren hängt also immer von der Ausgabeart ab. Ausgabe zwischen HTML-Tags ist nicht dasselbe wie Ausgabe in einem HTML-Attribut. In Letzterem musst du selbst Quotes maskieren. Ausgabe in HTML4 ist nicht dieselbe Ausgabeart wie HTML5. Selbst SQL-Queries in UTF-8 sind nicht dieselbe Ausgabeart wie SQL-Queries in einer anderen Zeichenkodierung. Da gab es in der Vergangenheit durchaus Sicherheitslücken in SQL Drivern, weil die Maskierung das nicht miteinkalkuliert hat.

Um den Punkt von oben mit dem kaputten Datenmodell nochmal aufzugreifen: ich finde es deswegen kaputt, weil du die sehr spezifische Annahme machst, dass die Daten nur in HTML5, da nur zwischen Tags und dann noch in Kodierung X ausgegeben werden.

PS: Ich sollte irgendwann mal einen Blogpost darüber schreiben :)
 

Technipion

Erfahrenes Mitglied
Ich würde soweit gehen und sagen, dass Speicherung von Daten in einer maskierten Form -- zumindest am Primärspeicherort zumindest; in spezialisierten Caches wäre es mitunter sinnvoll -- ein kaputtes Datenmodell aufweist.
Jepp. Falls die Datenbank textbasiert ist, würde ich auch immer dazu tendieren alles grundsätzlich als UTF-8 zu kodieren. Aber es kommt immer auf den Anwendungsfall an, möchte ich z.B. GPS-Abdrücke speichern bieten sich auch andere Formate an.

Ein schönes Negativbeispiel für schlechtes Datenbankmanagement ist übrigens Amazon Prime Video. Da ich mir hin und wieder mal einen Film/Serie dort gönne, sind mir über die Jahre schon unzählige Fehler bei denen aufgefallen. Ich habe mal 5 min auf deren Seite gesucht und bin tatsächlich fündig geworden:


(Disclaimer: Das sind keine Werbelinks, und sie spiegeln weder meine persönliche Meinung noch meinen Filmgeschmack wieder. Es sind lediglich zwei statistische Treffer einer kurzen Zufallssuche.)

In den Beschreibungstexten tauchen plötzlich kyrillische Zeichen auf. Ich habe aber auch schon HTML Einträge "ä" und Newlines "\n" gesehen.
Aber natürlich kann man Amazon hier keine Vorwürfe machen. Es ist ja total nachvollziehbar, dass so ein kleiner Laden, der obendrein noch quasi nichts mit dem ganzen Cloud- und Datenbankgedöns zu tun hat, seine Datenbanken nicht konsistent kodiert hat.

PS: Ich sollte irgendwann mal einen Blogpost darüber schreiben
Das wäre nice! Gibt bestimmt einiges, bei dem selbst die Profis noch einen gewissen "Aha-Effekt" haben werden :)

Gruß Technipion
 

chrisbergr

Erfahrenes Mitglied
Abgesehen von den bereits erwähnten Punkten kann es immernoch sein, dass deine Skripte oder das verwendete CMS Sicherheitslücken aufweißt, über die auch auf anderem Weg Daten in die Datenbank geschrieben werden können. Ganz zu schweigen von möglichem direkten Zugriff auf die Datenbank.

Des weiteren können sich auch immer bei Serverumzügen via Export/Import fehler einschleichen.

ich lese überall das man htmlentities() und ähnliches immer bei der Ausgabe verwenden soll.
Warum nicht schon beim Datenschreiben?
Ich würde immer - und so macht es auch WordPress - die Bereinigung sowohl bei der Ausgabe als auch beim Schreiben verwenden.
 

Neue Beiträge