Beim SPEICHERN von Eingaben sollte real_escape_string + typ-prüfung der werte (Zahlen, Buchstaben, evtl. Sonderzeichen bzw was man eben erwartet) genügen, um auf der DB-Ebene auf sicherer Seite zu sein?
Ja. Und sogar eins davon reicht meist - denn wenn du nur eine Zahl hast (auch Gleitkomma mit Exponent und pipapo), dann enthalten die keine für SQL speziellen Zeichen und müssen auch nicht escaped werden.
Beim Auslesen von Daten muss ich dann entscheiden, was angezeigt werden darf, d.h. z.b. strip_tags anwenden, oder eben htmlspecialchars etc.?
Ja. Soll das HTML als solches vom Browser interpretiert werden? Dann unverändert lassen. Soll das HTML als Code im Browser dargestellt werden (z.B. als Anleitung), dann htmlspecialchars (damit aus "<div>" dann richtigerweise "<div>" wird, damit es eben nicht als HTML selbst vom Browser interpretiert wird). Soll keins von beidem der Fall sein? Dann strip_tags() - wobei ich mir allerdings kein Szenario überlegen kann, in welchem man HTML-Tags mutwillig entfernen will - man ist doch besser aufgehoben, entsprechenden Text mit htmlspecialchars für HTML zu escapen.
Was ich z.B. aber nicht weiß: Muss ich tatsächlich real_escape_string über jeden Wert einzeln laufen lassen oder kann ich den ganzen SQL-String, wenn er fertig ist, escapen lassen?
Nicht verstanden. Escapen bedeutet, dass man alle speziellen Sachen für einen Bezug entsprechend entschärft, damit sie keine spezielle Funktion haben.
Unter SQL sind spezielle Zeichen z.B. das Semikolon - damit wird ein Kommando vom nächsten getrennt. Um dieses aber selbst als (nicht zu interpretierendes) Zeichen zu verwenden, kann man einen Backslash davorsetzen. Genauso das Hochkomma - das wird verwendet, um einen Text zu beginnen. Braucht man im Text selbst jedoch auch ein Hochkomma, dann kann man das ja nicht verwenden, weil man dadurch den Text als solches wieder abschließt. Aber mit einem Backslash vor dem Hochkomma wird das Hochkomma selbst als Textzeichen gewertet, statt als Textanfang oder -ende.
Unter HTML sind spezielle Zeichen z.B. das "kleiner als" (spitze Klammer auf) und das "größer als" (spitze Klammer zu) - damit wird ein Tag begonnen und wieder geschlossen. Will man aber diese Zeichen selbst in HTML darstellen, muss man eine Entität stattdessen verwenden. Eine Entität fängt immer mit einem Kaufmanns-Und an und endet mit einem Semikolon - z.B.
< für "kleiner als" und
> für "größer als". Und was passiert, wenn wir ein Kaufmanns-Und in HTML darstellen wollen? Können wir so blank ja nicht schreiben, weil das der Beginn für eine Entität darstellt. Kurz: auch dafür gibt es selbst eine Entität, nämlich & - damit wird in HTML ein
& dargestellt.
Hast du jetzt den Sinn von escapen verstanden? Und warum man es nicht global für alles machen kann/muss? Und warum es mehr als unsinnig wäre, ein komplettes SQL-Kommando zu escapen?
Und noch zu deinem Generalisierungsansatz: hier hab ich doch aber genauso viel wenn nicht noch mehr SChreibaufwand als wenn ich jeden Wert prüfe? ich müsste ja dann auch für jede Eingabemaske ein neues Array anlegen oder?
Nein - wenn du z.B. in drei deiner Eingabemasken dieselben Werte verwendest (wie z.B. "Alter" oder "Name"), dann kannst du jene Felder genauso nennen und brauchst sie entsprechend nur einmal definieren. Der Aufwand könnte für dich jetzt sogar höher aussehen. Bedenke jedoch, dass das eine weit saubere Implementierung ist. Sollte sich später mal etwas ändern (du erweiterst die Maximallänge beim Namen von 50 auf 150 Zeichen oder für eine Telefonnummer dürfen nun doch auch andere Zeichen eingegeben werden als nur Ziffern und Leerzeichen), dann gibt es lediglich eine Stelle, an der du etwas abändern musst. Bei deiner "Methode" musst du sämtliche betroffenen Stellen im Code finden und abändern. Und die Übersichtlichkeit wolltest du doch auch bedenken.
