SQL-инъекция и XSS: атаки на веб-приложения

SQL-инъекция (SQL injection, SQLi) — это атака на веб-приложение, при которой злоумышленник внедряет вредоносный SQL-код в поля ввода, чтобы обмануть базу данных и получить, изменить или удалить данные, к которым у него нет доступа. Причина — недостаточная проверка пользовательского ввода: приложение принимает то, что ввёл пользователь, и подставляет это напрямую в текст SQL-запроса, вместо того чтобы обработать как значение, отдельное от кода команды.

Атака возможна везде, где веб-приложение строит SQL-запрос из непроверенного пользовательского ввода: форма логина, поле поиска, параметр в URL, cookie, HTTP-заголовок. Если СУБД выполняет получившийся запрос буквально — включая ту часть, которую туда дописал атакующий, — граница между «данными» и «командой» стирается, и злоумышленник фактически получает возможность выполнять собственные SQL-команды от имени приложения.

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

Классический учебный пример — форма логина, где запрос на сервере собирается конкатенацией строк:

Если приложение подставляет ввод без проверки, а атакующий вместо логина вводит ' OR 1=1 --, итоговый запрос превращается в:

Одинарная кавычка закрывает строковое значение раньше, чем рассчитывал разработчик, условие 1=1 истинно всегда, а -- комментирует остаток строки — в том числе проверку пароля. В результате запрос возвращает первую строку из таблицы пользователей без единой правильной пары логин/пароль, и атакующий заходит под чужой учётной записью.

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

↔ таблицу можно прокрутить вбок

Внутри слепой SQL-инъекции разделяют два приёма: boolean-based — атакующий по очереди задаёт истинные и ложные условия и смотрит, отличается ли ответ страницы (например, показан результат или пустая страница), и time-based — использует функции задержки СУБД, чтобы по времени ответа сервера понять, было условие истинным или нет, даже если содержимое страницы всегда одинаковое.

XSS (Cross-Site Scripting, межсайтовый скриптинг) — это атака, при которой злоумышленник внедряет вредоносный JavaScript-код в веб-страницу, и этот код выполняется в браузере другого пользователя, а не на сервере. Итог для жертвы — кража сессионных cookie и токенов авторизации, перехват вводимых данных, подмена содержимого страницы или выполнение действий от имени жертвы без её ведома.

Причина та же, что у SQL-инъекции — недостаточная проверка и обработка пользовательского ввода, только уязвимое место другое: приложение выводит непроверенные данные (введённые пользователем или взятые из параметра URL) обратно в HTML-страницу, и браузер жертвы интерпретирует их не как текст, а как исполняемый код.

Виды XSS различаются тем, откуда берётся вредоносный код и как он попадает в браузер жертвы:

Ключевое отличие — цель атаки: SQL-инъекция бьёт по базе данных на сервере, XSS — по браузеру и сессии конкретного пользователя. Обе используют один и тот же корневой недостаток — приложение не проверяет и не обрабатывает должным образом пользовательский ввод, — но результат внедрения выполняется в разных средах и с разными последствиями.

↔ таблицу можно прокрутить вбок

Основная защита от SQL-инъекций и XSS находится в коде приложения, а не в отдельном защитном продукте — это параметризация запросов для SQLi и корректная обработка вывода для XSS. Средства сетевой защиты снижают риск дополнительно, но не заменяют исправление уязвимости в самом приложении.

На портале класс WAF — основная техническая защита веб-приложений на сетевом уровне: там же обзор продуктов, которые фильтруют SQLi- и XSS-паттерны в трафике. Отдельная задача — защита API, где та же логика инъекций применима к параметрам запросов и телу JSON-запроса: закрывается классом API Security.

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

Проверить, что эти практики действительно работают на конкретном приложении, позволяет пентест — тестирование на проникновение, которое ищет SQLi, XSS и другие инъекции тем же способом, что и реальный атакующий.

SQL-инъекция и XSS относятся к категории Injection в рейтинге OWASP Top 10 — списке наиболее критичных рисков безопасности веб-приложений, который проект OWASP регулярно обновляет. В версии OWASP Top 10 2021 года эта категория обозначена как A03:2021-Injection и объединяет все атаки, где причина одна и та же — непроверенный пользовательский ввод исполняется как код: SQL-, NoSQL-, OS command-инъекции и, начиная с редакции 2021 года, также межсайтовый скриптинг, который в более ранних версиях рейтинга (2013, 2017) выделялся в отдельную категорию.

Смежная тема, которая не входит в фокус этого материала, — как OWASP Top 10 устроен целиком, какие ещё категории риска в него входят и как рейтинг применяют для приоритизации в собственном проекте безопасной разработки; отдельный разбор всех десяти категорий — на профильной странице словаря OWASP Top 10.