PHP - aber sicher

[Sven Rautenberg]

Moin!

Das würde dann womöglich zwei Varianten erfordern, a la "sauber_html_.." und
"sauber_sql_..". Gleich für alle Variablen alle denkbaren Varianten
vorsorglich zu erzeugen wäre vielleicht doch etwas aufwändig, trotzdem kommt
mir eigentlich eine Stelle für solche Schritte übersichtlicher vor.

Zugegeben, sofern du oben im Skript aus $_POST[xy] eine Variable $sauber_html_xy machst, kannst du dieser dann natürlich auch in

  
echo $sauber_html_xy;  

ansehen, dass sie anscheinend behandelt wurde.

Aber Programmierung besteht ja nun nich nur aus Hauptprogramm, sondern hat auch Funktionen, denen Parameter übergeben werden. Manche Funktionen erzeugen dann auch Ausgaben, ins HTML oder ins SQL oder sonst wohin.

Das bedeutet: Du muß sowohl sicherstellen, dass du in jedem Fall die Variable $sauber_html_xy in deinen Funktionsparameter steckst, und nicht aus Versehen doch $_POST[xy], und du mußt innerhalb deiner Funktion natürlich die Namensbezeichnung beibehalten, um zu kennzeichnen, dass die Variable als sauber zu gelten hat.

  
function whatever($sauber_html_param) {...}  

Dann hast du aber wieder, oder eigentlich erst richtig, das Problem, dass du eine spezialisiert escapte Variable in der Funktion hast, die für keine andere Verwendung mehr nutzbar ist.

Mal angenommen, du schreibst dir ein Datenbank-Backend. Der Funktion zum Schreiben in die DB übergibst du vorgefertigt escapte Strings.

Und dann schreibst du noch ein Backend zur Speicherung in Flatfiles. Das kann mit dem DB-Escaping absolut nichts anfangen. Die zwei Backends sind also nicht austauschbar. Ganz schlechte Idee also. :)

Und noch eines ist relevant: Um mysql_real_escape_string() anwenden zu können, muß mindestens eine Datenbankverbindung _bestehen_, denn das Escaping orientiert sich an der für diese Verbindung vereinbarten Zeichencodierung. Es ist nun zwar nicht ungewöhnlich, dass ein Skript direkt zum Start die DB verbindet, aber so rein von einer vernünftigen Programmlogik her gesehen wäre es doch wahrscheinlicher, dass eher ein Singleton verwendet wird, so dass die DB-Verbindung erstmalig erst beim ersten db-relevanten Methodenaufruf hergestellt wird. Folglich kannst du vor diesem Zeitpunkt noch gar kein Escaping durchführen.

Abgesehen davon halte ich es für Speicherverschwendung, wenn man Daten mehr oder weniger sinnlos im Vorraus dupliziert, nur falls sie mal gebraucht werden könnten. Das führt nur zu Problemen bei der Verarbeitung, weil Änderungen an dem einen String natürlich auch im anderen String nachgeführt werden müßten.

Andere Umwandlungen etwa wegen UTF-8 oder Sonderzeichen für URIs usw.
sind wohl auch öfters nötig. Ob sich daraus auch folgern läßt, doch besser
alles dezentral nur nach Bedarf und dann ggf. mehrfach durchzuführen?

Aber sicher läßt sich sowas folgern. Im Vorraus weißt du, dass du eigentlich alle denkbaren Escaping-Varianten irgendwo mal gebrauchen könntest. Aber erst wenn wirklich eine gebraucht wird, hast du Gewißheit. Warum aber für alle Fälle Escaping vorproduzieren, wenn es sich "on-demand" durch Funktionsaufruf herstellen läßt?

- Sven Rautenberg