Защита от SQL-инъекций и XSS-атак: ревью кода, исправление и тесты, которые не дают ошибке вернуться

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

Почему ручное экранирование не метод

• Правила зависят от контекста. Строка, числовое поле, имя столбца и значение внутри шаблона экранируются по-разному, и одна функция на все случаи не подходит.
• Фильтр на входе защищает одно место. Данные приходят ещё из файлов, обмена с другими системами и из самой базы. Защита должна стоять там, где строится запрос, а не у двери.
• Чёрные списки обходятся. Запретить слова и символы нельзя: законное имя клиента или наименование товара может содержать любые из них.

Что ещё входит в защиту базы

• Права учётной записи приложения. Приложение не владеет схемой и не умеет менять структуру таблиц; миграции идут под отдельной учётной записью. Тогда успешная инъекция даёт меньше.
• Тексты ошибок. Подробности ошибки базы пишутся в журнал, пользователь видит общее сообщение. По тексту ошибки злоумышленник узнаёт устройство базы.
• Соседние случаи. Тот же принцип у документных баз, LDAP и команд операционной системы: данные отдельно, команда отдельно.
• ORM помогает, но не решает. Обычные методы безопасны, а «сырые» вставки, форматирование строк и передача условий целиком возвращают проблему.

Мы ищем в вашем коде обходы защиты, они хорошо видны поиском:

• Явные «сырые» выводы. Прямая вставка разметки в React и Vue, фильтры и метки «безопасно» в Django и Jinja, обход проверки в Angular. Каждое место либо убирается, либо получает санитайзер.
• Работа с деревом страницы вручную. Присваивание готовой разметки через innerHTML, вставка из адресной строки и из сообщений между окнами. Такие участки переписываются на безопасные методы, которые вставляют текст, а не разметку.

Чужой код на вашей странице

Метрика, чат-виджет и скрипт рекламной сети исполняются с теми же правами, что и ваш код. Если их владелец взломан, вы получаете XSS без единой уязвимости у себя. Мы составляем перечень внешних скриптов, убираем лишние, для статических файлов с чужих серверов включаем проверку целостности и ограничиваем разрешённые источники политикой CSP.

Межсетевой экран для веб-приложений (WAF) фильтрует подозрительные запросы снаружи. Он полезен как временная мера, пока исправление в очереди, но обход фильтра находят, а ошибка в коде остаётся. Мы чиним причину. Настройка и эксплуатация WAF как услуга в наш перечень не входит.

Если приложение ещё не проверялось вообще, начинают с аудита безопасности: он покрывает все десять классов, а инъекции и XSS в нём лишь два пункта. Если известно, что проблема именно здесь, подойдёт эта проверка.Защита входа и прав описана на странице SSO и MFA, защита самого API от перебора и чужих запросов — на странице защиты API.