[php] sichere MySQL Queries

[Lutz Zetzsche]

Hallo AA,

Am Donnerstag, 9. November 2006 14:30 schrieb AA:
> zum semikolon-m�rchen:
> ----------------------
> das mit dem semikolon im query ist eine legende. mysql und mysqli
> filtern dies heraus. das steht auch im handbuch:
>
> "The query string should not end with a semicolon."

da steht nur, da� am Ende kein Semikolon stehen *sollte*. Von Filtern 
ist da keine Rede. Nach meiner Erinnerung hat Peter recht, da� es - 
zumindest bei der mysql-Erweiterung - tats�chlich zu einer 
Fehlermeldung kommt, wenn der Query-String ein abschlie�endes Semikolon 
enth�lt.

> aus bestimmten gr�nden, kann dies aber gewollt sein (mehrere queries
> in einem befehl). daf�r liefert mysqli die funktion/methode
> mysqli_multi_query() / multi_query():
>
> "executes one or multiple queries which are concatenated by a
> semicolon."

In dem Augenblick h�tten wir dann aber auch  potentiell genau das 
Sicherheitsloch, um das es Michael in seiner Frage ging. ;-)

> zum einsatz von prepared statements als heilmittel:
> ---------------------------------------------------
> schickes feature :)

Ich sagte nicht, da� es sich um ein Allheilmittel handelt, allerdings 
halte ich Prepared Statements f�r die sicherste Methode, 
SQL-Einschleusung zu vermeiden. Mir ist klar, da� das bei nur einmal 
ausgef�hrten SQL-Befehlen zu einem Performanzverlust f�hrt, jedoch 
bewerte ich pers�nlich den Sicherheitsgewinn deutlich h�her. Wen es 
interessiert, kann ja auch mal auf der MySQL-Website nachlesen und sich 
sein eigenes Bild machen:

http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

> was dagegen spricht: will man eine portable anwendung schreiben (zb.
> mit der PDO-erweiterung), sollte man dies tunlichst unterlassen.
> leider findet sich dieser entscheidende hinweis nicht �berall da, wo
> er hingeh�rt. aber zumindest wird es bei PDO-mysql in einem nebensatz
> erw�hnt:
>
> "If you're writing portable code, you should use
> PDOStatement::fetchAll() instead."

M�glicherweise habe ich von der Materie zu wenig Ahnung, aber aus meiner 
Sicht hast Du hier etwas falsch interpretiert. Dieser Satz bezieht sich 
auf die vordefinierte Konstante PDO::MYSQL_ATTR_USE_BUFFERED_QUERY und 
steht auf folgender Seite:

	http://de3.php.net/manual/en/ref.pdo-mysql.php

Zum einen handelt es sich hier also um eine MySQL-spezifische Konstante 
und zum anderen vermute ich, da� man sie im Zusammenhang mit Prepared 
Statements auf TRUE setzen kann, aber nicht mu�.

Viel wichtiger erscheint mit folgendes Zitat von der 
PDO-Einf�hrungsseite:

"Prepared statements are so useful that they are the only feature that 
PDO will emulate for drivers that don't support them. This ensures that 
you will be able to use the same data access paradigm regardless of the 
capabilities of the database."
-> http://de3.php.net/manual/en/ref.pdo.php

Wenn das so ist, dann ist die Portabilit�t auch bei der Verwendung von 
Prepared Statements doch grunds�tzlich erst einmal gew�hrleistet. 
Andersherum formiliert: Die PDO-Erweiterung soll ja gerade die 
Portabilit�t gew�hrleisten. W�rde die Verwendung von Prepared 
Statements dieses Ziel zunichte machen, g�be es sicherlich nicht die 
M�glichkeit, diese mit PDO zu verwenden.

Ein weiterer Punkt ist, da� es wahre Portabilit�t wohl nur schwerlich 
gibt. Selbst Hibernate erreicht sie nicht. Es gibt nur eine 
gr��tm�gliche Ann�herung. ;-)

> zur eigentlichen frage: "sichere mysql-queries?"
> ------------------------------------------------
> das ist ein komplexes thema und l�sst sich nicht mit einer formel
> beantworten. es gibt allerdings eine grundregel: text, der in ene db
> gespeichert wird, muss escaped werden.

Das ist eben genau der entscheidende Denkfehler... Du mu�t jedes Feld 
"escapen". Der Grund ist einfach: Wer garantiert Dir, da� dort, wo Du 
im SQL-Befehl eine Zahl vorgesehen hast, auch eine Zahl ankommt und 
nicht etwa eine eingeschleuste Zeichenkette � la '1 OR 1=1'? Es ist ein 
gravierender Denkfehler, sich nur auf die Textfelder zu konzentrieren.


Viele Gr��e
Lutz