PHP funktion gegen SQL-Injection

[22hase]

also brauche ich nur mysql_real_escape_string($var, $db) nehmen und das ist schutz genug?

natürlich wenn ich beispielsweise so eine abfrage habe

"select * from user where uid=".$_GET['uid'] 

lieber so

$id = (int)$_GET['uid'];
"select * from user where uid=".$id 

dann wenn in formularen nur zahlen eingeben werden soll kann man dies ja auch prüfen, desweiteren habe ich die formular felder auf eine maximallänge gesetzt, ist doch sicherauch noch ein wenig schutz oder?

[nikosch]

also brauche ich nur mysql_real_escape_string($var, $db) nehmen und das ist schutz genug?

Für Strings, ja. Und für Zahlen hast Du ja ein Beispiel gepostet.

[22hase]

und da mach ich mir so ne platte? ich fass es ne...

aber könnte man eventuell noch zeichen wie +- usw aus der eingabe filter..wenn man weiß das a-z eingeben werden muss...

[David]

Unter Umständen kann ein MySQl integer einen größeren Wertbereich haben als ein PHP integer.

D:\webserver\xampp\php>php.exe -v
PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend Technologies
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

D:\webserver\xampp\php>php.exe -r "echo PHP_INT_MAX;"
2147483647

Das ist kleiner als der Maximalwert eines unsigned int in MySQL (4294967295)
Einen Datesatz mit id=2147483650 kann man also nicht mit

$sql ='SELECT ... WHERE id='.(int)$id 

abfragen.

[nikosch]

aber könnte man eventuell noch zeichen wie +- usw aus der eingabe filter..wenn man weiß das a-z eingeben werden muss...

Das ist eine Frage der Validierung und hat so nichts mit SQL Sicherheit zu tun.

Einen Datesatz mit id=2147483650 kann man also nicht mit
PHP-Code:
$sql ='SELECT ... WHERE id='.(int)$id
abfragen.

Trotzdem sollten 2 Milliarden Datensätze für den Großteil der Anwender ausreichen, so dass man (int) $var wohl als weitgehend allgemeingültige Methode propagieren darf. Aber interessanter Hinweis.

[22hase]

Unter Umständen kann ein MySQl integer einen größeren Wertbereich haben als ein PHP integer.
Das ist kleiner als der Maximalwert eines unsigned int in MySQL (4294967295)
Einen Datesatz mit id=2147483650 kann man also nicht mit

$sql ='SELECT ... WHERE id='.(int)$id 

abfragen.

und wie sollte es deiner meinung nach richtig oder besser sein?

[David]

Du meinst abgesehen von "verwende prepared statements"?

Solltest Du eine Tabelle haben, bei der Du mit solchen Werten rechnen musst, würde ich den Parameter einfach als Zeichenkette behandeln.

$sql = "SELECT ... WHERE id='".mysql_real_escape_string($_POST['id'], $mysql) . '"; 

[22hase]

Du meinst abgesehen von "verwende prepared statements"?

Solltest Du eine Tabelle haben, bei der Du mit solchen Werten rechnen musst, würde ich den Parameter einfach als Zeichenkette behandeln.

$sql = "SELECT ... WHERE id='".mysql_real_escape_string($_POST['id'], $mysql) . '"; 

wie gesagt ich bleib erstmal beim alten..

und wenn man

$id = (int)$_POST["id"];
$sql = "SELECT ... WHERE id='".mysql_real_escape_string($_POST['id'], $mysql) . '"; 

macht? bringt auch net mehr sicherheit oder

[Wolla]

Es heißt mysql_real_escape_string und nicht mysql_real_escape_int

[22hase]

also ich mach bei zahlen jetzt mit int und bei strings eben mysql_real_escape_string

nach den meinungen scheint es ja sicher zu sein...werd noch alle zeichen wie +,-,*', usw aus der eingabe filtern und formular felder begrenzen...

düfte dann ja reichen...

[nikosch]

Es ist nur sicher, wenn es dann immer in Anführungsstrichen steht. Vgl.

$_GET[id] => 0
$_GET[id] => 0 OR 1=1
$_GET[id] => 0 OR 1

'SELECT * FROM Accounts WHERE id = ' . $_GET['id']

Außerdem bietet es eben keine Typsicherheit, also wird ein nicht num. String eben u.U. als 0 oder anders interpretiert.