Antworten
Es gibt APIs die Parametrisierte Abfragen unterstützen, z.B. die von drupal.
Ich habe eine Datenbankabstraktionsschicht geschrieben, die zu jedem Entitätstyp Klassen zum Speichern, Laden und Löschen der Objekte verwendet. Wenn ich diese Klassen programmiere, dann weiss ich, das ich mit potentiell nicht vertrauenswürdigen Daten hantiere. Da schaltet dann im Gehirn irgendetwas um, so daß ich überhaupt nicht mehr weiß wie "SELECT * FROM {$_POST['tabelle']}" überhaupt geschrieben wird.
Es gibt natürlich auch schon vorgefertigte Datenbankschnittstellen, z.B. Propel. Die sollten ebenfalls über Mechanismen verfügen, SQL-Injection zu verhindern. Optimalerweise solltest du davon aber dann nichts mehr mitbekommen.
2.
Die PHP Data Objects (PDO, seit PHP5 mit dabei) sollen angeblich bei vorher erstellten Abfragen SQL Injections verhindern ...
[doc]pdo-prepare[/doc]
3.
Die MySQLi-Erweiterung von PHP beherrscht durchaus auch prepared statements.
4.
Ok,
danke für eure Antworten. Aber mit meiner jetztigen Lösung über mysql_real_escape_String kann ich dies auch gut verhindern oder sollte ich lieber Parameter verwenden. Wäre halt jetzt etwas aufwändiger zu ändern!
5.
Wenn Du es konsequent durchziehst ist mysql_real_escape_string genau dafür gedacht und daher natürlich auch geeignet.
6.
Wundebar. dann werde ich dies weiterhin so umsetzen und für eine neues Projekt, den Weg über Parameter gehen!
7.
addslashes() ;)
8.
Die meisten plätze die gegen sql injection nicht geschützt sind,sind plätze wie:
view.php?id=
pic_view.php?id=
etc.....
Was Passiert?
id=
erwartet meistens eine Zahl!
d.h. wenn du anstatt einer Zahl einen buchstaben eingibst dann weiß die sql datenbank nicht welche id sie heruasnehmen soll
und es wird der fehler andgezeigt!
Wie schütze ich mich:
Das geht ganz schnell!
$id=$_GET['id'];
if (preg_match ("/UNION/i", $id)) { //Um daten aus der db zu holen verwendet man immer -1 UNION SELECT ....
exit;
};
if (preg_match ("/And/i", $id)) { //And ist für den Fall eine Blind Sql injection
exit;
};