Schützt htmlspecialchairs vor SQL Injections?

[Thomas H.]

Hi!

htmlspecialchairs schützt ausreichend vor SQL Injections & XSS, oder irre ich mich da?

Danke!

[MatMel]

Eigentlich sollte es schon ausreichend schützen.
Aber du kannst ja trotzdem noch Sachen dazumachen, wie zum Beispiel ein Check mit is_numeric, wenn der Wert immer eine Zahl ist.
Oder das checken auf bestimmte Werte, wenn die Variable nur aus eine bestimmte Menge Werte annehmen kann.
Und halt auf jedenfall register_globals ausmachen und alle Variablen mit Startwerten belegen (also alle Notices wegbekommen).

Edit: Ich hab grade htmlentities() mit mysql_real_escape_string() verwechselt. Ersteres bringt bei SQL Injection recht wenig, sondern hilft nur dabei zu vermeiden, dass ein Benutzer eigenen HTML Code auf die Seite einschleust. Also gegen SQL Injection mysql_real_escape_string() (http://de3.php.net/manual/de/function.mysql-real-escape-string.php) verwenden. htmlentities() selbstverständlich nach Bedarf auch noch ...

[meikel (†)]

htmlspecialchairs schützt ausreichend vor SQL Injections & XSS, oder irre ich mich da?
Ja.

Gegen SQL Injektionen hilft das:
http://de2.php.net/mysql_real_escape_string

XSS:
siehe http://de.wikipedia.org/wiki/XSS
Besser ist es daher, die „guten“ Eingaben exakt zu definieren (Weiße Liste) und nur solche Eingaben zuzulassen.

Es ist ratsam, im Formular HTML als Eingabe zu verbieten und auszuknipsen:
http://de2.php.net/strip_tags
Und zwar komplett, um so auch "inline Javascripte" auszuschließen.

[Thomas H.]

aber durch den Parameter ENT_QUOTES werden die Anführungszeichen doch konvertiert => keine Gefahr für den mysql_query!?

Normalerweise grenze ich die Benutzereingaben deutlich ein, aber ich will nur eine schon vorhanden Seite (von jemanden anderen) sicher machen....
durch htmlspecialchars werden html-tags doch sowieso nicht mehr ausgeführt, da brauch ich kein strip_tags.

lg
Thomas

[conmunich]

nein, htmlspecialchars wandelt mit der option ENT_QUOTES, wandelt z.b. ein einfaches anführungszeichen ' in die html schreibweise " um. mysql_real_escape_string hingegen escaped ein ' mit einem backslash \ also \'

edit: glaub ich hab dich falsch verstanden. :)

[defabricator]

htmlentities(, ENT_QUOTES) hilft sogar gegen die von Chris Shifflet augezeigten Probleme mit addslashes(). Allerdings werden die tatsächlichen Nutzdaten verändert, d.h. es wird "nur" eine für HTML equivalente Darstellung abgespeichert.

[meikel (†)]

aber durch den Parameter ENT_QUOTES werden die Anführungszeichen doch konvertiert => keine Gefahr für den mysql_query!?
Es gibt noch mehr Fallstricke:
mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.


durch htmlspecialchars werden html-tags doch sowieso nicht mehr ausgeführt, da brauch ich kein strip_tags.
Da unterscheiden wir uns wohl...

[defabricator]

Es gibt noch mehr Fallstricke:mysql_real_escape_string() behandelt unter Umständen sogar noch mehr Zeichen als die hier aufgeführten.
Ich rate allerdings, schon allein um die Daten möglichst unverändert zu speichern, auch zu mysql_real_escape_string() oder der dafür ausgewiesenen Methode der Datenbankabstraktion.