PHP Bereinigung der Daten vor/nach Speicherung in DB?

[Dsimon24]

Moin zusammen,

ich diskutiere gerade ein wenig mit einem Kollegen im Bereich DB-Sicherheit.
Er schlägt vor, nur die Ausgaben aus einer DB zu bereinigen, mittels Strip_Tags und HTMLSpecialChars.
Ich würde die Bereinigung aber schon auf dem Weg in die DB, quasi vor der Speicherung realisieren.
Möglicherweise auch auf dem Weg in der DB und bei Ausgabe aus der DB.

Was schlägt ihr vor, und warum?

VG, David

 

[Cool Master]

Man bereinigt BEVOR man speichert. Sobald alles bereinigt wurde muss bei der Ausgabe nichts mehr bereinigt werden.

 

[Jesterfox]

Eine Bereinigung um unerwünschte Bestandteile würde ich schon vorher machen, so das in der DB nur genau das steht was man auch haben möchte (wobei die Frage ist was wirklich unterwünscht ist und was man erlauben kann auch wenns nicht sinvoll erscheint)

Eine Umwandlung wie mit HTMLSpecialChars aber niemals in der DB speichern sondern immer erst hinterher machen. Warum? Was ist denn wenn der Text plötzlich mal nicht in HTML sondern irgend einem anderen Format ausgegeben werden soll? Dann hast du da plötzlich schon HTML-Syntax mit drin und dafür fehlen evtl. andere Umschreibungen die für das gewünschte Format notwendig wären.

 

[Yuuri]

Man validiert vorher und immer und lässt nur rein, was einem genehm ist. Natürlich muss man im Nachhinein auch für das Ziel encoden. Wenn man HTML ausgibt und keine XSS-Lücken haben will, brauch man entsprechend htmlentities() oder htmlspecialchars(). Gibt man bspw. in Text oder auch XML aus, kann man beruhigt CDATA-Tags verwenden und brauch den Klamauk nicht, da der Empfänger damit nix anfangen kann und es eben nur für HTML/Browser relevant ist.

 

[Madman1209]

Hi,

das kommt auch drauf an, was ihr unter "Bereinigen" versteht und welche Technologie genutzt wird für die Datenbankanbindung.

VG,
Mad

 

[BeBur]

Du willst doch keinen ruhenden Exploit in deiner DB dauerhaft abspeichern.
Eines Tages baut jemand anders eine unabhängige Komponente, Bereinigt die Ausgabe nicht -> Problem.
Außerdem willst du doch wissen, welche Daten du da drin hast, zwecks Querying und nicht ein wildes Gemisch aus Kram und Daten.
Außerdem bekommst du Probleme mit der Typsicherheit. Wie willst du einen float abspeichern, wenn du die Hälfte der Zeit "<p>34.5</p>" in die Datenbank schreibst?

 

[Jesterfox]

Eines Tages baut jemand anders eine unabhängige Komponente, Bereinigt die Ausgabe nicht -> Problem.

Und woher sollte man vorher wissen was für diese Komponente Problematisch ist? Wird da Plaint Text, XML, JSON, ein SQL Statement oder irgendwas ganz anderes exotisches zusammengebaut?

Nein, jede Komponente muss für sich selber sicherstellen das sie Daten validiert und in ihr Zielformat umkodiert.

Wobei das auch für die Datenbank gilt, deshalb auch da die Daten vorher validieren und dann in ein für die Datenbank sinnvolles Format bringen.

 

[BeBur]

Und woher sollte man vorher wissen was für diese Komponente Problematisch ist?

Das Szenario ging davon aus, dass nicht nur Daten, sondern Daten + Noise bzw. Daten + malicous Zeichenketten enthalten sind. Der nächste, der queries unabhängig von den beiden (bzw. deren Team) baut wird davon nicht ausgehen und fast garantiert kleine oder große Probleme produzieren.

 

[Jesterfox]

Der Punkt ist aber das "malicious" immer Kontextabhängig ist. Das kann man nicht im Vorfeld wissen.

Und wer bei der Verarbeitung von Daten nicht berücksichtigt dass dort gefährliche Zeichen drinnen sein können und sie nicht in den Zielkontext umkodiert sollte vielleicht nochmal das programmieren lernen.

 

