Аутентификация и защита в Java

стоимость  4:    6 мс
стоимость  8:   20 мс
стоимость 10:   75 мс
стоимость 12:  295 мс

один пароль, два хеша:
  $2a$10$MOekS8x00CK.jNRyuC856eQNbTnuoH34dp2oWI2xzIkTfunLPbTiG
  $2a$10$hWIuM9lthkGitdIjDkK3luCHJ1RJooKrxmhirvaKu1QCz2F0hWCKi
оба проходят проверку

токен: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiw...

средняя часть, декодированная без ключа:
  {"sub":"user-42","role":"ADMIN","exp":1800000000}

подделка с другой ролью: подпись НЕ совпала с ожидаемой

// склейка строк:
select login, secret from users where login = 'нет' or '1'='1'
//   вернулось 2 строки: anna/обычный  admin/ядерные коды

// параметр:
ps.setString(1, "нет' or '1'='1");
//   вернулось 0 строк

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 17, остальные разбираются в тренажёре.

1. #security_auth1 / 5
   Что представляет собой JWT (JSON Web Token) и как он устроен?

   A)Зашифрованный файл на сервере, где хранится сессия пользователя, а клиенту выдаётся ссылка на него

   B)Три части (header.payload.signature) в base64url; подпись подтверждает целостность

   C)Случайный идентификатор сессии, по которому сервер каждый раз ищет данные пользователя в своей базе

   D)Пара логин-пароль, закодированная в base64 и передаваемая в каждом запросе для повторного входа

   показать ответ и разбор

   +B)Три части (header.payload.signature) в base64url; подпись подтверждает целостность

   // разбор: JWT — самодостаточный токен из трёх частей через точку: HEADER (алгоритм/тип), PAYLOAD (claims: кто пользователь, роли, срок жизни exp, издатель) и SIGNATURE. Всё закодировано base64url (это НЕ шифрование — payload читается любым!), а ПОДПИСЬ (HMAC секретом или RSA-парой) позволяет серверу проверить, что токен ВЫДАН ИМ и НЕ ИЗМЕНЁН, не обращаясь к БД. Отсюда его сила — STATELESS аутентификация: вся нужная информация в самом токене. Отсюда и правила: не класть в payload секреты (он читаем), обязательно ставить срок жизни, проверять подпись/exp/issuer.

2. #security_auth2 / 5
   В чём главный компромисс stateless JWT по сравнению с серверной сессией?

   A)JWT занимает меньше места, чем session id, поэтому его передача быстрее и безопаснее сессии

   B)JWT хранится на сервере, а сессия — на клиенте, поэтому JWT проще отозвать в нужный момент

   C)Не нужен серверный стор (масштабируется), но токен трудно отозвать до истечения срока

   D)JWT работает только по HTTP, а серверные сессии — только по HTTPS, в этом их основное различие

   показать ответ и разбор

   +C)Не нужен серверный стор (масштабируется), но токен трудно отозвать до истечения срока

   // разбор: Серверная сессия: сервер хранит состояние (session store), клиент носит короткий session-id (кука) — легко ОТОЗВАТЬ (удалить сессию), но нужен общий стор и «липкость»/репликация при масштабировании. Stateless JWT: состояние в самом токене, сервер лишь проверяет подпись — не нужен серверный стор, любой инстанс валидирует токен сам (отлично для горизонтального масштаба/микросервисов). Плата: токен ДЕЙСТВИТЕЛЕН до exp, и мгновенно ОТОЗВАТЬ его трудно (он не хранится на сервере) — при компрометации/логауте нужны обходы: короткий TTL + refresh-токены, чёрные списки, версия ключа. Выбор — масштабируемость против управляемости отзыва.

