Логические уязвимости при составлении SQL запросов с LIKE

в 8:32, , рубрики: like, ONsec, sql-injection, sql-инъекция, безопасность веб-приложений, информационная безопасность, метки: , , , ,

Когда пользовательские данные попадают в запрос под оператор LIKE следует быть предельно внимательными.
Дело в том, что ни одна функция фильтрации, включая mysql_real_escape_string, и даже prepared statements не защитят от логических ошибок, связанных с wildcard символами.

В нашей практике аудита веб-приложений, данная ошибка встречается примерно в каждом пятом веб-приложении, уязвимом к SQL-инъекциям (19.3%).

Оператор LIKE используется для поиска по неточному значению, строковых типов.
Синтаксис оператора позволяет использовать wildcard семантику, где
% заменяет классический * — последовательность любых символов
_ заменяет классический? — любой одиночный символ

Частая ошибка разработчиков состоит в том, что символы % и _ не фильтруются в попадании пользовательских данных в SQL запрос. Да, нарушить синтаксис запроса, то есть выполнить внедрение операторов, в этом случае нельзя, но может пострадать логика работы веб-приложения.

Распространенное заблуждение, также считать, что уязвимость купируется минимальной длинной строки.
SQL запрос
SELECT asd FROM t1 WHERE name LIKE '%%%%%%%%%%%%%%%%%%%%%%%%%%%'
работает абсолютно также, как
SELECT asd FROM t1 WHERE name LIKE '%%'

Но даже если ошибки логики в консутрукции нет, не следует пропускать wildcard там, где этого явно не требуется. Ведь все хорошо знают, как тормозят запросы c LIKE, а с полным wildcard в LIKE они тормозят сильнее.
Это может быть использовано для DoS, DDoS, или же получения информации от сервера путем провокации сообщений об ошибки (вроде истечения max_execution_time)

Автор: d0znpp

Поделиться

* - обязательные к заполнению поля