Böswillige Einträge verhindern

zwutz schrieb:

JEDE Benutzereingabe

... ich würde aber sagen, dass bei Primitivtypen (wie int, char etc.) ein entsprechender "Sicherheitscast" sinnvoller ist

$sql = "INSERT INTO students(name, age, gender) VALUES('".sqlRealEscapeString($age)."', ".((int)$age).", '".sqlRealEscapeString($gender)."')";

Wobei, bei komplexeren Systemen baut man sich sinvollerweise einen Wrapper, dann ist das Thema ohnehin obsolete

$statement = 'INSERT INTO studends(name, age, gender) VALUES(:name:, :age:, :gender:)';
$statement->bindParams(array('name' => $name, 'age' => $age, 'gender' => $gender));
$statement->execute();

unsigned long

wie wäre es mit escapen und sprintf?

unsigned long schrieb:

wie wäre es mit escapen und sprintf?

Im Bezug auf welchen Post?

Falls auf meinen:
Das ist natürlich möglich, bei Verwendung eines Wrappers aber eher unpraktisch (wobei der Wrapper die Technik natürlich selbst durchaus verwenden könnte). Außerdem bist du dann an die Reihenfolge der Parameter gebunden.

tntnet

árn[y]ék schrieb:

Wobei, bei komplexeren Systemen baut man sich sinvollerweise einen Wrapper, dann ist das Thema ohnehin obsolete
$statement = 'INSERT INTO studends(name, age, gender) VALUES(:name:, :age:, :gender:)';
$statement->bindParams(array('name' => $name, 'age' => $age, 'gender' => $gender));
$statement->execute();

Diese prepared statements, wie hier vorgeschlagen, sind die korrekte Lösung. Diese sqlescapeirgendwas sind Workarounds, die unbedingt zu vermeiden sind. Prepared Statements sind schneller, sicherer, einfacher und portabler. Es gibt eigentlich kaum einen Grund, diese nicht zu verwenden.

zwutz

tntnet schrieb:

Diese sqlescapeirgendwas sind Workarounds, die unbedingt zu vermeiden sind.

Begründung? Vor allem im Bezug auf "unbedingt zu vermeiden"

Sa*n*dman

Das seh ich etwas differenzierter.

Auch mit DB-API und Prepared Statements werden Escape-Routinen intern immer noch verwendet. Sobald also der Fall eintritt, daß Du Dir besagtes API auch noch selbst schreiben musst, kannst Du auch einfach direkt mit besagten Escape-Funktionen arbeiten. Wer weiß denn, ob Du die zusätzlichen Möglichkeiten eines API wirklich benötigst?

Wenn die verwendete Sprache das API zur Verfügung stellt, dann ist das was anderes. Andernfalls entwickelst Du unter Umständen nur Overhead für Deinen konkreten Anwendungsfall.

So pauschal kann man also weder das eine, noch das andere befürworten.

Gruß Jens

ronny

bind parameter werden separat übertragen, von daher ist kein escaping notwendig
die db engine bekommt das direkt als wert

PHP 4 kann leider keine Prepared Statements

zwutz

ussa schrieb:

PHP 4 kann leider keine Prepared Statements

dann nimm php5

tntnet

Sa(n)dman schrieb:

Wenn die verwendete Sprache das API zur Verfügung stellt, dann ist das was anderes. Andernfalls entwickelst Du unter Umständen nur Overhead für Deinen konkreten Anwendungsfall.

Overhead entsteht durch das zusammenbauen eines SQL-Strings mit escapen der Sonderzeichen. Eine gute Datenbank-API macht das, was ronny sagt: es überträgt die bind-Parameter separat, was sicherer und effizienter ist.

Ein escapeiregendwas wird beim codieren gerne mal vergessen. Und dann hat man wieder ein SQL-injection. Bei Bind-Parametern kann das nicht passieren.

Stellt die API keine prepared Statements zur Verfügung, wie laut Aussage von ussa PHP4, dann ist die API ungenügend. Wenn man die API unbedingt verwenden muß, dann sollte man lieber einen Wrapper bauen, welcher sich so verhält, als hätte man prepared Statements. Das hat 2 Vorteile: Zum einen baut man diese escape-Sachen nur an einer Stelle ein und kann das dann ausgiebig testen und zum anderen hält man sich eine Hintertür offen, mal auf was vernünftiges umzusteigen.

Es kann dennoch Situationen geben, wo prepared Statements nicht verwendet werden können. Diese sind aber sehr selten und in der Regel ein Hinweis auf einen möglichen Designfehler in der Applikation.