Перечисляю наиболее распространённые уязвимости, кратко — как обычно эксплуатируются (высокоуровнево, без пошаговых «payload‑ов») и подробные меры по исправлению/смягчению (включая подготовленные выражения, экранирование, CSP и др.).
1) SQL‑инъекция (SQLi)
- Суть: неподготовленные SQL‑запросы с включением непроверённых данных пользователя.
- Как эксплуатируют (в общих чертах): злоумышленник подставляет специально сформированные данные в поля/параметры, чтобы изменить структуру запроса и получить/изменить данные.
- Исправление:
- Использовать параметризованные запросы / подготовленные выражения (prepared statements) для всех запросов с внешними данными; пример концепции: `SELECT * FROM users WHERE id = ?`.
- Применять ORM с безопасной параметризацией либо безопасные API драйверов БД.
- Минимизировать привилегии учётной записи БД (принцип наименьших привилегий).
- Валидировать и нормализовать вход (whitelist для чисел/ID/форматов).
- Ограничивать подробность ошибок (не возвращать стек/SQL‑ошибки пользователю).
- Внедрить мониторинг и WAF как дополнительный слой защиты.
2) Межсайтовый скриптинг (XSS: reflected, stored, DOM)
- Суть: внедрение/выполнение небезопасного JS/HTML в контексте страницы.
- Как эксплуатируют: вставка скриптов в поля/URL/данные, которые потом рендерятся в браузере других пользователей.
- Исправление:
- Всегда кодировать (escape) вывод по контексту: HTML‑энкод для текста в теле, атрибут‑энкод для значений атрибутов, JS‑энкод для вставок в скрипты, URL‑энкод для вставок в URL.
- Использовать шаблонизаторы/фреймворки с автоматическим экранированием.
- Для динамического HTML предпочтать вставку данных через безопасные DOM‑API (textContent, setAttribute), а не через innerHTML.
- Политика CSP: запретить inline‑скрипты и неизвестные источники, пример (рекомендация): `Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-'; object-src 'none'; frame-ancestors 'none'; base-uri 'self';` (используйте nonce или hash для разрешённых inline‑скриптов).
- HttpOnly и Secure флаги для куки, SameSite для защиты от утечки через сторонние запросы.
- Валидация входа и ограничение допустимых форматов/размеров данных.
3) Межсайтовая подделка запросов (CSRF)
- Суть: браузер выполняет авторизованные действия по запросу, инициированному другим сайтом.
- Как эксплуатируют: отправка формы/запроса от имени жертвы, если браузер автоматически посылает куки.
- Исправление:
- Применять постоянные или одноразовые CSRF‑токены (сравнивать серверная сессия ↔ поле формы/заголовок).
- Требовать двойную отправку токена (например, в теле формы и в заголовке).
- Устанавливать для сессионных куки `SameSite=Lax`/`Strict` где возможно; HttpOnly/Secure.
- Для API — требовать авторизацию через заголовок (Bearer token), не через куки.
4) Неправильная настройка контроля доступа / Broken Access Control
- Суть: пользователи получают доступ к объектам/функциям без проверки прав.
- Как эксплуатируют: подмена ID в URL, прямой доступ к API/ресурсам без проверки прав.
- Исправление:
- Реализовать централизованную проверку прав (server‑side) для каждого запроса/эндпойнта.
- Не полагаться на клиентскую фильтрацию; проверять владельца ресурса (owner checks) и роли.
- Принцип наименьших привилегий, RBAC/ABAC, утверждённые политики.
- Логи доступа и тесты на обходы прямых ссылок (IDOR).
5) Инъекция команд / RCE / Command injection
- Суть: выполнение системных команд/кодa из данных пользователя.
- Как эксплуатируют: вставка команд в параметры, которые передаются shell/интерпретатору.
- Исправление:
- Избегать вызовов shell; использовать безопасные API библиотек.
- Если нужно вызывать внешние программы — передавать аргументы как массив (no shell), избегать конкатенации строк.
- Валидация/white‑list параметров, ограничение прав процесса, контейнеризация, sandboxing.
- Мониторинг и ограничение ресурсов.
6) Небезопасная десериализация
- Суть: десериализация данных, содержащих указание на выполнение кода/создание объектов.
- Как эксплуатируют: формирование данных, которые при десериализации вызывают выполнение нежелательного кода.
- Исправление:
- Избегать десериализации от недоверенных источников.
- Использовать безопасные форматы (JSON) и строгие схемы/валидацию.
- Включить allowlist допустимых типов объектов; запретить произвольные классы.
- Применять статический анализ, патчи и обновления библиотек.
7) Утечка чувствительных данных / Sensitive Data Exposure
- Суть: хранение/передача секретов/персональных данных в открытом виде или слабо защищённо.
- Как эксплуатируют: перехват трафика, компрометация БД/бэкапов, слабое шифрование.
- Исправление:
- TLS для всего трафика; HSTS.
- Шифрование данных в покое (используйте проверенные алгоритмы и управление ключами).
- Не хранить секреты в репозиториях; использовать секрет‑менеджеры.
- Маскирование/минимизация логируемых данных.
- Политики ротации ключей и парольная политика.
8) Использование уязвимых компонентов / Vulnerable Dependencies
- Суть: сторонние библиотеки/пакеты с известными уязвимостями.
- Как эксплуатируют: известные CVE/эксплойты для старых версий.
- Исправление:
- Автоматический SCA/сканирование зависимостей (Dependabot, Snyk и т.д.).
- Регулярные обновления и бэкапы.
- Минимизация используемых компонентов, аудит лицензий и кода.
9) Неправильная конфигурация безопасности / Security Misconfiguration
- Суть: оставленные debug‑режимы, открытые админ‑панели, незащищённые заголовки.
- Как эксплуатируют: доступ к отладочной информации, административным страницам, открытые порты.
- Исправление:
- Убрать debug/verbose в prod, закрыть ненужные порты, минимальные сервисы.
- Включить безопасные HTTP‑заголовки: `Content-Security-Policy`, `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, `Referrer-Policy`.
- Регулярные конфигурационные ревью и автоматизированные проверки.
10) SSRF (Server‑Side Request Forgery)
- Суть: сервер выполняет HTTP/FTP/SMTP‑запросы по URL, поставленным пользователем, и злоумышленник заставляет сервер обращаться к внутренним ресурсам.
- Используют: подставляют URL на внутренние IP/сервисы.
- Исправление:
- Валидировать и разрешать только whitelisted хосты/диапазоны.
- Ограничить исходящие сетевые вызовы, использовать прокси с фильтрацией.
- Установить таймауты и лимиты; логировать исходящие запросы.
11) Неправильная обработка загрузки файлов
- Суть: загрузка вредоносных файлов, обход проверки типа/расположения.
- Используют: загрузка скриптов, последующий вызов их как кода.
- Исправление:
- Проверять MIME‑тип и расширение, но основываться на server‑side/инспекции содержимого (magic bytes).
- Сохранять файлы вне корня веб‑сервера, отдавать через прокси/контроллер с проверкой.
- Устанавливать ограничения на размер, антивирусную проверку, генерировать уникальные имена, обеспечить права доступа.
12) Логирование и мониторинг (Insufficient Logging & Monitoring)
- Суть: отсутствие или недостаточность логов и оповещений, затрудняет обнаружение атак.
- Исправление:
- Логировать аутентификацию, ошибки, привилегированные действия; централизовать логи.
- Настроить алерты на аномалии (много неудачных логинов, всплески трафика).
- Сохранять логи достаточно долго для расследования, защищать их от изменения.
Рекомендации по общим практикам (процедуры, политики, инструменты)
- Безопасная разработка: SAST/DAST интегрированы в CI/CD, code review с фокусом безопасности, threat modelling.
- Политика Content Security Policy: использовать «директивы по умолчанию» и минимальные разрешения; применять nonce/hash для контролируемых inline‑скриптов; пример шаблона: `Content-Security-Policy: default-src 'none'; script-src 'self' 'nonce-...'; style-src 'self' 'nonce-...'; img-src 'self' data:; object-src 'none'; frame-ancestors 'none'; base-uri 'self';` — адаптировать под приложение.
- Экранирование по контекстам: HTML entity encoding, attribute encoding, JS string encoding, URL encoding, CSS encoding — выбирать кодирование согласно месту вставки данных.
- Подготовленные выражения для БД: всегда параметры вместо конкатенации; для NoSQL — использовать API‑методы, не строить запросы строкой.
- Политики доступа: RBAC/ABAC, централизованная авторизация, аудит прав.
- Управление секретами: vault/secret manager, ротация, ограничение доступа.
- Обновления и управление уязвимостями: регулярные сканы, тестирование перед релизом, план реагирования на инциденты.
- Минимизация поверхности атаки: отключать ненужные функции/эндпойнты, минимальный набор библиотек.
Если нужно, могу сгенерировать конкретную чек‑лист‑таблицу (для аудита) или примеры безопасного кода (параметризованные запросы в конкретном языке, примеры правильного экранирования и CSP) — укажите стек/язык/фреймворк.