Безопасность
Security capstone: тест с выбором ответа
Шесть вопросов поперёк всего трека security. Ни один не про заучивание определения — каждый это решение в реальной модели угроз безопасного веб-приложения, где брешь почти всегда живёт в шве между двумя контролями, каждый из которых по отдельности выглядел правильным.
Убедись, что можешь собрать весь трек — контроль доступа, OAuth/OIDC, валидацию JWT, защиту от CSRF, хеширование паролей, секреты и supply chain — в одну модель угроз и сказать, какой слой реально останавливает данную атаку.
Залогиненный пользователь шлёт GET /accounts/{id}/statements с валидным, корректно подписанным JWT, но с чужим id — и читает чужие данные. Какой слой отказал и что чинит?
Твой SPA получает OIDC ID token и access token. Джун подключает API так, что авторизует вызовы, читая claims из ID token. Почему это неправильно?
Пентестер берёт валидный RS256 JWT, меняет header на alg:HS256, ставит role:admin и переподписывает его, используя твой публичный ключ из JWKS как HMAC-секрет — и сервер принимает. Корень причины?
Команда переносит сессионную аутентификацию с JWT в localStorage в HttpOnly-куку, чтобы остановить кражу через XSS. Какую новую брешь это открывает и как её закрыть?
Утечка сдампила твою таблицу users. Какой выбор хранения означает «они получат пару тривиально слабых паролей и сдадутся», а не «всё распространённое взломано к понедельнику»?
Твой код приложения безупречен, но CI компрометируют на npm install: пакет разрешился из публичного реестра с версией 9.9.9 поверх твоего внутреннего. Какой это класс и основная защита?
Сквозная линия всего трека — одна модель угроз: один чувствительный запрос проходит через транспорт, аутентификацию, авторизацию, обработку ввода, секреты и supply chain — и брешь живёт в шве, а не внутри одного слоя. AuthN доказывает «кто»; AuthZ решает, к чему можно прикоснуться (A01). OIDC ID token идентифицирует пользователя, а access token авторизует API, валидируемый по подписи, iss, aud, exp. JWT заслуживает доверия, только когда ты закрепляешь алгоритм. Перенос токена в HttpOnly-куку меняет кражу через XSS на CSRF, закрываемый SameSite плюс токеном. Паролям нужен медленный, солёный, memory-hard KDF. А шаг установки — твоя настоящая поверхность атаки: scope пакетов, закрепи реестр, требуй integrity lockfile.