Auge: PHP: Variablen nehmen falsche Werte an

Beitrag lesen

Hallo

So gehört z. B. htmlspecialchars() nicht in den Dateneingang (E), sondern beim Kontextübergang in den Datenausgang (A) der guten alten EVA-Strategie.

Florence MAURICE empfiehlt in "PHP 7 und MySQL", Heidelberg 2019, etwaige missbräuchliche Eingaben möglichst früh abzufangen!

Entweder sie empfiehlt ein falsches Vorgehen, oder du gibst ihre Empfehlung stark verkürzt und sinnentstellt wieder. Das mag durchaus Folge einer Fehlinterpretation sein.

Grundsätzlich erst einmal: Missbräuchliche oder nicht ins Datenmodell passende Eingaben bei ihrem eintreffen abzufangen, ist richtig. An dieser Stelle eine Maskierung für einen ganz bestimmten Kontext einzufügen, ist jedoch falsch. Dies zumal dann, wenn dieser Kontext im gegenwärtigen Verarbeitungsschritt absolut keine Rolle spielt.

Halte dich an den Grundsatz „Alles zu seiner Zeit“.

Gehen wir mal das typische Werden einer zu speichernden Eingabe durch.

  1. Eingabe in einem HTML-Formular und absenden an ein serverseitiges Skript.
  2. Prüfung der Eingaben auf Plausibilität und Korrektheit (soweit möglich) in jenem Skript.
    • Texteingaben lassen sich grundsätzlich nur auf Plausibilität prüfen (zum Beispiel Mindest- und/oder Maximallänge der Eingabe), da jede Eingabe anders sein kann, als die zuvor getätigte.
    • Bei den Werten aus Checkboxen, Radiobutton-Gruppen und Select-Feldern sind die möglichen Werte bekannt. Die tatsächliche Eingabe kann also gegen eine bekannte Menge von Werten geprüft werden.
    • Auch Eingaben aus Zahlen-, E-Mail-, Datums- und ähnlichen Feldern können auf die Einhaltung bestimmter Regeln geprüft werden.
  3. Speichern der erfolgreich geprüften Eingaben (zum Beispiel) in einer Datenbank. Hier erfolgt die eine kontextgerechte Maskierung in dem Prozess von Eingabe, Aufbereitung und Speicherung, passend zur Datenbank (beispielsweise mit mysqli_real_escape_string für an eine MySQL-Datenbank zu übertragende Zeichenketten). Maskierungen für eine etwaige Ausgabe, zum Beispiel als Bestandteil eines HTML-Dokuments, erfolgen zu diesem Zeitpunkt explizit nicht.

Nun folgt eine Ausgabe als HTML-Dokument.

  1. Lies die auszugebenden Daten aus der Datenbank.
  2. Führe eventuell notwendige Bearbeitungen der Daten durch (zum Beispiel Rundung und Formatierung von Zahlen).
  3. Maskiere jetzt, bei der Generierung der Ausgabe als letztem Schritt des Prozesses, die Daten passend zum Kontext HTML (in PHP mit htmlspecialchars).

Warum erfolgt die Maskierung erst vor der Ausgabe? Weil die Daten eventuell vor der Ausgabe noch umformatiert oder anderweitig bearbeitet werden sollen und weil man das mit Rohdaten machen will und nicht mit bereits für HTML aufbereiteten Daten.

Warum will man in der Datenbank die Rohdaten aufheben und nicht die, die bereits für eine HTML-Ausgabe aufbereitet sind? Weil man die Daten eventuell auch in anderen Kontexten ausgeben will, wo die Aufbereitung für HTML bestenfalls unnütz und schlimmstenfalls falsch ist. Für die Ausgabe von Text in einer Nur-Text-E-Mail ist die HTML-Maskierung falsch. Für eine Ausgabe mehrerer Datensätze als CSV-Datei ist die HTML-Maskierung falsch. Für eine Ausgabe als PDF-Dokument ist die HTML-Maskierung falsch. Für eine Ausgabe von Daten auf Papier ist die HTML-Maskierung falsch, außer, es wird ein HTML-Dokument als Basis des Ausdrucks benutzt.

In all diesen Fällen will man die Rohdaten haben und nicht aus für eine HTML-Ausgabe maskierten Daten eben diese HTML-Maskierungen herausprökeln.

Tschö, Auge

--
Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
Hohle Köpfe von Terry Pratchett