Возможно ли вмешательство полезной нагрузки при отправке запроса на сервер ресурсов с JWT?

Question

Как мы знаем, JWT подписан с секретным ключом, поэтому сам токен не может быть подделан, но полезная нагрузка, которую мы отправляем на сервер ресурсов с JWT, может быть простой текстовой / json / xml / строкой запроса, так как мы можем защитить полезную нагрузку от подделки ?

Answer 1

JWT само по себе не является доказательством взлома. Чтобы сделать его безопасным, его необходимо преобразовать с помощью следующих 2 шагов:

1. Подписать с помощью закрытого ключа отправителя
2. Зашифровать с помощью ключа c Получателя

Подписание с помощью закрытого ключа отправителя гарантирует обнаружение любой несанкционированной модификации токена.

Шифрование с помощью открытого ключа c Получателя гарантирует, что токен достигает секретности, и только предполагаемый получатель может видеть содержимое токена.

JWT, подписанный Отправителем, называется JWS. Зашифрованный JWS называется JWE.

Дополнительная информация: https://dzone.com/articles/securing-spring-boot-microservices-with-json-web-t

Answer 2

tl; dr Чтобы сохранить полезную нагрузку (и токен в целом) в безопасности, все, что вам нужно сделать, это использовать строгий секрет и алгоритм подписи и проверить подпись перед доверием содержимого .

---

JWT подписан с секретным ключом, но полезная нагрузка может быть простым текстом / json / xml / query

Вы, похоже, не понимаете, что такое JWT есть. Нет отдельного JWT и полезной нагрузки, один является частью другого. JWT состоит из заголовка, полезной нагрузки и подписи. Подпись создается как для частей заголовка и полезной нагрузки, так и для дополнительного секретного ключа. Это означает, что, если любая часть подделана с подписью, не может быть проверено.

Из Введение в JWT :

Обратите внимание, что для подписанных токенов эта информация [заголовок и полезная нагрузка], хотя и защищена от подделки, доступна для чтения любому. Не помещайте секретную информацию в элементы полезной нагрузки или заголовка JWT, если она не зашифрована.

Чтобы убедиться в этом, вы можете использовать JWT отладчик . Когда вы изменяете декодированный заголовок или полезную нагрузку, их значения base64 изменяются, и, следовательно, подпись изменяется вместе с ними. Если вы скопируете и вставите старое значение подписи в новый JWT, это приведет к ошибке неверной подписи.

Answer 3

К сожалению, не существует стандартного способа гарантировать, что тело запроса не было изменено во время транспортировки с использованием заголовков http.

AFAIK и среди всех схем аутентификации , перечисленных IANA , ни одна из них не имеет такой функции.

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

Я рекомендую вам прочитать больше о следующих инициативах. В этой реализации вам могут помочь следующие:

• AWS Signature Version 4 : безусловно, самый интересный ресурс. Это также позволяет подписывать POST (возможно, PUT и PATCH) запросы
• Hawk : то же, что и выше. Хотя не широко используется.
• Код проверки подлинности сообщения OAuth 2.0 (MA C) Токены . Этот заброшен и не гарантирует, что тело не было изменено.

Answer 4

Подпись - это именно то, что предотвращает изменение содержимого. Полезная нагрузка не может быть изменена без аннулирования подписи.

Позвольте мне также уточнить, что JSON Web Token (JWT) является открытым стандартом, который определяет компактный и автономный способ безопасного передача информации между сторонами в виде объекта JSON. JWT - это generi c имя для следующих типов токенов:

• JSON Веб-подпись (JWS): полезная нагрузка закодировано и подписано , чтобы можно было проверить целостность утверждений.
• JSON Веб-шифрование (JWE): их полезная нагрузка составляет зашифровано , поэтому заявки скрыты от других сторон.

Если вы намерены предотвратить несанкционированное изменение полезной нагрузки, используйте JWS. Если вы хотите скрыть полезную нагрузку от других сторон, используйте JWE.