Ниже — сжатый, но полный перечень уязвимостей и конкретных технических мер/политик для проверки и внедрения для формы авторизации.
1) Уязвимости, которые нужно проверять
- SQL‑инъекции (включая NoSQL) — влияние на аутентификацию/пользовательские данные.
- XSS (отображаемое/хранимое/DOM) — кража учётных данных/токенов.
- CSRF / Login CSRF — нежелательная аутентификация или смена состояния.
- Брутфорс / перебор паролей / credential stuffing.
- Утечка/слабое хранение паролей (plaintext, слабые хеши).
- Тайминг‑атаки и побочные каналы при сравнении паролей.
- Сессии и фиксация сессий, украденные/недавно скомпрометированные токены.
- Недостаточная защита восстановления пароля (токены малой энтропии, длинный срок жизни).
- Account enumeration (различные ответы при наличии/отсутствии пользователя).
- Clickjacking (iframe атаки).
- Open redirect (фишинговые переадресации).
- Неправильная конфигурация TLS/несовременные версии протоколов.
- Уязвимости сторонних библиотек/зависимостей.
- Логирование секретов (паролей, токенов) в открытом виде.
- MFA слабости / обходы (SIM swapping, устаревшие OTP методы).
2) Технические меры (код + конфигурация)
- Ввод/обработка данных:
- Всегда использовать параметризованные запросы / prepared statements / ORM-парадигмы — запретить конкатенацию SQL.
- Для NoSQL — использовать безопасные API и whitelist параметров.
- Валидировать и нормализовать вход (whitelist), минимально доверять клиенту.
- Экранировать/контекстно-санитизировать вывод для предотвращения XSS.
- Защита от CSRF:
- Генерировать и проверять CSRF‑токены для state‑changing форм; для логина — рекомендован CSRF‑токен или SameSite cookie.
- Устанавливать cookie с атрибутом SameSite=$\text{Strict}$ или $\text{Lax}$ по ситуации.
- Транспорт:
- Обязательный HTTPS/TLS: поддержка TLS $\ge 1.2$ (предпочтительны TLS $1.3$).
- HSTS заголовок, включая preload.
- X‑Content‑Type‑Options: nosniff; X‑Frame‑Options: DENY; Referrer‑Policy; Content‑Security‑Policy (минимум — запрет inline скриптов).
- Хранение паролей:
- Использовать адаптивные хеши: Argon2id / bcrypt / scrypt. Пример Argon2id параметры: память $=64\text{MB}$, итерации $=3$, параллелизм $=4$ (подбирать по устройствам).
- Никогда не хранить пароли в логах/в виде plaintext.
- Аутентификация и сессии:
- Генерация сессионных идентификаторов с криптостойкой энтропией; регенерация id после входа/повышения привилегий.
- Установить cookie: HttpOnly, Secure, SameSite.
- Ограничить время жизни сессии: таймаут бездействия ~ $15\text{min}$, абсолютная длительность ~ $24\text{h}$ (настраивать в зависимости от риска).
- Для SPA/API использовать короткоживущие access токены (например $\le 15\text{min}$) и защищенные refresh токены с ротацией.
- Для JWT: проверять подпись, issuer, audience, срок годности; использовать безопасные алгоритмы (RS256/ES256) и короткие lifetimes.
- Против брутфорса и перебора:
- Rate limiting: по IP и по учётной записи; порог e.g. блок/замедление после $5$ неудачных попыток (или progressive delays).
- Привязка лимитов: IP, account, device fingerprint.
- После нескольких неудачных попыток вводить CAPTCHA/многофакторную проверку; временная блокировка $15\text{min}$ или прогрессивная.
- Защита от credential stuffing: проверять пароли по спискам утёкших (k‑Anonymity HIBP) при регистрации/смене пароля.
- Восстановление пароля:
- Токены восстановления — криптографически случайные, энтропия $\ge 128\text{bits}$, одноразовые, срок жизни $\le 1\text{hour}$ (обычно $15\text{–}60\text{min}$).
- Лимит запросов восстановления; не выдавать информацию о существовании учётной записи.
- MFA:
- Рекомендовать/обязывать MFA: TOTP (RFC6238) и FIDO2/WebAuthn. SMS — только как fallback.
- Защита UI и клиенской стороны:
- CSP без 'unsafe-inline', nonce/хэшы для допустимых скриптов.
- Минимизировать динамический HTML на странице логина; не вставлять пользовательские значения без обработки.
- Против тайминг‑атак:
- Использовать constant‑time сравнение для токенов/хэшей.
- Логи и мониторинг:
- Логировать попытки входа (IP, user agent, timestamp, причина отказа) без записи паролей/токенов.
- Настроить алерты на аномальные паттерны (всплески неудачных логинов, массовые создания аккаунтов).
- Управление ключами и секретами:
- Хранить секреты в безопасном хранилище (KMS/secret manager), ротация ключей по политике.
- Тестирование и процессы:
- Регулярный SAST/DAST, dependency scanning, pentest, threat modeling.
- Процесс реагирования на инциденты и уведомлений пользователей о подозрительной активности.
- Политика минимальных прав доступа в кодовой базе/инфраструктуре.
- API/ОAuth/OIDC:
- Использовать PKCE для публичных клиентов; проверять state параметр; ограничивать redirect_uris; валидировать параметры.
- Ротация refresh токенов, возможность отзыва сессий/токенов.
3) Политики и UX/соответствие
- Политика паролей: минимум длина $\ge 12$ символов; не навязывать чрезмерную сложность (лучше длину/фразовую политику); блокировать широко использующиеся/утёкшие пароли.
- Пассивный и активный мониторинг: alerting при массовых неудачных попытках и при логинах из новых гео/устройств.
- Сообщения об ошибках: унифицированные, не раскрывают наличие пользователя (например «Неверный логин или пароль»).
- Обучение пользователей: рекомендовать MFA, безопасное поведение, уведомления о новых входах.
- Соблюдение регуляций (GDPR/PCI/другие): минимизация хранения данных, уведомление о компрометации.
4) Проверки/тесты для формы авторизации
- Автоматизированный SAST/DAST, ручной pentest на SQLi/XSS/CSRF/IDOR.
- Тесты на brute‑force (rate limiting), token entropy, session fixation и время жизни.
- Проверка заголовков безопасности (CSP, HSTS, X‑Frame‑Options и т.д.).
- Проверка хранилища паролей и параметров хеширования.
- Проверка восстановления пароля (токены, срок, одноразовость).
- Проверка логирования (отсутствие секретов).
- Ревью конфигураций TLS и библиотек (уязвимости зависимостей).
Краткий чеклист для развертывания (минимум):
- HTTPS/TLS включён (TLS $\ge 1.2$), HSTS;
- Пароли хранятся через Argon2id/bcrypt;
- CSRF‑токены + SameSite cookie;
- HttpOnly + Secure cookie;
- Rate limiting + CAPTCHA/progressive lockout;
- MFA доступно/рекомендовано;
- Токены восстановления одноразовые + срок $\le 1\text{hour}$;
- CSP + X‑Frame‑Options + X‑Content‑Type‑Options;
- Логи без секретов + мониторинг/алерты;
- Регулярное тестирование (SAST/DAST/pentest).
Если нужно — могу дать конкретные конфигурации (пример CSP, пример заголовков, пример кода проверки CSRF, параметры Argon2id) — скажите, что хотите увидеть.