[bog]

weiterer punkt: stell dir vor, du hast zwei (oder n) unabhaengige systeme, die an dieselbe datenbank angebunden sind, und musst deine bereinigung doppelt implementieren.

 

[BeBur]

Und wer bei der Verarbeitung von Daten nicht berücksichtigt dass dort gefährliche Zeichen drinnen sein können und sie nicht in den Zielkontext umkodiert sollte vielleicht nochmal das programmieren lernen.

Mag sein, aber 'der nächste wird gewiss ebenfalls aufpassen' ist keine besonders nachhaltige Philosophie .

 

[Jesterfox]

Aber die einzig mögliche... nehmen wir an wir speichern einen Text in der Datenbank. Wie soll da ein "Bereinigen" aussehen? Erst mal alle kleiner-Zeichen rauswerfen weil ja eine Ausgabe in HTML möglich sein soll? -> Text kaputt. Umkodieren? -> Volltextsuche kaputt, außerdem wird das ganze unbrauchbar für andere Zwecke, z.B. Plain Text Ausgabe in einer E-Mail (oder whatever). Zusätzlich enthält das ganze immer noch "gefährliche" Zeichen für andere Ausgaben, z.B. den Transport über JSON. -> es ist gar nicht möglich einen Text so abzuspeichern das er für alle Szenarien sicher ist! (wenn du sowohl eine JSON als auch eine HTML Kodierung drüber laufen lässt ist der Text schlussendlich nicht mehr in HTML ausgebbar, außer man muss jedes mal die JSON Kodierung erst rückgängig machen.) Außerdem... er weiß welche Kodierung als nächstes benötigt wird?

 

[Andreas_]

Es ist von Anwendung zu Anwendung verschieden. Deswegen kann man auch keine pauschalen Aussagen machen. Ich hatte schon die Anforderung, dass die Originaldaten unverändert erhalten bleiben sollten. Da kamen die so wie sie waren in einen Blob und ich habe mir rausgeparst, was ich für die verschiedenen Anwendungsfälle brauchte ...

 

[BeBur]

Malicous also bösartig ist unabhängig vom Kontext und Bereinigung bezeichnet das Trennen von Daten und Noise ist auch ziemlich klar und unabhängig vom Kontext des Auslesens. Das der TE im Beitrag nicht nur Bereinigung vorschlägt ist eine andere Geschichte.

 

[Yuuri]

Malicous also bösartig ist unabhängig vom Kontext

<script></script> ist nur in HTML "bösartig". Wenn ich das in ner lokalen Anwendung in ner DB vorliegen hab, passiert da genau gar nichts, weil da bspw. kein HTML-Parser genutzt wird und nicht mal ne JS-Engine einsatzbereit wäre. Ziehe ich die DB aber irgendwann als Quelle für ein Webfrontend in Betrachtung, hab ich plötzlich "Probleme". Aber genau genommen ist es kein Problem, denn ordentlich escaped, passiert im Browser da genau gar nichts, da der ausliefernde Server entsprechend agieren sollte. Wer das nicht tut, hat eben Pech und hat dann eine Lücke. Das ist nicht das Problem der Daten, sondern des Entwicklers, der (mal wieder?) geschlampt hat.

DELETE FROM ... ist auch nur in SQL "bösartig". Willst du mir jetzt meinen Usernamen verbieten? Oder nutzt du 2020 einfach mal Prepared Statements und hörst auf den Scheiß direkt in den Query per String Concat zu schreiben?

Natürlich ist das einzig und allein Kontextabhängig.

Wenn dies nicht so sein sollte, nenn mir doch mal ein Beispiel, der eine globale Gültigkeit besitzt? Nun bin ich gespannt...

 

[BeBur]

Streiten über Semantik . Vielleicht wird es klarer, wenn ich malicous stattdessen mit 'böswillig' oder 'in böser Absicht' übersetze.
Bösartige, also malicous Zeichenketten sind nicht auf einmal nicht mehr bösartig nur weil sie im aktuellen Kontext keinen Schaden anrichten können. Das mentale Modell dahinter ist schon recht problematisch.

Das ist nicht das Problem der Daten, sondern des Entwicklers, der (mal wieder?) geschlampt hat.

