• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

MySQL - SQL-Inject verhindern

Hallo-Welt

Aktives Mitglied
Guten Tag,

ich wollte fragen, ob bei einer durch den User eigegebenen Eingabe, nach welcher direkt in der DB abgefragt wird, einfach die Abfrage durch:
PHP:
$totsichereAbfrage = mysqli_real_escape_string($verbingungZurDatenbank, $_POST['userDefinierteEingabeNachDerInDerDBGesuchtWird']);
genügt?

Ist so eine SQL Injektion unmöglich? Oder müssen noch ganz andere Sicherheitsvorkehrungen getroffen werden?
 
Okay, das schaut sich vielversprechend an, jedoch müsste ich mich da erst einmal einarbeiten. Bevor ich das tue, würde ich dennoch gerne wissen, ob das "escapen" (was ja an sich wirklich keine Mühe macht und auch keine Umstellung verlangt) denn ebenso 100-ig vor SQL Injektionen schützt, was ja das Haupteinfallstor für Hacker ist.

An dieser Stelle würde mich auch noch interessieren, welche schwerwiegenden Fehler man noch so Sicherheitsbezogen machen kann, bzw. wie Hacker noch ein leichtes haben, sich Zugang zur DB oder sogar zum Quellcode zu verschaffen?
 
Weiß niemand weiter, oder habe ich irgendetwas hier missachtet?!
Kennt denn niemand ein Buch ein Link ein Artikel oder irgendwas, was mir weiterhelfen könnte? Reicht das "real_escape" aus, oder nicht, um eine SQL-Injektion zu verhindern?
 
Okay, danke für diese Einschätzung. Das heißt, mit "mysqli_real_escape_string" ist eine SQL-Injektion vom Prinzip her unmöglich, richtig?
 
Ein gutes Beispiel das zeigt warum mysql_real_escape_string() unsicher ist:

Code:
$id = $_GET['id'];
$sql ='SELECT `name` FROM `user` WHERE `id` = ', mysqli_real_escape_string($id);

Wenn nun aus dem GET-Request eine einfache Zahl wie 1 kommt, dann haut alles hin. Sobald es aber
Code:
1 OR id IN(1,2,3,4,5)
ist, dann wird aus dem Statement bei der Generierung:

Code:
SELECT `name` FROM `user` WHERE `id` = 1 OR id IN(1,2,3,4,5)

was ja nicht Sinn der Sache ist. So könnte ein Nutzer auf unzulässige Art an Datensätze kommen die er nicht sehen soll - schlimmer noch: er könnte darüber auch Lücken in MySQL ausnutzen.

Der Web über prepared Statements mit Bindvars ist heute der beste Web um sich vor SQL Injections zu schützen.
 
Ein gutes Beispiel das zeigt warum mysql_real_escape_string() unsicher ist:

Code:
$id = $_GET['id'];
$sql ='SELECT `name` FROM `user` WHERE `id` = ', mysqli_real_escape_string($id);

Wenn nun aus dem GET-Request eine einfache Zahl wie 1 kommt, dann haut alles hin. Sobald es aber
Code:
1 OR id IN(1,2,3,4,5)
ist, dann wird aus dem Statement bei der Generierung:

Code:
SELECT `name` FROM `user` WHERE `id` = 1 OR id IN(1,2,3,4,5)

was ja nicht Sinn der Sache ist. So könnte ein Nutzer auf unzulässige Art an Datensätze kommen die er nicht sehen soll - schlimmer noch: er könnte darüber auch Lücken in MySQL ausnutzen.

Der Web über prepared Statements mit Bindvars ist heute der beste Web um sich vor SQL Injections zu schützen.
Vielen Dank für diese Ausführliche Antwort. Ich war kurz davor, mich auf mysql_real_escape_string zu verlassen. Also die einzige effektive Möglichkeit sich gegen die SQL_Injection zu schützen ist die schon in der ersten Antwort genannte, richtig?
 
Zurück
Oben