nicht angemeldet
Hallo!
Ich kann mich nur wiederholen: Schau dir einmal größere Webframeworks an, die haben über diese Feinheiten schon vor Jahren nachgedacht und zum Teil sehr saubere Lösungen gefunden. Ein wichtiger Pfeiler ist das Model-View-Controller-Pattern ergänzt durch Model-Decorators, View-Models oder ähnliches. Die View ist meistens eine Datei in einer eigens für HTML geschaffenen, äußerst beschränkten Templating-Sprache, bei der automatisch escapet wird.
Letztlich will man nicht überall htmlentities() schreiben müssen. Ich bin da radikaler Ansicht: Wenn man eine HTML-Template-Sprache (z.B. direkt PHP) verwendet, die es erfordert, manuell Strings in den HTML-Kontext zu übertragen und zu entschärfen, dann macht man etwas falsch. Denn früher oder später vergisst man das Escapen oder escapet inkorrekt. Dann hat man mit hoher Wahrscheinlichkeit eine Sicherheitslücke. Für Webframeworks gilt »don’t make me think«. Basale Sicherheitsfeatures verhindern die schlimmsten Fehler. Man muss vom vorgegebenen Weg abweichen, um eine Sicherheitslücke durch XSS oder SQL Injection einzubauen.
ABER was ist, wenn der Benutzername max. 20 Zeichen lang sein soll, keine Sonderzeichen enthalten darf, nicht schon vergeben sein darf ... usw. ...! Da sollte ich mich doch in meiner Strukturdatei auch darauf verlassen, das meine Funktionen in der Codedatei dies ordnungsgemäß prüft
*Solche* Beschränkungen müssen auf jeden Fall im Code validiert werden. Oftmals ist das eine deklarative Regel im Model. Auf dem Model prüft man dann nur, ob es valide ist. Das Model gibt entsprechende Fehler zurück, die später dem Nutzer gezeigt werden können. Invalide Models kommen so gar nicht erst in die Datenbank.
Die View sollte letztlich möglichst dumm sein und nur fertige Daten ausgeben. Sie formatiert sie vielleicht noch, wenn dafür nicht schon ein Model-Decorator existiert. Das Templating-System beachtet den Kontextwechsel bestenfalls automatisch.
Grüße
Mathias
Gunnar Bittersmann