nicht angemeldet
Moin!
Hallo Sven,
nix gegen Korrekturen Herr Lehrer, nur stimmen muessten sie dann schon.
Sieht sonst sehr bloed aus ...
- mit serialize()
Das ist korrekt.
wie gnaedig ... ;-)
- und mit addslashes()
Absolut falsch.
aha,
und was glaubst Du passiert mit diesem Feld:
<input type="hidden" name="A" value="Sven glaubt ohne "addslashes" auszukommen">
Ein Slash ist NICHT das HTML-Escaping-Zeichen. Wenn du da addslashes() benutzt, kommt raus:
<input type="hidden" name="A" value="Sven glaubt ohne /"addslashes/" auszukommen">
Damit ist dir nicht geholfen.
Mit htmlspecialchars() kommt raus:
<input type="hidden" name="A" value="Sven glaubt ohne "addslashes" auszukommen">
Und das ist korrektes HTML.
- abschliessend mit urlencodet() oder base64_encodet()
Vollkommen unnötig.
Schlaumeier,
lies doch mal in den RFC's nach, welche Zeichen bei der Datenuebertragung zulaessig sind.
Die Datenübertragung interessiert zum Zeitpunkt der Erstellung eines versteckten Formularfeldes absolut überhaupt nicht. Das erledigt der Browser dann, wenn das Formular wieder abgeschickt wird - andernfalls kommt es nämlich zu unschöner Doppelcodierung, die man dann serverseitig wieder rückgängig machen müßte.
Was vorher oder nachher PHP damit anstellt, ist dem http-Protokoll echt schnuppe!
Was fehlt: htmlspecialchars().
aha,
wenn Du meinst, ich habe es noch nie gebraucht ...
aber es schadet sicher auch nicht, ausser bei der Performace.
Man kann sich natürlich auch anderweitig mit urlencode() und urldecode() was zusammenfummeln. Das funktioniert aber nur deshalb "zufällig" mit versteckten Inputfeldern, weil das Resultat von urlencode() keine Zeichen produziert, die in HTML Sonderbedeutung haben.
Also hast du Glück gehabt - aber nur, weil du zufällig nicht in die Falle getappt bist.
Aber wenn du bislang von htmlspecialchars() noch nie was gehört hast, hast du mit Sicherheit Scripte produziert, die für Cross-Site-Scripting anfällig sind. Keine schöne Sache, das...
- Sven Rautenberg
"Love your nation - respect the others."