Die Verwendung von gebundenen Parametern ist in allgemeinen Fällen ausreichend und eine bewährte Methode zur Vermeidung von SQL-Injektionen.
Aber ein Parameter in einer vorbereiteten Anweisung kann nur für einen Wert verwendet werden in einem SQL-Ausdruck. Mit anderen Worten, wo Sie normalerweise ein String-Literal in Anführungszeichen, ein Datums-Literal in Anführungszeichen oder ein numerisches Literal schreiben würden. Und ein Parameter ==ein Wert (keine Listen).
Sie sollten für diese Fälle gebundene Parameter verwenden. Wenn Sie diese Frage stellen, weil Sie denken, dass Sie die Verwendung gebundener Parameter überspringen möchten, wenn jemand antwortet, dass sie nicht ausreichend sind, dann werden Sie leider nicht von sicheren Programmierpraktiken entschuldigt.
Es gibt jedoch andere (vielleicht weniger häufige) Fälle, in denen gebundene Parameter nicht funktionieren. Wenn Sie eine Abfrage mit einem dynamischen Tabellennamen, Spaltennamen oder einer anderen Kennung oder einem ganzen Ausdruck oder einem SQL-Schlüsselwort schreiben müssen, benötigen Sie eine andere Methode. Diese Fälle müssen in der SQL-Syntax bei prepare behoben werden Zeit, sind also nicht parametrierbar.
Hier ist zum Beispiel eine Abfrage mit dynamischen Teilen, die durch die Verwendung von Variablen gekennzeichnet sind, die keine Parameter sein können:
$sql = "SELECT * FROM mytable ORDER BY $column_of_users_choice $asc_or_desc";
In diesen Fällen sollten Sie die Whitelist verwenden . Stellen Sie mit anderen Worten sicher, dass eine Zeichenfolge, die Sie als dynamischen Tabellennamen in Ihre Abfrage interpolieren, tatsächlich eine der Tabellen ist, die in Ihrer Datenbank vorhanden ist. Stellen Sie sicher, dass SQL-Schlüsselwörter legitime Schlüsselwörter sind.
Niemals Nehmen Sie Benutzereingaben wörtlich und interpolieren Sie sie in SQL (oder jeden anderen Code, der zur Laufzeit analysiert wird, wie das Argument, das Sie eval() zuführen oder shellexec() ). Und nicht nur Benutzereingaben können unsichere Inhalte sein.
Siehe auch meine Präsentation Mythen und Irrtümer über die SQL-Injektion für weitere Erklärungen.
