Hallo,

Es reicht aus, bei der Ausgabe in HTML htmlspecialchars() aufzurufen.
Also htmlspecialchars() macht weniger als htmlentities() - Hm.

ja, es macht weniger Unsinn.
Gut, für dein konkretes Beispiel wirken beide Funktionen exakt gleich.

Dann hat meine Variable var nach der Anwendung von htmlspecialchars(var) also immernoch den Wert
<script>alert('CSS Vulnerable')</script&gt

Richtig.

und dann wird eine Seite geladen, die als allererstes für jedes gehackte Eingabefeld einen Alert ausführt. Hm.

Falsch. Es zeigt den Text "<script>alert('CSS Vulnerable')</script>" an der Stelle an, an der der Feldinhalt ausgegeben wird, führt aber kein Script aus. Da ist ja nirgends ein script-Tag, sondern nur ein maskiertes Kleiner-Zeichen, das Wörtchen "script" und ein ebenso korrekt maskiertes Größer-Zeichen.

Mal abgesehen von der Sicherung der Datenbank - immernoch meine Frage: Wieso geht das überhaupt?
Denn wenn ich
&lt;script&gt;alert('CSS Vulnerable')&lt;/script&gt;
in das Eingabefeld eingebe passiert ja auch nichts...

Doch, dann müsste an derselben Stelle der String "&lt;script&gt;alert('CSS Vulnerable')&lt;/script&gt;" angezeigt werden.

Es ist allerdings schwer, das alles zu überblicken, solange du uns nicht ein wenig an deinem Quellcode teilhaben lässt.

$_POST['var'] macht ja offensichtlich komische Dinge mit dem Script bevor es überhaupt abgefragt (und dabei entschärft) wird...

Nö. Es reicht die Parameter nur durch - es sei denn, dein Hoster hätte so dämliche PHP-Optionen wie magic_quotes aktiviert - dann werden Anführungszeichen innerhalb der Parameter mit einem Backslash maskiert.

So long,
 Martin

Mahlzeit,

vorausgeschickt: ich habe das Gefühl, Du hast überhaupt nicht verstanden, was Sven erklärt hat.

Dann _sichert_ es also nicht MEHR - Hm.

Weder htmlentities() noch htmlspecialchars() sind zur "Sicherung" von irgendwas da. Die Funktionen sind dazu da, einen String wie z.B. "<b>blablubb</b>" genau so von einem Browser anzeigen zu lassen - indem evtl. vorhandene HTML-Sonderzeichen entsprechend maskiert werden. Sie sind insbesondere NICHT dazu da, Eingaben, die in irgendwelche Formulare gemacht wurden und die dann per GET oder POST an ein PHP-Skript weitergereicht wurden, vor der Verarbeitung oder dem Schreiben in eine Datenbank zu verunstalten.

Wenn ein Benutzer in ein Eingabefeld namens "var" unbedingt "<script>alert('CSS Vulnerable')</script>" eingeben will, lass ihn doch!

Das einzige, was Du tun musst (und IMMER tun solltest!) ist den Inhalt von $_POST['var'] (also den String "<script>alert('CSS Vulnerable')</script>") genau DANN zu behandeln, wenn Du diesen z.B.

• in eine Datenbank einfügen willst: mysql_real_escape_string($_POST['var']) ... Ergebnis: "<script>alert('CSS Vulnerable')</script>"

• als HTML ausgeben willst: htmlspecialchars($_POST['var']) ... Ergebnis: "&lt;script&gt;alert('CSS Vulnerable')&lt;/script&gt;"

Dann kann sowas

und dann wird eine Seite geladen, die als allererstes für jedes gehackte Eingabefeld einen Alert ausführt. Hm.

nämlich NIEMALS passieren.

Mal abgesehen von der Sicherung der Datenbank

Nochmals: zur "Sicherung der Datenbank" solltest Du ausschließlich die Funktion mysql_real_escape_string() verwenden - weder htmlspecialchars() noch htmlentities() haben in diesem Zusammenhang IRGENDWAS im Code verloren.

&lt;script&gt;alert('CSS Vulnerable')&lt;/script&gt;
in das Eingabefeld eingebe passiert ja auch nichts...

Es sollte egal sein, was Du (oder irgendjemand sonst) in das Eingabefeld eingibt - mit vernünftiger, kontextbezogender String-Behandlung sollte NIEMALS etwas passieren.

$_POST['var'] macht ja offensichtlich komische Dinge mit dem Script bevor es überhaupt abgefragt (und dabei entschärft) wird...

Wie der Martin schon schrieb: normalerweise "macht" $_POST[] nix - außer Dir die per POST übergebenen Parameter zur Verfügung zu stellen. Zumindest, wenn in der php.ini oder httpd.conf keine merkartigen Einstellungen vorgenommen wurden ...

MfG,
EKKi