Насколько безопасно отправлять токен в заголовке запроса?

Question

Я хочу добавить аутентификацию в свое приложение с помощью токенов jwt.

Каждый раз, когда я отправляю запрос на сервер, я прикрепляю токен, созданный моим сервером.

Я раняю, это безопасно как отправить токен в заголовках? что, если кто-то получит доступ к моему компьютеру и проверит мою сеть на вкладке devtools и увидит мой токен, он сможет mimi c запрос с токеном и взять под контроль пользовательские данные.

Это распространенный сценарий? а способы кражи и взлома токенов jwt?

Answer 1

Токен - это недолговечный ключ. Любой, у кого есть доступ к токену, имеет доступ ко всему, что разблокирует этот ключ. Это кажется небезопасным, но это фундаментальное свойство использования токенов. Вы используете HTTPS для шифрования данных, чтобы их нельзя было прочитать в процессе, но всегда найдутся способы получить токен.

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

Answer 2

Да, отправка через заголовок безопасна, даже без https

что, если кто-то получит доступ к моему компьютеру, проверит мою сеть на вкладке devtools и увидит мой токен

В этом случае он также может украсть ваш кошелек, кредитную карту, машину, дом, жену и т. Д. c .. Вы понимаете, если у кого-то есть прямой доступ - игра окончена

Вы смешиваете JWT с Bearer, они разные

{ ссылка }

Answer 3

Да, его обычно прикрепляют к заголовку. Это выглядит примерно так:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Конечно, кто-то мог go войти в ваш компьютер и проверить токен. Но обычно на вашем компьютере есть какая-то аутентификация, а также для входа в систему. То же самое и с телефоном, почти у всех есть какой-то пароль.

Хорошим способом хранения токенов являются httpOnly cookie. С этим флагом javascript не может прочитать повар ie на стороне клиента. Это затрудняет получение токена при атаках XSS.

Проблема с JWT заключается в том, что у них есть срок действия, и они действительны до тех пор, пока не достигнут этой даты. Допустим, вы авторизуетесь на веб-странице и получаете токен. Теперь кто-нибудь украдет ваш жетон. Вы выходите из системы и стираете токен со своего устройства.

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

На этом этапе атакующий технически является вами потому что у него есть токен с сохраненными данными.

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

Для черного списка я бы порекомендовал кеш, например redis, для быстрого доступа.

Answer 4

Так и должно быть. При аутентификации токена JWT предоставленный сервером токен всегда должен отправляться в виде заголовка с форматом Authorization: Bearer <token>.

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

EDIT

Да, использование HTTPS обязательно. Если человек овладевает вашим компьютером, он может использовать токен, чтобы выдать себя за пользователя. Токены хороши тем, что они в основном недолговечны, а это означает, что они быстро истекают. Следовательно, их использование прекращается, и требуется повторная аутентификация.