Если вы можете декодировать JWT, как они защищены?
Я люблю JWT, это действительно весело работать. Мой вопрос в том, если я получу JWT, и я могу декодировать полезную нагрузку, как это безопасно? Не мог ли я просто выхватить токен из заголовка, декодировать и изменить информацию о пользователе в полезной нагрузке и отправить ее обратно с тем же правильным закодированным секретом?
Я знаю, что они должны быть, мне просто очень нравится понимать технологии. Что я упускаю? Спасибо!
5 ответов
JWTs могут быть подписаны, зашифрованы или оба. Если маркер подписан, но не зашифрован, каждый может прочитать содержимое маркера, но если вы не знаете закрытый ключ, вы не можете его изменить. В противном случае получатель заметит, что подпись больше не будет совпадать.
ответ на ваш комментарий: Я не уверен, правильно ли я понимаю ваш комментарий. Просто чтобы быть уверенным: знаете ли вы и понимаете цифровые подписи? Я просто кратко объясню один вариант (HMAC, который симметричные, но есть и многие другие).
предположим, Алиса хочет отправить JWT Бобу. Они оба знают какой-то общий секрет. Мэллори не знает этого секрета, но хочет вмешаться и изменить JWT. Чтобы предотвратить это, Алиса вычисляет Hash(payload + secret) и добавляет Это как подпись.
при получении сообщения Боб также может вычислить Hash(payload + secret) чтобы проверить, соответствует ли подпись.
Если, однако, Мэллори что-то меняет в содержании, она не может вычислить соответствующая подпись (которая будет Hash(newContent + secret)). Она не знает секрета и не имеет возможности узнать его.
Это означает, что если она что-то изменит, подпись больше не будет совпадать, и Боб просто больше не примет JWT.
предположим, я посылаю другому человеку сообщение {"id":1} и подпишите его Hash(content + secret). (+ здесь просто конкатенация). Я использую хэш-функцию SHA256, и подпись, которую я получаю:330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c. Теперь ваша очередь: играть роль Мэллори и попытаться подписать сообщение {"id":2}. Ты не можешь, потому что не знаешь, какой секрет я использовал. Если я предполагаю, что получатель знает секрет, он может вычислить подпись любого сообщения и проверить, правильно ли оно.
вы можете перейти к jwt.io, вставьте маркер и прочитайте содержимое. Поначалу это раздражает многих.
короткий ответ заключается в том, что JWT не занимается шифрованием. Он заботится о проверке. То есть, он всегда может получить ответ на "манипулирование содержимым этого токена"? Это означает, что манипуляция пользователем токеном JWT бесполезна, потому что сервер будет знать и игнорировать токен. Сервер добавляет подпись на основе полезная нагрузка при выдаче маркера клиенту. Позже он проверяет полезную нагрузку и соответствующую подпись.
логический вопрос заключается в том, какова мотивация не заниматься зашифрованным содержимым?
самая простая причина заключается в том, что она предполагает, что это решенная проблема по большей части. Если вы имеете дело с клиентом, например, с веб-браузером, вы можете хранить токены JWT в файле cookie, который
secure + httpsOnly(Не может быть прочитан Javascript + не может быть чтение по HTTP) и переговоры с сервером по зашифрованному каналу (HTTPS). Как только вы узнаете, что у вас есть безопасный канал между сервером и клиентом, вы можете безопасно обмениваться JWT или чем угодно еще.это держит вещи простыми. Простая реализация упрощает принятие, но также позволяет каждому слою делать то, что он делает лучше всего (пусть HTTPS обрабатывает шифрование).
JWT не предназначен для хранения конфиденциальных данных. Как только сервер получает токен JWT и проверяет его, он может свободно искать идентификатор пользователя в своей собственной базе данных для получения дополнительной информации для этого пользователя (например, разрешения, почтовый адрес и т. д.). Это сохраняет JWT небольшим по размеру и позволяет избежать непреднамеренной утечки информации, потому что все знают, что не следует хранить конфиденциальные данные в JWT.
это не слишком отличается от того, как сами куки работают. Cookies часто содержат незашифрованные полезные нагрузки. Если вы используете HTTPS, то все хорошо. Если нет, то это рекомендуется шифровать конфиденциальные файлы cookie самостоятельно. Не делать этого будет означать, что человек-в-середине атаки возможно-прокси-сервер или ISP читает куки, а затем воспроизводит их позже, притворяясь, что вы. По аналогичным причинам JWT всегда следует обмениваться через безопасный уровень, такой как HTTPS.
содержимое веб-маркера json (JWT) не является по своей сути безопасным, но есть встроенная функция для проверки подлинности маркера. JWT - это три хэша, разделенные точками. Третья подпись. В системе открытого/закрытого ключа эмитент подписывает подпись токена закрытым ключом, который может быть проверен только соответствующим открытым ключом.
важно понимать различие между эмитентом и верификатора. Получатель маркер отвечает для проверки.
в безопасном использовании JWT в веб-приложении есть два важных шага: 1) отправить их по зашифрованному каналу и 2) проверить подпись сразу после ее получения. Асимметричный характер криптографии с открытым ключом делает возможной проверку подписи JWT. Открытый ключ проверяет, что JWT был подписан соответствующим закрытым ключом. Никакая другая комбинация ключей не может выполнить эту проверку, тем самым предотвращая попытки олицетворения. Следуйте этим двум шагам, и мы сможем гарантируйте с математической уверенностью подлинность JWT.
только приватекей JWT, который находится на вашем сервере, расшифрует зашифрованный JWT. Те, кто знает privateKey, смогут расшифровать зашифрованный JWT.
скрыть privateKey в безопасном месте на вашем сервере и никогда никому не говорить privateKey.
данные внутри JWT подписаны и зашифрованы, это не означает, что это безопасно. JWT не предоставляет гарантии для конфиденциальных данных.
данные шифруются с помощью закрытого ключа, который известен обеим сторонам, т. е. отправителю и получателю, злоумышленник может затормозить ключ и может изменить содержимое.
насколько мне известно, JWT не обеспечивает безопасность.
спасибо