PDO prepare und (MySQL-)SQL-Injections?

[rkr]

http://stackoverflow.com/questions/1...02218#12202218

[Tropi]

Sollte wohl eher heißen "PDO prepare und MySQL-Injections", andere PDO Treiber unterstützen echte Prepared Statements.
Danke für den Hinweis aber, kannte diesen Angriff nicht.

[rkr]

Habs angepasst

[BlackScorp]

is interessant zu wissen aber

Wrapping Up

If you:

Use Modern Versions of MySQL (late 5.1, all 5.5, 5.6, etc) AND PDO's DSN charset parameter (in PHP ≥ 5.3.6)

OR

Don't use a vulnerable character set for connection encoding (you only use utf8 / latin1 / ascii / etc)

OR

Enable NO_BACKSLASH_ESCAPES SQL mode

You're 100% safe.

$pdo->query('SET NAMES gbk'); 

solange ich arbeite(ist nicht viel) aber so etwas habe ich noch nie gesehen

[tr0y]

Alter Hut, 0815 Anwendungen die auf UTF-8 Datenbankseitig, Anwendungssetig und Clientseitig setzen sind von dem Problem nicht betroffen.

[rkr]

Ja, ist schon etwas älter. Für mich war die Schlagzeile jetzt

The important thing to realize here is that PDO by default does NOT do true prepared statements. It emulates them (for MySQL). Therefore, PDO internally builds the query string, calling mysql_real_escape_string() (the MySQL C API function) on each bound string value.

[tr0y]

Was ja schwachfug wäre, da die MySQL C API schon seit 3.2.* mysql_stmt_bind_param() kann was ein nutzen von mysql_real_escape_string() in kombination mit mysql_stmt_bind_param() in verfälschte Values resultieren lassen würde.

[monolith]

Vielleicht auch einfach nicht mehr up-to-date? Die Antwort ist von April 2012.

[tr0y]

Vielleicht auch einfach nicht mehr up-to-date? Die Antwort ist von April 2012.

Naja die Antwort wurde ja im März von jemanden aktualisiert. Das Problem besteht ja solange niedrigere MySQL-Versionen und non-UTF Encodings verwendet werden ( warum man das heutzutage auch immer tun sollte ).

[dingsda]

Ja, ist schon etwas älter. Für mich war die Schlagzeile jetzt

ich versteh nicht was daran eine schlagzeile ist. ist das nicht schon allgemein bekannt, dass pdo die prepared queries bei mysql nur emuliert, wenn man nicht explizit ATTR_EMULATE_PREPARES auf false setzt.

dass es dabei dann auf mysql_real_escape_string (die C funktion) zurückgreift ist doch nur logisch.

hab ich hier irgendwas missverstanden?

[erc]

ich versteh nicht was daran eine schlagzeile ist. ist das nicht schon allgemein bekannt, dass pdo die prepared queries bei mysql nur emuliert, wenn man nicht explizit ATTR_EMULATE_PREPARES auf false setzt.

Schön... In der Dokumentation stehts zwar anders (http://php.net/manual/en/ref.pdo-mysql.php), aber wer liest sowas schon...

[mermshaus]

Mir war das auch nicht bekannt. Wo steht denn das in der Doku[, dass es bei MySQL nur emuliert wird]?

[Arne Drews]

PDO::ATTR_EMULATE_PREPARES Enables or disables emulation of prepared statements. Some drivers do not support native prepared statements or have limited support for them. Use this setting to force PDO to either always emulate prepared statements (if TRUE), or to try to use native prepared statements (if FALSE). It will always fall back to emulating the prepared statement if the driver cannot successfully prepare the current query. Requires bool.

Was ich nicht rauslese ist, welches der Default-Wert ist? Aufgrund des Fallback-Verhaltens, macht FALSE als Default-Einstellung imho mehr Sinn.
Müsste man aber evtl. über getAttribute herausfinden können...

[Trainmaster]

Der Default-Wert ist true, siehe: http://marc.info/?l=php-internals&m=133972232919056&w=2

[Arne Drews]

Oha... Wieder was dazu gelernt...