addslashes und escape_mysql_string

Zitat von sentencedX

addslashes fügt vor " und ' ein / an, oder?

Das Escapen funktioniert hier mit Backslashes, also z.B. \". Das und viele andere Infos findest du im PHP Manual zu addslashes():

Zitat von PHP Manual - addslashes()

The PHP directive magic_quotes_gpc is on by default, and it essentially runs addslashes() on all GET, POST, and COOKIE data. Do not use addslashes() on strings that have already been escaped with magic_quotes_gpc as you'll then do double escaping. The function get_magic_quotes_gpc() may come in handy for checking this.

Also was bedeutet das? Wenn magic_quotes_gpc aktiviert ist, dann werden alle GET-, POST- und Cookie-Variablen automatisch escaped. Das bedeutet, dein String test's wurde bereits zu test\'s, bevor du die Variable benutzt. Wenn du jetzt noch einmal addslashes() darauf ausführst wird der String zu test\\\'s, weil der einzelne Backslash auch escaped wird. Sendest du diesen String an die Datenbank, wird sie wie immer nur einmal den Escape-Prozess rückgängig machen (also sozusagen stripslashes() ausführen), sodaß der String test\'s in die Tabelle eingefügt wird!

Das ist natürlich schlecht. Was du also tun kannst ist entweder die magic quotes ganz abzuschalten (was ich für die beste Lösung halte!), oder zur Laufzeit festzustellen ob diese aktiviert sind, und, wenn ja, deine GPC-Strings halt nicht mehr zu escapen.

Hoffe das war jetzt halbwegs verständlich...

Zitat von sentencedX

achja: wie bekomm ich aus einer Textarea die formatierung raus bzw. die returns? wenn ichs in die DB schreib krieg ich nachher alles nur in einer wurscht...

Wie meinst du das genau? Du kannst den Text aus einer Textarea ohne Probleme einfach so (eventuell escaped, siehe oben) in die DB schreiben! Falls du den Text nachher wieder in einer Textarea anzeigen willst solltest du htmlentities() drüber laufen lassen.

Falls du den Text einfach so auf der Seite anzeigen willst ruf ebenfalls htmlentities() auf, es sei denn du willst daß HTML-Code 1:1 vom Benutzer übernommen wird. Auf jeden Fall solltest du außerdem nl2br() auf den Text anwenden.

Da hab ich jetzt hoffentlich nichts durcheinander gebracht, ich bitte um Korrekturen wenn nötig.

Zitat von sentencedX

das mitm escapen check ich aber noch nicht ganz, und hab auch ein stranges *problem*
ich hab den text via textbox eingelesen -> echo hats mit \ ausgegeben -> in der DB ist es OHNE \ gestanden.

OK, das bedeutet also daß die magic quotes aktiviert sind. Die von dir benutzte GET- bzw. POST-Variable wurde automatisch escaped, daher auch der \ bei der Ausgabe mit echo. Wenn du diesen String ohne ihn weiter zu bearbeiten an die DB schickst, wird die Datenbank diese Escape-Zeichen ein einziges Mal auflösen. Das heißt, die Datenbank läuft einmal über deinen String und ersetzt alle \" durch ", alle \' durch ', alle \\ durch \, und wahrscheinlich noch ein paar andere Zeichen.

Darum mußt du eben aufpassen, daß addslashes() nur einmal ausgeführt wird - und zwar entweder durch die magic quotes-Automatik, oder manuell durch dich (falls die magic quotes deaktiviert wurden - was du übrigens auch durch eine .htaccess-Datei schaffen kannst).

Zitat von sentencedX

Aber jetzt,ohne code wirklich geändert zu haben oder addslashes extra zu verwenden, werden die \ auch eingetragen wenn ich ein neues hinzufüg *?? wtf ??*

Das versteh ich jetzt nicht ganz. Wenn die \ auch in der DB stehen, dann hast du sicher addslashes() irgendwie 2x ausgeführt (vielleicht eben das erste Mal bereits durch die magic quotes).

Zitat von sentencedX

aber warum ist es schlecht wenn die \ in der DB stehen? ich dachte sie sind dafür um sonderzeichen(',") zu "entschärfen" und man sollte es auf jeden fall verwenden?

In der DB selber stehen die \ dann nicht mehr! Das ist nur dazu da, der Datenbank einen "schönen" String zu schicken. Es ist überhaupt kein Problem wenn in der DB Apostrophe oder was auch immer stehen, das sind ja dann nur noch abgelegte Daten.

Hier noch was zu der generellen Problematik:

Stell dir vor, du willst von der DB wissen, ob es einen User mit diesem Namen und diesem Passwort gibt, im Script schaust du dann ob mysql_num_rows() > 0 ist:

SELECT * FROM users
WHERE name = 'humanic' AND pass = 'franz'

Soweit kein Problem, wenn der User wie hier "normale" Strings eingegeben hat. Aber jetzt stell dir vor, du tust die Strings nicht escapen und der User gibt bösartige Sachen ein, z.B. ins Passwort-Feld den String franz' OR 'a'='a:

SELECT * FROM users
WHERE name = 'humanic' AND pass = 'franz' OR 'a'='a'

Jetzt haben wir ein Problem! Der SQL-Server wird jetzt ziemlich sicher > 0 Ergebnisreihen zurückgeben, womit unter Umständen die Authentisierung erfolgen würde!

Wie schaut der String aus, wenn wir ihn vorher escapen?

SELECT * FROM users
WHERE name = 'humanic' AND pass = 'franz\' OR \'a\'=\'a'

Der SQL-Server würde hier also einmal den escape-Prozeß rückgängig machen, bevor er die Daten wirklich verwendet. Er würde also Zeile für Zeile das Passwort mit dem genauen String franz' OR 'a'='a vergleichen, was ja in Ordnung ist. Soll er doch.

Zitat von sentencedX

und was ist der unteschied zu escape_mysql_string? lt. php.net machen sie eh das selbe...

mysql_escape_string() escaped ein paar mehr Zeichen als addslashes(). Ich würde also mysql_escape_string() empfehlen, zumindest wenn du mit einem MySQL-Server arbeitest. Die werden schon wissen was für ihre DB escaped werden muß, sozusagen.