nicht angemeldet
Moin!
Escaping fehlt!
Das ist jetzt sicher ein Späßchen gewesen? Was - bitte - sollte denn rawurlencode(date('Y-m-d')) bringen?
Fast jede Webapplikation hat an irgendeiner Stelle das Problem, dass durch unsaubere Programmierung Möglichkeiten zu Code-Injection eingebaut wurden.
Die Herausforderung für die Programmierer ist also, solche Stellen möglichst einfach zu erkennen und zu beheben. Dies geschieht entweder manuell durch Anschauen des Codes oder tatsächlich automatisiert mit statischer Codeanalyse.
Egal welchen Weg man wählt, wird man am Ende bei einer Zeile wie deiner landen und sich fragen: Was zum Henker steht wohl in der Variablen, und wie kann ich das herausfinden? Und man wird dann eine Suche starten nach den Stellen, in denen die Variable bearbeitet und gefüllt wird. Und im Zweifel wird die Stelle der Datumserzeugung auch keine statischen Formate enthalten, sondern dynamisch aus der Datenbank den konfigurierten Userwunsch, oder sonst was.
Mit anderen Worten: Die Rückverfolgung, ob in einer Variablen überhaupt irgendwelche für den Kontextwechsel relevanten Zeichen stehen, oder ob die alle unverändert bleiben können, kann sich sehr aufwendig gestalten.
Die einfachste Art, sich in seiner Applikation gegen sowas abzusichern: Einfach Escaping machen - ohne Diskussion über den konkreten Sinn an der konkreten Stelle. Das korrekte Escaping für den Kontextwechsel ist dort nie falsch - als Sonderfall lässt es den String lediglich unverändert.
Die Tatsache, dass du ansonsten nur Performanceargumente dagegen anführst und direkt die arme Umwelt mit ins Boot holst, bestätigt die Schwäche deines Gegenarguments nur.
Es geht nicht um Performance, es geht um Sicherheit. Die Performanceeinbußen eines zusätzlichen Funktionsaufrufs und unveränderter Stringausgabe sind zwar meß- aber nicht wahrnehmbar. Die Sicherheitseinbußen bei späterer, ungeeigneter Codeänderung an ganz anderen Zeilen als der Redirect-Header-Ausgabe hingegen werden nicht nur wahrnehmbar sein, sondern auch ganz andere Kosten verursachen können.
Und nur darum geht es mir. Sicheres Programmieren kann man aufwendig betreiben, indem man bei jeder Variablenausgabe die Sinndiskussion des Escapings führt. Oder ganz schlicht und einfach erledigen, indem man einfach immer passendes Escaping betreibt, und sich dann niemals wieder daran erinnern muss, dass eine bestimmte Variable eben nicht alle Zeichen erlaubt, weil dahinter kein Escaping ist.
Da Software ja in der Regel über einen langen Zeitraum lebt und gepflegt werden will, ist dieser zweite Ansatz deutlich weniger aufwendig. Und es ist nie verkehrt, als Vorbild in einem Forum immer auch Sicherheitsaspekte mit in den Code einfließen zu lassen - Unwissende werden deinen Code nämlich ohne Berücksichtigung dieser Sonderaspekte einfach nur kopieren - besser, er ist in sich sicher, nicht nur zufällig.
- Sven Rautenberg