fiter_var() oder / und htmlspecialchars()

[MB]

moin,

braucht man zusätzlich noch zu filter_var() die Funktion htmlspecialchars() und htmlspecialchars_decode() für die Sicherheit, um mit der Datenbank gefahrlos arbeiten zu können?

lgmb

[Rolf B]

Hallo MB,

statt filter_var kannst Du übrigens auch filter_input verwenden, um direkt aus $_GET oder $_POST auslesen zu können.

Ansonsten - die verfügbaren Sanitize-Filter tun gewisse dokumentierte Dinge. htmlspecialchars tut andere Dinge. Diese Dinge sind dafür relevant, Daten aus HTML-Kontexten zu holen oder dorthin zu senden.

Für die DB brauchst Du ganz andere Dinge. Die Maskierungsregeln für SQL sind andere als für HTML. D.h. deine Frage zielt in die falsche Richtung. Entweder verwendest Du für den Einbau von Werten in SQL die escape_string-Methode von mysqli (wenn Du mysqli nutzt), oder die quote-Methode von PDO (wenn Du PDO nutzt) oder du verwendest prepared statements.

Rolf

[dedlfix]

Tach!

braucht man zusätzlich noch zu filter_var() die Funktion htmlspecialchars() und htmlspecialchars_decode() für die Sicherheit, um mit der Datenbank gefahrlos arbeiten zu können?

Beide Funktionen haben ganz andere Aufgabenbereiche. Und das Datenbank-Handling ist auch unabhängig davon.

Die Filter-Funktionen behandeln die Eingabe, htmlspecialchars() behandelt die Ausgabe, die in HTML eingefügt werden soll. Für SQL wiederum sind nochmal andere Syntaxregeln zu beachten. Es ist auch nicht in jedem Fall so, dass die Ausgabe direkt von der Eingabe kommt, und damit vom eventuell verwendeten Eingabefilter bearbeitet wurde. Die Ausgabe muss aber auch für die Daten korrekt sein, die aus anderen Quellen kommen. Ausgabe bezieht sich jedoch nicht nur auf HTML, auch das Einfügen in ein SQL-Statement ist eine Ausgabe.

Du kannst versuchen, am Eingang bereits die Daten für den Ausgang vorzubereiten, aber das ist eine ganz und gar nicht zu empfehlende Strategie. Unterschiedliche Ausgänge erfordern unterschiedliche Bearbeitungen der Daten. Zudem möchte man intern auch lieber mit Rohdaten arbeiten, ohne dass diese mit ausgabekontextspezifischen Zusatzzeichen angereichert sind. Besser ist es, die Daten am Eingang ins Rohformat zu bringen, falls das notwendig sein sollte. Filterung und andere Umwandlungen sollten nur aus fachlichen Gründen erfolgen. Eine vorgesehene Ausgabe spielt dabei keine Rolle. Wenn aber die Daten letztendlich zur Ausgabe gelangen, dann sind sie immer noch im Rohformat, und erst dann werden sie für den jeweiligen Ausgabekontext aufbereitet. Alles andere führt nur zu Kuddelmuddel mit irgendwelchen Umkodierungen, weil man doch ein anderes Format braucht, als man am Eingang vorbereitet hat, oder es führt zu Lücken, weil man irgendeinen Verarbeitungsweg nicht vollständig beachtet hat.

dedlfix.