Когда пользовательские данные попадают в запрос под оператор LIKE следует быть предельно внимательными.
Дело в том, что ни одна функция фильтрации, включая mysql_real_escape_string, и даже prepared statements не защитят от логических ошибок, связанных с wildcard символами.
В нашей практике аудита веб-приложений, данная ошибка встречается примерно в каждом пятом веб-приложении, уязвимом к SQL-инъекциям (19.3%).
Оператор LIKE используется для поиска по неточному значению, строковых типов.
Синтаксис оператора позволяет использовать wildcard семантику, где
% заменяет классический * — последовательность любых символов
_ заменяет классический? — любой одиночный символ
Частая ошибка разработчиков состоит в том, что символы % и _ не фильтруются в попадании пользовательских данных в SQL запрос. Да, нарушить синтаксис запроса, то есть выполнить внедрение операторов, в этом случае нельзя, но может пострадать логика работы веб-приложения.
Распространенное заблуждение, также считать, что уязвимость купируется минимальной длинной строки.
SQL запрос
работает абсолютно также, как
Но даже если ошибки логики в консутрукции нет, не следует пропускать wildcard там, где этого явно не требуется. Ведь все хорошо знают, как тормозят запросы c LIKE, а с полным wildcard в LIKE они тормозят сильнее.
Это может быть использовано для DoS, DDoS, или же получения информации от сервера путем провокации сообщений об ошибки (вроде истечения max_execution_time)
Дело в том, что ни одна функция фильтрации, включая 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)
