Это не так просто. Вы можете использовать связанные параметры вместо интерполяции прикладных переменных в выражения SQL вместо только буквальных значений :
$sql = "SELECT * FROM MyTable WHERE id = ".$_GET["id"]; // not safe
$sql = "SELECT * FROM MyTable WHERE id = ?"; // safe
Но что, если вам нужно сделать часть запроса динамической помимо литерального значения?
$sql = "SELECT * FROM MyTable ORDER BY ".$_GET["sortcolumn"]; // not safe
$sql = "SELECT * FROM MyTable ORDER BY ?"; // doesn't work!
Параметр всегда будет интерпретироваться как значение, а не идентификатор столбца. Вы можете выполнить запрос с ORDER BY 'score', который отличается от ORDER BY score, и использование параметра будет интерпретироваться как первый - постоянная строка 'score', а не значение в столбце с именем score.
Так что во многих случаях приходится использовать динамический SQL и интерполировать переменные приложения в запросе, чтобы получить желаемые результаты. В этих случаях параметры запроса не могут вам помочь. Вы все еще должны быть бдительными и защищаться от ошибок, чтобы предотвратить ошибки SQL-инъекций.
Никакая платформа или библиотека доступа к данным не может сделать эту работу за вас. Вы всегда можете создать строку запроса SQL, которая содержит недостаток внедрения SQL, и вы делаете это до того, как библиотека доступа к данным увидит запрос SQL. Так как же узнать, что является преднамеренным и в чем недостаток?
Вот методы для достижения безопасных запросов SQL:
Фильтр ввода. Трассировка любых переменных данных, которые вставляются в ваши SQL-запросы. Используйте входные данные filters для удаления недопустимых символов. Например, если вы ожидаете целое число, убедитесь, что ввод ограничен целым числом.
Выход Escape. Выходом в этом контексте может быть запрос SQL, который вы отправляете на сервер базы данных. Вы знаете, что можете использовать параметры SQL-запроса для значений, но как насчет имени столбца? Вам нужна функция экранирования / цитирования для идентификаторов, так же, как старый mysql_real_escape_string() для строковых значений.
Обзоры кода. Попросите кого-нибудь стать второй парой глаз и просмотреть ваш код SQL, чтобы помочь вам определить места, где вы не воспользовались двумя вышеупомянутыми методами.