Sicherheit: Warum geht das???

[*Alex*]

Hallo liebes Forum

Ich habe gerade ein Formular getestet, indem ich die Hacker-Zeile
<script>alert('CSS Vulnerable')</script>
als Eingabe eines böswilligen Users in einen input der Form
<INPUT TYPE="text" NAME="var">
eingegeben habe.

Das Formular wird mit einen PHP-Script abgearbeitet, welches den input wie folgt übernimmt:
$var= htmlentities(trim($_POST["var"]));

Wieso kann dieser Code trotzdem meine Seite zerschießen???

var hat doch jetzt den Wert
<script>alert('CSS Vulnerable')</script>
oder etwa nicht?

Anschließend an den Alert bekomme ich die Fehlermeldung:
Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in ...

Die Datenbank müsste doch auch nur o.a. Textstring abkriegen - wieso kann sie dann so reagieren?

Geschockt und ratlos

*Alex*

PS: Bei meiner eigenen Suche bin ich auf englischsprachige Seiten gestoßen, welche das Problem scheinbar behandeln - leider ist Englisch nicht so meine Sprache...

[Matze]

Hi Alex,

zwar hab ich bei deinem Problem keine Ahnung, jedoch kann ich dir bei der englischen seite evtl helfen, wie ist den die url?

vg, matze

[*Alex*]

Hi Matze

Danke für Dein Hilfsangebot!
Ich versuche gerade mit meinem Translator zu kapieren, was mir
http://www.technicalinfo.net/papers/CSS.html/ mir sagen könnte.
Da sind ewig Beispiele mit Hacker-Zeilen...

Aber nochmal meine Frage:
wieso entschärft htmlentities('fieseZeile'); nicht so etwas wie <script>alert('CSS Vulnerable')</script> ???

Ohne jeden Ansatzpunkt und für Erklärungen dankbar

*Alex*

[Sven Rautenberg]

Moin!

Ich habe gerade ein Formular getestet, indem ich die Hacker-Zeile
<script>alert('CSS Vulnerable')</script>
als Eingabe eines böswilligen Users in einen input der Form
<INPUT TYPE="text" NAME="var">
eingegeben habe.

Das ist im Grunde eine sehr gute Idee - und es zeigt sich ja in der Folge, dass du ein Problem in deinem Code hast.

Das Formular wird mit einen PHP-Script abgearbeitet, welches den input wie folgt übernimmt:
$var= htmlentities(trim($_POST["var"]));

htmlentities() ist für den HTML-Kontext gedacht: Wenn ein String, der möglicherweise Zeichen enthält, die in HTML Sonderbedeutung haben, in HTML eingebettet werden soll, müssen diese Sonderzeichen entschärft werden - das geht in HTML, indem sie in Entities gewandelt werden.

Allerdings macht htmlentities() mehr, als notwendig, weil es auch vollkommen ungefährliche Umlaute in Entities wandelt.

Es reicht aus, bei der Ausgabe in HTML htmlspecialchars() aufzurufen.

Wieso kann dieser Code trotzdem meine Seite zerschießen???

var hat doch jetzt den Wert
&lt;script&gt;alert('CSS Vulnerable')&lt;/script&gt;
oder etwa nicht?

Anschließend an den Alert bekomme ich die Fehlermeldung:
Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in ...

Du schreibst dein Formularfeld anscheinend in eine Datenbank. Zum Glück hast du in deinem Testcode einfache Anführungszeichen verwendet, die tatsächlich ungefiltert durchgegangen sind, deshalb hast du auch diesen Fehler gefunden.

Für die Einbettung von Strings mit möglicherweise bösen Inhalten in MySQL-Querys gilt dasselbe, wie für die Einbettung in HTML: Die bösen Zeichen müssen entschärft werden. Allerdings müssen hier andere Zeichen entschärft werden, als bei HTML. Deshalb gibts auch eine andere Funktion: mysql_real_escape_string().

- Sven Rautenberg

[*Alex*]

Hi Sven

Es reicht aus, bei der Ausgabe in HTML htmlspecialchars() aufzurufen.

Wieso kann dieser Code trotzdem meine Seite zerschießen???

var hat doch jetzt den Wert
&lt;script&gt;alert('CSS Vulnerable')&lt;/script&gt;
oder etwa nicht?

Anschließend an den Alert bekomme ich ...

Also htmlspecialchars() macht weniger als htmlentities() - Hm.
Dann _sichert_ es also nicht MEHR - Hm.
Dann hat meine Variable var nach der Anwendung von htmlspecialchars(var) also immernoch den Wert
&lt;script&gt;alert('CSS Vulnerable')&lt;/script&gt
und dann wird eine Seite geladen, die als allererstes für jedes gehackte Eingabefeld einen Alert ausführt. Hm.

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...

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

Hm
     *Alex*

[Der Martin]

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
&lt;script&gt;alert('CSS Vulnerable')&lt;/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

[*Alex*]

Hallo Martin

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.

Ich habe es offensichtlich noch nicht deutlich genug gesagt:
Es wird eben wohl das Script ausgeführt!!!

Leider kann ich den Fall heute nicht weiter bearbeiten. Werde den Quellcode wohl Stück für Stück in einer Testdatei aufbauen müssen und schauen, ab wann dieser Fehler auftritt.

Derzeit geschieht nach dem Abschicken des Formulars, dass _zuallererst_ bevor irgendetwas angezeigt wird (weiße Seite im Hintergrund), dass für jedes gehackte Feld ein Alert ausgegben wird und mit O.K. bestätigt werden muss.
Sind alle Alerts ausgeführt, wird die Seite geladen.

