Ниже — краткое, но ёмкое описание распространённых уязвимостей и практические меры защиты на трёх уровнях: код приложения, конфигурация сервера и архитектурные решения.
1) XSS (Cross‑Site Scripting)
- Суть: внедрение и исполнение вредоносного JS в контексте сайта жертвы (хран. / отражённый / DOM‑XSS).
- Риски: похищение сессий, CSRF, фальсификация действий, фишинг.
- Защита в коде:
- Всегда экранируйте вывод в зависимости от контекста (HTML, атрибут, JS, URL). Используйте проверенные функции фреймворка/шаблонизатора.
- Отдавайте только разрешённые данные (whitelist) при парсинге HTML/BBCode; запрещайте raw‑HTML.
- Для динамического вставляемого JS избегайте innerHTML; используйте textContent / safe DOM APIs.
- Устанавливайте флаги cookie: HttpOnly для защищённых от JS куков.
- Защита на уровне сервера/конфигурации:
- Content‑Security‑Policy (CSP) с минимумом источников, предпочительно с nonce/хешами для скриптов.
- X‑Content‑Type‑Options: nosniff.
- Включить проверку входящих данных на WAF.
- Архитектура:
- Разделение фронтенда/бэкенда (API только для данных, UI рендерит с явным кодированием).
- Минимизация доверия к внешним библиотекам, централизованная политика включения скриптов (CDN, подписанные/проверенные пакеты).
2) CSRF (Cross‑Site Request Forgery)
- Суть: злоумышленник заставляет браузер жертвы выполнить авторизованный запрос к приложению.
- Риски: незаметные изменения данных, денежные транзакции, смена пароля и т.п.
- Защита в коде:
- Для state‑changing запросов требуйте CSRF‑токен (synchronizer token) и проверяйте его сервер‑side.
- Для AJAX: использовать заголовки вместе с проверкой Origin/Referer.
- Для форм: скрытые токены и проверка соответствия сессии.
- Защита на уровне сервера/конфигурации:
- Устанавливать cookie флаг SameSite (Lax или Strict) для сессионных куки.
- Проверять заголовки Origin/Referer для критичных операций.
- Архитектура:
- API‑подход с использованием токенов (Bearer, JWT) и CORS: явно ограничить список доверенных origin в Access‑Control‑Allow‑Origin.
- Требовать повторной аутентификации/2FA для высокорискованных действий.
3) SQLi (SQL Injection)
- Суть: подстановка в запросы SQL, обход авторизации, утечка/изменение данных.
- Риски: компрометация БД, удаление/эксфильтрация данных.
- Защита в коде:
- Используйте параметризованные запросы (prepared statements) и ORM API, не формируйте SQL через конкатенацию строк.
- Whitelist валидация для имен столбцов/таблиц; для числовых параметров — строгая типизация.
- Экранирование/валидирование при использовании динамического SQL; избегайте raw SQL, а если необходимо — тщательно параметризуйте.
- Защита на уровне сервера/конфигурации:
- Ограничьте привилегии БД у учётной записи приложения (минимум прав).
- Включите логирование запросов и мониторинг аномалий; WAF с правилом против SQLi.
- Архитектура:
- Разделение прав: разные учётные записи/сущности для чтения и записи, раздельные сервисы.
- Использование хранимых процедур с проверкой входа (но не как единственный механизм защиты).
4) Insecure Direct Object References (IDOR)
- Суть: прямой доступ к объектам (по предсказуемым ID) без проверки прав.
- Риски: просмотр/изменение чужих данных.
- Защита в коде:
- Всегда проверяйте авторизацию/владение ресурса на сервере перед возвратом/изменением объекта.
- Не полагайтесь на скрытые поля в форме или клиентскую логику.
- Используйте непрогнозируемые идентификаторы (UUIDv4 / opaque tokens) в качестве дополнительной меры, но не вместо проверки прав.
- Защита на уровне сервера/конфигурации:
- Лимит доступа к API через ACL, rate limiting и аудит.
- Архитектура:
- Централизованная служба авторизации/ACL, microservice‑gateway, проверяющий права на каждый запрос.
- Модель владения/шаблон проверки доступа (policy enforcement point) — единая реализация проверок.
5) Утечки через заголовки (информационные заголовки)
- Суть: HTTP‑заголовки (Server, X‑Powered‑By, подробные ошибки, CORS) раскрывают версию ПО/стек и дают разведданные злоумышленнику.
- Риски: таргетированные эксплойты, быстрый подбор уязвимостей.
- Защита в коде/сервере:
- Удалить/скрыть заголовки Server, X‑Powered‑By; не выдавать версий ПО.
- Отключить детальные стек‑трэйсы и сообщения ошибок в продакшене; логировать их локально.
- Content‑Security‑Policy, Strict‑Transport‑Security (HSTS), X‑Frame‑Options / frame‑ancestors, X‑Content‑Type‑Options: nosniff, Referrer‑Policy, Permissions‑Policy.
- Для CORS: явно указывать Access‑Control‑Allow‑Origin и избегать wildcard (*).
- Устанавливать cookie флаги Secure, HttpOnly, SameSite.
- Архитектура:
- Через API‑gateway/edge реализовать центральную политику заголовков и скрытие серверных деталей.
- CDN и WAF как первый уровень фильтрации и маскировки бекенда.
Дополнительные общие меры (все уровни)
- Валидация на белом списке и строгая типизация входных данных.
- Защита секретов: хранение в vault, переменные окружения, минимизация доступа.
- Принцип наименьших привилегий для сервисных аккаунтов и БД.
- Логирование и мониторинг (алерты на аномалии, IDS/WAF).
- Регулярное тестирование: SAST/DAST, пен‑тесты, ревью кода, зависимостей (SCA).
- Обновления и патчи; управление уязвимостями.
- Обучение разработчиков: безопасные практики, шаблоны и библиотеки для общего использования.
- «Defense in depth»: многослойные контрмеры (код, конфиг, сеть), чтобы сбой на одном уровне не приводил к компрометации.
Короткий чек‑лист внедрения (практический порядок):
1) Внедрить параметризованные запросы и централизованную проверку прав.
2) Включить CSP, HSTS, X‑Content‑Type‑Options, Referrer‑Policy, скрыть Server/X‑Powered‑By.
3) Реализовать CSRF‑токены + SameSite cookies + Origin/Referer проверки.
4) Настроить WAF, мониторинг и логирование инцидентов.
5) Провести SAST/DAST и пен‑тест, исправить критичные находки.
Если нужно, могу дать короткие примеры кода (например, подготовленные запросы в конкретном языке, CSP‑политику или проверку владельца ресурса).