Het gebruik van gebonden parameters is in veel voorkomende gevallen voldoende en een goede gewoonte om SQL-injectie te vermijden.
Maar een parameter in een voorbereide instructie kan alleen worden gebruikt voor een waarde in een SQL-expressie. Met andere woorden, waar u normaal gesproken een letterlijke tekenreeks tussen aanhalingstekens, letterlijke datum tussen aanhalingstekens of letterlijke cijfers zou schrijven. En één parameter ==één waarde (geen lijsten).
Voor die gevallen moet u gebonden parameters gebruiken. Als je deze vraag stelt omdat je denkt dat je het gebruik van gebonden parameters misschien wilt overslaan als iemand antwoordt dat ze niet voldoende zijn, sorry, dan krijg je geen excuus voor veilige programmeerpraktijken.
Er zijn echter andere (misschien minder voorkomende) gevallen waarvoor gebonden parameters niet werken. Als u een query moet schrijven met een dynamische tabelnaam, kolomnaam of andere id, of een hele expressie of een SQL-sleutelwoord, dan hebt u een andere methode nodig. Deze gevallen moeten worden opgelost in de SQL-syntaxis op prepare tijd, zodat ze niet kunnen worden geparametriseerd.
Hier is bijvoorbeeld een query met dynamische delen die worden aangegeven door het gebruik van variabelen, die geen parameters kunnen zijn:
$sql = "SELECT * FROM mytable ORDER BY $column_of_users_choice $asc_or_desc";
Voor die gevallen moet u witte lijsten gebruiken . Met andere woorden, zorg ervoor dat een tekenreeks die u in uw query interpoleert als een dynamische tabelnaam, daadwerkelijk een van de tabellen is die in uw database bestaat. Zorg ervoor dat SQL-zoekwoorden legitieme zoekwoorden zijn.
Nooit neem de gebruikersinvoer letterlijk en interpoleer deze in SQL (of een andere code die tijdens runtime wordt geparseerd, zoals het argument dat u invoert voor eval() of shellexec() ). En het is niet alleen gebruikersinvoer die onveilige inhoud kan zijn.
Zie ook mijn presentatie SQL Injection Myths and Fallacies voor meer uitleg.