Уязвимости в фрагменте
query = "SELECT * FROM users WHERE id=" + request.params.id
Кратко:
- Основная — SQL‑инъекция: строковая конкатенация пользовательского ввода в SQL позволяет атакующему подставить произвольный SQL.
- Отсутствие валидации/нормализации ввода — допускает некорректные, многочастные или бинарные полезные нагрузки.
- Возможна эксплойтация через подмену запросов (CSRF) — если это изменение состояния и нет анти‑CSRF мер, злоумышленник может заставить авторизованного пользователя выполнить нежелательный запрос.
- Дополнительно: чрезмерные привилегии БД, отсутствие логирования и мониторинга облегчают последствия.
Как атакуют (конкретные примеры)
- Пример прямой инъекции (получить всех пользователей): request.params.id = "1 OR 1=1" → сгенерируется SQL с условием всегда истинно: $1=1$.
- Пример удаления/модификации: request.params.id = "1; DROP TABLE users; --" — если СУБД позволяет несколько выражений, это может удалить таблицу.
- Blind/Time‑based атаки: request.params.id = "1 AND (SELECT IF(SUBSTRING(password,1,1)='a', SLEEP(5), 0))" — извлечение данных побайтово.
- CSRF: злоумышленник подсовывает форму/скрипт, который отсылает запрос от имени аутентифицированного пользователя — без CSRF‑токена действия выполнятся.
Конкретные исправления
1) Параметризованные (подготовленные) выражения — основное средство:
- SQL: "SELECT * FROM users WHERE id = ?" и привязать параметр как значение, а не конкатенировать.
- Примеры (псевдокод):
- Node.js (mysql):
- query = "SELECT * FROM users WHERE id = ?"; db.query(query, [id], ...);
- Java:
- PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE id = ?");
- ps.setInt(1, id);
- Параметризация нейтрализует инъекции — значения не становятся частью синтаксиса SQL.
2) Типизация и валидация:
- Привести id к целому и проверить диапазон/формат:
- id = parseInt(request.params.id, $10$); проверять на NaN и допустимый диапазон.
- Использовать белые списки (например, только цифры, регулярное выражение) вместо черных списков.
3) Нормализация ввода:
- Unicode‑нормализация (NFKC), trim, ограничение длины.
- Удалять/нормализовать управляющие символы.
4) Минимизация привилегий и защита БД:
- Аккаунт БД для приложения — только необходимые права (SELECT/INSERT/UPDATE нужных таблиц).
- Отключить поддержку множественных выражений, если возможно.
5) CSRF‑защита (если endpoint изменяет состояние или выполняет критичные операции):
- Использовать CSRF‑токены (включать токен в форму/заголовок и проверять на сервере).
- Устанавливать cookie с SameSite=strict/lax, требовать заголовок X‑Requested‑With или проверять Origin/Referer.
- Для API — использовать авторизацию через безопасные токены (Bearer), не полагаться на cookie для безопасных операций.
6) Защита от XSS и CSP:
- CSP заголовок для снижения риска внедрения скриптов: например
- Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'
- Это косвенно уменьшает шанс кражи сессий и подстановки запросов со стороны клиента.
7) Логирование и мониторинг:
- Логи запросов, детектирование аномалий, оповещения при частых ошибках/подозрительных паттернах (повторы попыток инъекции).
Как встроить безопасность в жизненный цикл разработки (SDLC)
- Требования: включить требования безопасности, политики привилегий, требования к валидации ввода и логированию.
- Проектирование: проводить threat modeling для API/эндпоинтов, выбирать архитектуру с принципом «ниже привилегии».
- Реализация:
- Использовать безопасные библиотеки/ORM/параметризованные запросы по умолчанию.
- Стандарты кодирования, чек‑листы безопасности, обучение разработчиков.
- Интеграция в CI/CD:
- SAST (статический анализ) на коммитах, dependency scanning (SCA) для уязвимых библиотек.
- Unit и integration тесты на проверку валидации; тесты на SQL‑инъекции простыми полезными нагрузками.
- Тестирование:
- DAST (динамический анализ), IAST, периодический пентест, fuzzing важных вводов.
- Ввод в эксплуатацию:
- Хранение секретов безопасно, конфигурация CSP, заголовков безопасности (HSTS, X-Content-Type-Options).
- Операции и поддержка:
- Мониторинг, логирование, плана реагирования на инциденты, регулярные патчи и ревью зависимостей.
- Обратная связь:
- Инциденты и результаты тестов используются для обновления стандартов и обучения команды.
Краткий итог
- Немедленно заменить конкатенацию на параметризованные запросы; валидировать и типизировать вход (например, привести id к целому); внедрить CSRF‑защиту и CSP; минимизировать права БД; интегрировать SAST/DAST и проверки безопасности в CI/CD и процесс разработки.