Ниже — концентрированный, но детальный обзор типичных уязвимостей, практических мер защиты и компромиссов между безопасностью и удобством. Числа и параметры указаны явно.
1) Общая методика
- Принцип защиты по слоям (defense in depth): валидация на клиенте + строгое проверка/ограничения на сервере + мониторинг/логирование + WAF/IDS.
- Прайвеси/минимизация данных: хранить минимум, шифровать чувствительное.
2) SQL‑инъекции
- Уязвимость: динамическая конкатенация SQL с данными пользователя.
- Защита:
- Параметризованные запросы / prepared statements / ORM с bind параметрами (никогда не форматировать строки).
Пример: `SELECT * FROM users WHERE email = ?` (bind email).
- Белый список разрешённых идентификаторов/полей при динамической генерации SQL.
- Минимизация прав БД (каждое приложение — отдельный пользователь БД с минимумом привилегий).
- Регулярные аудиты и тестирование (DAST/SAST, sqlmap в тестовой среде).
- Компромисс: полностью избегать динамического SQL сложнее при гибких фильтрах/фичах → нужно шаблонизировать и валидировать входы.
3) Хранение паролей
- Нельзя: хранить в открытом виде, или с простой хеш‑функцией (MD5,SHA1,SHA256 без соли и адаптивности).
- Должно быть:
- Современный адаптивный KDF: Argon2id предпочтительнее; допустимы bcrypt/scrypt при корректных параметрах.
- Уникальная соль на пароль (per‑user salt) + возможно глобальный pepper (секрет вне БД, хранится в KMS).
- Пример рекомендуемых параметров Argon2id: память = $64\text{MiB}$, итерации = $3$, параллелизм = $4$. (Подберите под ваше железо; тестируйте время хеширования ~$100\text{–}500\text{ms}$ на целевом сервере.)
- Бэкап и миграция хешей: версия хеша в записи, при входе обновлять параметры.
- Компромисс: сильные параметры ухудшают UX (долгая регистрация/логин) и нагрузку. Решение: балансируйте время хеширования и нагрузку; можно использовать аппаратный KDF изолированно или очереди для пиков.
4) Аутентификация и управление сессиями
- Парадигмы:
- Сессионная серверная аутентификация (stateful): простой контроль, лёгкое принудительное аннулирование сессий.
- Токены/JWT (stateless): масштабируемо, но сложнее с ревокацией и безопасным хранением.
- OAuth2/OpenID Connect — для SSO; FIDO2/WebAuthn — для passwordless/MFA без пароля.
- Рекомендации:
- При cookie: ставить флаги `Secure`, `HttpOnly`, `SameSite=Strict`/`Lax` в зависимости от сценария.
- На успешный логин — регенерировать идентификатор сессии.
- Короткая продолжительность жизни access token (например $15\text{мин}$), долгие refresh token с безопасным хранением и rotation.
- Хранить refresh token в HttpOnly cookie или в безопасном хранилище; при использовании SPA избегать хранения токенов в localStorage.
- Для JWT: использовать короткий срок жизни access token; при необходимости — reference tokens (хранить на сервере) для возможности ревокации.
- Компромисс: короткие сессии и частая реаутентификация повышают безопасность, ухудшают UX; MFA добавляет защиту, но отпугивает часть пользователей.
5) XSS (Cross‑Site Scripting)
- Уязвимость: вставка пользовательского ввода в HTML/JS без экранирования.
- Защита:
- Контекстно‑чувствительное экранирование при выводе: HTML‑текст, атрибуты, URL, JavaScript, CSS — разные правила.
- Использовать фреймворки/шаблонизаторы с авто‑экранированием (React, Angular, Twig и т.д.).
- Content Security Policy (CSP) с минимально необходимыми источниками; исп. nonce/sha‑256 для inline скриптов.
- Избегать innerHTML / eval / document.write; при необходимости — безопасная парсинг/санация (DOMPurify).
- HttpOnly cookie для токенов чтобы XSS не мог украсть их.
- Компромисс: строгий CSP и отказ от inline скриптов усложняют интеграцию трекинга/сторонних скриптов.
6) CSRF (Cross‑Site Request Forgery)
- Уязвимость: нежелательные state‑changing запросы, инициированные с другого сайта.
- Защита:
- Для stateful apps: CSRF‑токены (одноразовые/сессия) + проверка для небезопасных методов (POST/PUT/DELETE).
- Использовать SameSite cookies (`Lax`/`Strict`) — устраняет многие CSRF.
- Для REST APIs — требовать авторизации через заголовки (Authorization bearer), CORS с белым списком, и проверять Origin/Referer.
- Double submit cookie как альтернатива: сравнить токен в cookie и в теле/заголовке.
- Компромисс: строгая политика CORS и проверка реферера могут ломать легитимные интеграции; нужно документировать и предусмотреть whitelisting.
7) Insecure Direct Object References (IDOR) / Broken Access Control
- Защита:
- Авторизация на каждой критической операции (never trust client).
- Использовать непрямые идентификаторы (UUIDs, хэши) + проверять права доступа в бизнес‑логике.
- Принцип наименьших привилегий на уровне API/БД.
- Компромисс: строгие проверки добавляют латентность и усложняют код — нужно хорошее тестирование.
8) Insecure deserialization, RCE, SSRF, file upload
- Защита:
- Не десериализовать данные от клиентов без проверки; использовать безопасные форматы (JSON) и валидаторы.
- Для загрузки файлов: проверять тип через содержимое (MIME), ограничивать расширения, хранить вне webroot, переименовывать файлы, сканировать антивирусом.
- Валидация URL перед fetch/подключением; черные/белые списки для SSRF.
- Компромисс: безопасная обработка файлов и сетевых ресурсов требует дополнительной инфраструктуры.
9) TLS и общая конфигурация
- TLS 1.2+ (предпочтительно TLS 1.3), HSTS, отказ от слабых шифров и протоколов.
- Сертификаты от доверенных CA, автоматическое обновление (Let's Encrypt + ACME).
- Компромисс: строгие настройки могут препятствовать старым клиентам/интеграциям.
10) Логирование, мониторинг и реагирование
- Централизованный лог: аутентификация, неудачные попытки, привилегированные операции, изменения прав.
- SIEM/alerting, anomaly detection, rate limiting и авто‑блокировки (с учётом false positives).
- Incident response план и регулярные упражнения.
- Компромисс: агрессивный мониторинг может собрать много данных и повлиять на конфиденциальность; балансировать ретеншн логов и доступ.
11) CI/CD и зависимостями
- Подпись/проверка артефактов, сканирование зависимостей (Snyk, Dependabot), пиннинг версий, ограничение доступа к секретам.
- Изолированные окружения, принудительные code review и SAST в пайплайне.
12) Конкретные практические рекомендации «to‑do»
- Везде использовать параметризованные запросы/ORM; аудит динамических SQL.
- Хеширование паролей: Argon2id с настраиваемыми параметрами (см. выше). Солить и опционально pepper.
- Реализовать MFA (по крайней мере TOTP) для привилегированных аккаунтов.
- Cookies: `Secure`, `HttpOnly`, `SameSite`.
- CSP + контекстное экранирование + избегать inline JS.
- CSRF: токены + SameSite.
- JWT: короткая жизнь access token, refresh rotation, хранить refresh в HttpOnly cookie.
- Тесты: регулярный pentest, SAST/DAST, dependency scan.
- План на случай компрометации: откат ключей, аннулирование сессий, уведомления пользователей.
13) Компромиссы (суммирование)
- Безопасность vs удобство: более строгие политики (MFA, короткие сессии, CSP) повышают защиту, снижают удобство/сложнее интеграции. Решение — риск‑ориентированный подход: критичные операции требуют дополнительной проверки; low‑risk — упрощённый поток.
- Стоимость/время разработки: некоторые меры требуют значительных изменений (контекстное экранирование, CSP) — вводите поэтапно, покрывая сначала критичные пути.
- Производительность: сильное хеширование и глубокие проверки замедляют операции — нужно масштабирование и бенчмаркинг.
Если нужно, могу:
- предложить конкретные параметры Argon2id, bcrypt для вашего окружения (укажите целевой CPU/RAM и требуемую задержку),
- составить чек‑лист для ревью кода/CI,
- или дать образцы конфигураций CSP, cookie и заголовков.