AAA и экзотика: токены, 0-day, DDoS

Senior-уровень безопасности это уже не “не забыть экранировать вывод”, а системное мышление. Сначала закрываем третью A в AAA, accounting, потом смотрим на атаки, которые не лечатся одним заголовком: баги OAuth, 0-day и DDoS.

Идея: безопасность это не точка, а процесс

У системы нет состояния “защищено”. Есть постоянная гонка: появляются новые уязвимости, обновляются зависимости, меняется код. Поэтому зрелая защита это не финальный чеклист, а способность заметить атаку и отреагировать. А чтобы заметить, нужен accounting: без записи о том, что происходило, расследовать нечего и инцидент проходит незамеченным (это тот самый OWASP A09, Logging and Monitoring Failures).

Accounting и аудит

Третья A замыкает связку. Authentication знает, кто ты. Authorization решает, что тебе можно. Accounting записывает, что ты на самом деле сделал.

Что логировать в audit log: вход и выход, смену прав и ролей, доступ к чувствительным данным, мутации важных ресурсов, отказы в доступе. На каждое событие пишут кто (субъект), что (действие), над чем (ресурс), когда, откуда (IP, user-agent) и результат.

Ключевые свойства правильного аудита:

• Неизменяемость: журнал только дописывается. Если атакующий может затереть свои следы, аудита фактически нет. Часто это отдельное хранилище, куда у приложения есть право только на запись.
• Корреляция: сквозной trace id, чтобы собрать одно действие через все сервисы.
• Отделять audit log от обычных логов приложения и не складывать туда секреты и персональные данные сверх необходимого.

Это прямо смыкается с observability из микросервисов (см. урок Observability): те же логи, метрики и трейсы, только прочитанные через призму безопасности. Аномалия в метриках (всплеск 401, странный географический паттерн логинов) часто первый сигнал атаки.

Баги OAuth и token fixation

OAuth мощный, но реализация полна тонких ошибок, и почти все они на стороне сервера, который не проверил то, что обязан. Базовую механику OAuth и JWT мы разбирали в уроке OAuth2 и JWT, здесь про классы багов.

• Token fixation: атакующий навязывает жертве заранее известный идентификатор, а после логина пользуется им. Лечится регенерацией сессии и токена при каждом логине и повышении привилегий.
• Open redirect в redirect_uri: сервер пускает код на чужой адрес. Лечится точным сопоставлением redirect_uri с заранее зарегистрированным значением, без частичных совпадений и вайлдкардов.
• Утечка кода через Referer: код в URL улетает на сторонние ресурсы в заголовке Referer. Лечится одноразовостью кода и PKCE.

Главная современная защита это PKCE: клиент привязывает код авторизации к секрету, который знает только он, так что перехваченный код бесполезен. Для публичных клиентов (SPA, мобильные) он обязателен. Все эти правила собраны в RFC 9700, это первое, что стоит прочитать перед своей OAuth-интеграцией.