Являются ли санация ввода и параметризованные запросы взаимоисключающими?

Question

Я работаю над обновлением устаревшего кода, который неправильно обрабатывает ввод пользователя. Код выполняет минимальную дезинфекцию, но не охватывает все известные угрозы.

Наш новый код использует параметризованные запросы. Насколько я понимаю, запросы предварительно скомпилированы, а ввод обрабатывается просто как данные, которые не могут быть выполнены. В этом случае санитарная обработка не требуется. Это верно?

Другими словами, если я параметризирую запросы в этом унаследованном коде, нормально ли это устранять очистку, которая выполняется в настоящее время? Или я упускаю некоторые дополнительные преимущества санитаризации помимо параметризации?

Answer 1

Это правда, что параметры запроса SQL являются хорошей защитой от внедрения SQL. Встроенные кавычки или другие специальные символы не могут причинить вреда.

Но некоторые компоненты SQL-запросов не могут быть параметризованы. Например. имена таблиц, имена столбцов, ключевые слова SQL.

$sql = "SELECT * FROM MyTable ORDER BY {$columnname} {$ASC_or_DESC}";

Итак, есть несколько примеров динамического контента, который вам может потребоваться проверить перед интерполяцией в SQL-запрос. Значения белого списка также являются хорошим методом.

Также у вас могут быть значения, которые разрешены типом данных столбца, но будут бессмысленными. В этих случаях часто проще использовать код приложения для проверки, чем пытаться проверять ограничения SQL.

• Предположим, вы храните номер кредитной карты. Существуют допустимые шаблоны номеров кредитных карт, и библиотеки могут распознавать действительные номера из недействительных.

• Или как насчет того, когда пользователь определяет свой пароль? Возможно, вы захотите обеспечить достаточную надежность пароля или подтвердить, что пользователь ввел одну и ту же строку в два поля ввода пароля.

• Или, если они заказывают количество товара, вам может потребоваться сохранить количество в виде целого числа, но вы хотите убедиться, что оно больше нуля и, возможно, если оно больше 1000, вы хотите удвоить -проверьте с пользователем, что они правильно ввели.

Answer 2

Параметризованные запросы помогут предотвратить внедрение SQL, но они не будут противодействовать межсайтовому скриптингу.Вам нужны другие меры, такие как кодирование HTML или обнаружение / проверка HTML, чтобы предотвратить это.Если все, что вас волнует, - это внедрение SQL, вероятно, достаточно параметризованных запросов.

Answer 3

Существует много разных причин для санации и проверки, в том числе для предотвращения межсайтовых сценариев и простого выбора нужного содержимого для поля (без имен в телефонных номерах).Параметризованные запросы устраняют необходимость ручной очистки или экранирования от внедрения SQL.

См. Один из моих предыдущих ответов по этому вопросу.

Answer 4

Важно отметить, что в качестве незначительного момента иногда полезно писать хранимые процедуры, которые содержат динамический SQL.В этом случае тот факт, что входные данные параметризованы, не является автоматической защитой от внедрения SQL.Это может показаться довольно очевидным, но я часто сталкиваюсь с людьми, которые думают, что, поскольку их входные данные параметризованы, они могут просто перестать беспокоиться о SQL-инъекции.

Answer 5

короче нет.Очистка ввода и использование параметризованных запросов не являются взаимоисключающими, они независимы: вы не можете использовать ни один, ни один, или оба.Они предотвращают различные типы атак.Использование обоих - лучший курс.

Answer 6

Вы правы, параметры SQL не являются исполняемым кодом, поэтому вам не нужно об этом беспокоиться.

Тем не менее, вам все равно придется немного проверить.Например, если вы ожидаете, что varchar (10) и пользователь введут что-то более длинное, вы получите исключение.