Dies geschieht offensichtlich unabhängig vom Abfragen der Variablen var.
Selbst, wenn das Formular var sendet, ohne dass das Script diese Variable jemals abfragt, geschieht was ich oben beschrieben habe!

O.K. ich mach mal für heute Schluß - vielleicht hat bis morgen jemand eine Erklärung - oder die Seite http://www.technicalinfo.net/papers/CSS.html begriffen...

Habt eine gute Zeit
       *Alex*

[EKKi]

Mahlzeit,

Derzeit geschieht nach dem Abschicken des Formulars, dass _zuallererst_ bevor irgendetwas angezeigt wird (weiße Seite im Hintergrund), dass für jedes gehackte Feld ein Alert ausgegben wird und mit O.K. bestätigt werden muss.
Sind alle Alerts ausgeführt, wird die Seite geladen.

Falsch. Die Seite wird ZUERST geladen, beim Parsen der Seite wird vom Browser dort, wo Javascript-Code steht, dieser ausgeführt und wenn der Browser mit Parsen fertig ist, wird die Seite gerendert und danach angezeigt.

Dies geschieht offensichtlich unabhängig vom Abfragen der Variablen var.

Eine Variable "var" gibt es - wenn ich Dein Ursprungsposting zugrunde lege - allenfalls in PHP. Das hat mit dem letztendlichen HTML-Output (mit oder ohne Javascript) nur dort etwas zu tun, wo der Inhalt dieser Variablen "var" ausgegeben wird.

Da Du uns aber bisher standhaft relevanten Code vorenthältst, kann ich Dir zur Zeit nur mein Posting als Verständnishilfe zur Behandlung von Variableninhalten in PHP empfehlen.

Selbst, wenn das Formular var sendet, ohne dass das Script diese Variable jemals abfragt, geschieht was ich oben beschrieben habe!

Das klingt absolut unglaubwürdig. Irgendwo MUSST Du den Inhalt von $_POST['var'] in irgendeiner Form ausgeben, ansonsten KANN der entsprechende Inhalt NIEMALS beim Browser ankommen.

Wenn Du wirklich Hilfe benötigst, zeige endlich relevanten Code! Alles andere ist nur Stochern im Nebel ...

O.K. ich mach mal für heute Schluß - vielleicht hat bis morgen jemand eine Erklärung

"Keine Arme - keine Kekse"

MfG,
EKKi

[*Alex*]

Hallo EKKi

Große Entschuldigung!
Du hast RECHT:

Irgendwo MUSST Du den Inhalt von $_POST['var'] in irgendeiner Form ausgeben, ansonsten KANN der entsprechende Inhalt NIEMALS beim Browser ankommen.

Wenn Du wirklich Hilfe benötigst, zeige endlich relevanten Code! Alles andere ist nur Stochern im Nebel ...

Ich habe den relevanten Code gefunden - bin bloß nicht drauf gekommen, weil es sich um eine Kontrollausgabe handelt, die ich nur während des Entwickelns benutze:

  
// Kontrollausgabe  
echo"<B>POST Variablen:</B><BR>";  
foreach ($_POST as $key => $value){  
 echo"$key => $value &nbsp;&nbsp;&nbsp;";  
}  

schäm

Trotzdem Danke.

*Alex*

[Thorsten]

Hi Alex!

// Kontrollausgabe
echo"<B>POST Variablen:</B><BR>";
foreach ($_POST as $key => $value){
echo"$key => $value &nbsp;&nbsp;&nbsp;";
}

  
LOL!  
  
Das war sie also, die berühmte Nadel im Heuhaufen...  
Sowas Passiert, sag ich mal.  
  
  
Viele Grüße  
Thorsten

[EKKi]

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

[*Alex*]

Hallo EKKi

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

(müde) Ich weiß nicht womit es zu tun hat, aber

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.

es passiert eben doch.

Habe eine Testseite gebaut, die einfach nur $_POST['var'] entgegennimmt, bei der passiert es nicht. Was weiß ich.

Wenn ich Du wäre, würde ich das selbe antworten - ich würde es nämlich einfach nicht glauben, dass sowas passieren kann. Der Autor von http://www.technicalinfo.net/papers/CSS.html beschreibt das Ganze, aber ich versteh's nicht.

Bitte sagt nicht, es würde nicht passieren - glaubt's mir doch einfach mal und wenn Ihr ne Ahnung habt, was da los ist: Bitte schreibt.

GLG *Alex*

[EKKi]

Mahlzeit,

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.

es passiert eben doch.

Dann machst Du mit $_POST['var'] mehr als Du behauptest zu tun. Per POST an ein Skript übergebene Parameter KÖNNEN nur im Browser des Benutzers ankommen, wenn das Skript die Inhalte in irgendeiner Form ausgibt.

Habe eine Testseite gebaut, die einfach nur $_POST['var'] entgegennimmt, bei der passiert es nicht. Was weiß ich.

Was meinst Du mit "entgegennimmt"? Du gibst den Inhalt der Variable nicht aus? Wenn ja: siehst Du - natürlich passiert dann nichts!

Bitte sagt nicht, es würde nicht passieren - glaubt's mir doch einfach mal und wenn Ihr ne Ahnung habt, was da los ist: Bitte schreibt.

Ich habe ehrlich gesagt absolut keine Lust zum Raten oder Glaskugel-befragen: zeig uns relevanten Code!

MfG,
EKKi