SQL-инъекция: как возникает уязвимость и как от неё защищают код

Большинство сайтов хранят информацию в базе данных и общаются с ней на языке запросов SQL. Программа формирует запрос, подставляя в него то, что ввёл пользователь: логин, поисковую фразу, номер товара. Уязвимость появляется, когда ввод просто склеивается со строкой запроса. Тогда специально составленный текст перестаёт быть данными и превращается в часть команды.

Именно поэтому проблему называют инъекцией: в запрос «впрыскивается» чужой фрагмент, который меняет его смысл.

Представьте, что запрос проверки входа собирается как «выбрать пользователя, у которого имя равно введённому и пароль равен введённому». Если вместо имени подставить фрагмент, который закрывает кавычку и добавляет условие, всегда истинное, проверка пароля теряет смысл. Похожими приёмами можно читать чужие таблицы, объединяя результаты запросов, или менять записи, если у приложения есть такие права.

Бывают слепые варианты, когда результат не выводится на страницу, а атакующий делает выводы по разнице в ответах или во времени отклика. Автоматизированные сканеры проверяют такие точки массово, поэтому уязвимый сайт находят быстро.

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

Наличие таких следов ещё не означает успеха атаки, но повод проверить, что код обращается к базе безопасно. Полезно включить журналирование запросов к базе, ограничить права приложения и настроить оповещения о всплесках ошибок базы, поскольку при подборе инъекции ошибки возникают часто. Регулярное обновление фреймворков закрывает известные слабые места, а тестирование безопасности до выпуска находит остальные.

Последствия зависят от прав учётной записи базы. Возможны утечка данных пользователей, нарушение авторизации, изменение и удаление информации, а иногда — выполнение команд на сервере при определённых настройках. Многие громкие утечки связывали именно с инъекциями.

Случайные фильтры вроде «запретить символ кавычки» не решают вопрос: подмена символов даёт другие пути, а законные значения, например фамилия с апострофом, ломаются.

Важно и то, что уязвимость чаще всего встречается не в «главной» форме входа, а в малозаметных местах: фильтрах каталога, сортировке, экспорте, скрытых полях и параметрах API. Разработчики иногда защищают очевидные формы, но забывают о параметре сортировки, который тоже подставляется в запрос. Поэтому проверка кода должна охватывать все точки, куда попадает внешний ввод.

Главное средство — параметризованные запросы (подготовленные выражения). Текст запроса и данные передаются раздельно, и база никогда не воспринимает данные как код. Хорошее дополнение — использование ORM с корректной работой, проверка типов и форматов ввода, принцип минимальных привилегий для учётной записи приложения (например, без права удалять таблицы) и скрытие подробных сообщений об ошибках базы.

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

Хорошей практикой служит и разделение окружений: тестовая база не должна содержать реальных данных, а доступ к рабочей базе у приложения ограничивается конкретными таблицами. Тогда даже удачная инъекция получит мало. Автоматические проверки безопасности в процессе разработки ловят типичные ошибки до выпуска.

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

Попытки проверять чужие сайты на уязвимости без разрешения могут нарушать закон. Проверять допустимо свои проекты и учебные стенды, специально созданные для тренировки, а ответственное раскрытие найденных проблем идёт через контакты безопасности владельца.