3. #security_auth3 / 5
   Что такое CORS и какую задачу он решает?

   A)Способ шифрования запросов между разными доменами, заменяющий собой протокол HTTPS для API

   B)Ограничение частоты запросов с одного адреса, защищающее сервер от чрезмерной нагрузки (rate limit)

   C)Механизм кэширования ответов сервера на стороне браузера для ускорения повторных обращений к API

   D)Механизм, разрешающий браузеру кросс-доменные запросы через заголовки сервера (в обход same-origin)

   показать ответ и разбор

   +D)Механизм, разрешающий браузеру кросс-доменные запросы через заголовки сервера (в обход same-origin)

   // разбор: Браузеры по умолчанию соблюдают SAME-ORIGIN POLICY: JS со страницы одного origin (протокол+домен+порт) не может свободно читать ответы запросов к ДРУГОМУ origin. CORS (Cross-Origin Resource Sharing) — механизм, которым СЕРВЕР через заголовки (Access-Control-Allow-Origin и др.) ЯВНО разрешает браузеру такие кросс-доменные запросы. Для «непростых» запросов браузер сначала шлёт preflight (OPTIONS). Важно: CORS — это браузерная защита; серверные клиенты (curl, другой бэкенд) её не соблюдают, поэтому CORS НЕ заменяет аутентификацию/авторизацию. Типичная ошибка — путать «ошибку CORS» в консоли с проблемой сервера, хотя настраивается она на сервере.

4. #security_auth4 / 5
   Как правильно хранить пароли пользователей в БД?

   A)Хешировать медленным адаптивным алгоритмом с солью (bcrypt/argon2), не хранить в открытом виде

   B)Хранить в открытом виде, но в отдельной защищённой таблице с ограниченным доступом по паролю админа

   C)Шифровать симметричным ключом, чтобы при необходимости можно было расшифровать и показать пользователю

   D)Хешировать быстрым MD5 или SHA-1 без соли — этого достаточно для защиты учётных данных пользователей

   показать ответ и разбор

   +A)Хешировать медленным адаптивным алгоритмом с солью (bcrypt/argon2), не хранить в открытом виде

   // разбор: Пароли НИКОГДА не хранят в открытом виде и не шифруют обратимо (расшифровать нельзя должно быть в принципе). Их пропускают через ОДНОСТОРОННИЙ хеш с СОЛЬЮ (случайной на каждый пароль — против радужных таблиц и одинаковых паролей) и, критически, МЕДЛЕННЫМ АДАПТИВНЫМ алгоритмом с настраиваемой стоимостью: bcrypt, scrypt, argon2 — они специально дорогие, чтобы перебор был невыгоден даже на GPU. Быстрые MD5/SHA-1/SHA-256 для паролей НЕ годятся (миллиарды хешей/сек). При входе сравнивают хеши. В Spring Security это PasswordEncoder (BCryptPasswordEncoder). Так даже при утечке БД пароли остаются практически невосстановимыми.

5. #security_auth5 / 5
   Почему нельзя доверять данным из запроса (например, роли или id пользователя из тела/параметра)?

   A)Потому что данные из запроса приходят в неверной кодировке, и сервер не может их прочитать

   B)Клиент полностью контролирует запрос — авторизацию решают по проверенному токену/сессии на сервере

   C)Потому что параметры запроса передаются медленно, и к моменту обработки они успевают устареть

   D)Потому что HTTP запрещает передавать в запросе идентификаторы и роли — только в заголовках ответа

   показать ответ и разбор

   +B)Клиент полностью контролирует запрос — авторизацию решают по проверенному токену/сессии на сервере

   // разбор: Любые данные запроса (тело, query, заголовки, кроме проверенных сервером) ПОЛНОСТЬЮ подконтрольны клиенту — их легко подделать (curl/Postman/перехват). Поэтому НЕЛЬЗЯ решать авторизацию по «роли»/«userId», ПРИСЛАННЫМ клиентом: злоумышленник пришлёт role=admin или чужой userId. Личность и права берут из ПРОВЕРЕННОГО СЕРВЕРОМ контекста — валидного (подпись+срок) JWT или серверной сессии, — и на нём же проверяют доступ к конкретному ресурсу (в т.ч. что ресурс принадлежит ЭТОМУ пользователю — защита от IDOR). Классика уязвимостей — доверять клиентскому id/роли и менять /orders/1001 на /orders/1002. Сервер — единственный источник истины об авторизации.