Das ist auch so eine problematische Einstellung die dann auch zu solchen Fragen wie beim TE führen kann. 'Nein ist ja alles kein Problem für uns und wenn der nächste nicht richtig aufpasst ist er selber Schuld weil schließlich ist seine Aufgabe auch X zu machen'. So entstehen größere Bugs.

Ist aber eh alles nur sekundär, da sowieso schon weitere gute Gründe genannt wurden, Daten zu bereinigen.

 

[ayngush]

Hallo,

Sinnvollerweise speichert man in der Datenbank keine Zielformatierungen etc. ab, da sich diese auch mal ändern können. Spricht: Irgendwelche HTML-Escape-Sequenzen oder HTML-Tags haben in einer Datenbank nichts zu suchen. Die Formatierung für das jeweilige Zielsystem ist Aufgabe des Zielsystems - speziell des Views im MVC-Kontext, und nicht der Datenbank.

Eingaben in die Datenbank müssen zwingend verifiziert und validiert werden.

Das Beispiel mit den SQL-Injections: Es ist halt quatsch! Natürlich könnte man "Little Bobby Tables" auch genau so eingeben (und abspeichern), wie vorgeschlagen: "Robert'); DROP TABLE Stundents;--", denn man arbeitet ja mit Servergebundenen Variablen bei der Eingabe und entsprechenden Escape-Sequenzen im Ausgabesystem.

Kurz: Es wird keine Zielformatierung bei der Dateneingabe vorgenommen, das Escapen von SQL-Inputs erledigt die DB-Middleware über die Servergebundenen Variablen, Escape-Sequenzen und Zielformatierungen werden während der Ausgabe vom Ausgabesystem durchgeführt. Alle Benutzereingaben sind vom Frontend und Backend auf ihren jeweiligen Scope zu verifizieren (richtigkeit = E-Mail auch wirklich eine brauchbare E-Mail? Geburtsdatum ist ein gültiges Datum in der Vergangenheit und nicht länger als 150 Jahre zurückliegend?) und validieren (gültigkeit, typ, (Integer = Integer, Strings nicht zu lang, usw.) usw.)

Noch kürzer: Ich kann hier ja auch schreiben <script>alert(1);</script> und jeder kann es lesen und niemand bekommt (hoffentlich) ein Modal mit einer 1 drinnen um die Ohren... und nein in der Datenbank ist garantiert nicht &lt;script&gt;alert(1);&lt;/script&gt; gespeichert: Woher ich das weiß? Nun, ich kann den Text ja in einen Textfeld bearbeiten...

 

[Jesterfox]

Bösartige, also malicous Zeichenketten sind nicht auf einmal nicht mehr bösartig nur weil sie im aktuellen Kontext keinen Schaden anrichten können. Das mentale Modell dahinter ist schon recht problematisch.

Ok, dann lös mir doch mal folgendes Problem: ein Text soll sowohl für HTML als auch für CSV "sicher" sein. Viel Spaß (1). Für die Umschreibung der Spitzen Klammern brauchst du &gt; aber das ist in CSV "Böswillig" weil der Strichpunkt der Delimiter ist. Ergebnis: ein Inhalt kann niemals für alle Ziel-Kontexte sicher sein.

Außerdem: sich drauf zu verlassen dass das Vorsystem alles richtig liefert ist absolut Bad Practice. Oder wie du es ausdrückst "Das mentale Modell dahinter ist schon recht problematisch." Immer selber absichern! Es könnte ja auch mal sein das ein Angreifer es schafft deine API direkt anzusprechen.

(1): für noch mehr Spaß soll der Text HTML-Beispiele enthalten die nicht nur wieder in HTML sondern auch als Plaintext oder in einem RTF ausgegeben werden müssen. Außerdem soll die Anwendung unterschiedliche Datenbanksysteme verwenden die alle andere String-Delimiter in der SQL Syntax verwenden.

Am Ende müsstest du alles rausschmeißen was kein alphanumerisches ASCII Zeichen ist, denn alles andere kann irgendwo "gefährlich" sein... aber wie gibt man damit einen HTML-Quelltext lesbar wieder?

 

[ayngush]

... und wenn genug > < + - . , [ ] Zeichen enthalten sind, kann ich es als Brainfuck lauffähig kompilieren.