Как предотвратить Аутентификацию веб-сервиса Rest с помощью украденного токена

Question

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

В службе входа в систему он принимает учетные данные, которые возвращают токен.

Этот токен может быть установлен в клиентских файлах cookie, и все последующие запросы используют этот токен для проверки и обработки нового запроса, если токен действителен .

Теперь мой вопрос: как проверить токен? Если кто-то украл токен и пытается получить доступ к остальным службам с помощью украденного токена, просто отредактировав файлы cookie, то как его можно идентифицировать и ограничить?

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

Одно общее предложение состоит в том, чтобы установить устаревание для токена / файлов cookie, но это до сих пор не помогает до возраста этого токена / куки.

Буду признателен за любые предложения.

Answer 1

Я не верю, что существуют какие-либо 100% надежные методы предотвращения доступа с помощью украденных пользовательских токенов. Откуда ты вообще знаешь, что токен украден в первую очередь? Но, возможно, вы можете подумать о следующем:

1. Доступ к службе REST с тем же токеном, но другой пользовательский агент подозрительно. Это можно узнать по значению заголовка User-Agent. Возможно, вы захотите отбросить такие запросы.
2. Что если IP-адрес изменится, но токен останется прежним? Ну, может, кто-то использует балансировщик нагрузки и получает доступ к сети через разные IP-адреса? Или он получил доступ к VPN с тем же токеном / cook ie, что и раньше? Если у вас нет функции отбрасывания таких запросов, вы можете повысить уровень безопасности, проверив и исходный IP-адрес.
3. В случае, скажем, токенов JWT, вам понадобится немного инфраструктуры для обработки черного списка. Следуйте за этим .

Answer 2

Мое текущее понимание "наиболее безопасного" подхода к авторизации запросов в браузере состоит в том, чтобы требовать проверки HttpOnly SameSite cook ie AND заголовка HTTP (например, Authorization или X-CSRF-Token) в комбинации.

Например, при выдаче JWT в браузер отправьте подпись JWT в HttpOnly SameSite cook ie и отправьте тело (без подписи) клиенту для хранения в localStorage и отправки в Authorization заголовок. При авторизации запроса объедините два обратно в полный JWT и после этого подтвердите его как обычно.

В качестве альтернативы, вы можете сгенерировать два JWT с полем для различения guish их (например, клиента один имеет "browser", повар ie имеет "cookie") и требует, чтобы оба действовали и оба идентифицировали одного и того же пользователя. Один из них отправляется в заголовке Authorization и сохраняется в localStorage, а другой использует SameSite HttpOnly cook ie.

Другой популярный подход заключается в сохранении токена CSRF в поле в JWT, и поместите JWT в cook ie и потребуйте, чтобы клиент отправил соответствующий заголовок в заголовке (например, X-CSRF-Token).

Все решения эффективно предотвращают атаки XSS и CSRF: XSS не может получить HttpOnly готовит ie, а CSRF не включает заголовок HTTP, поэтому блокирует обе атаки.

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

Answer 3

После преодоления различных подходов, мы нашли решение, объясненное ниже:

1. Мы сохраняем токен (зашифрованный) в куки в запросе на вход, и для каждого последующего запроса этот повар ie проверяется.
2. Проблема заключалась в том, что если кто-то заменил токен в cook ie другим действительным токеном, поскольку файлы cookie поддерживаются браузером клиента.

Решение: -> Хотя значения токена были зашифрованы, он представлял только одно значение, поэтому, если одно заменит все зашифрованное значение другим действительным зашифрованным значением, его можно взломать.

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

например

Cook ie 1 -> зашифрованный токен

Cook ie 2 -> Зашифрованный объект, содержащий информацию, такую ​​как имя пользователя + некоторые другие детали контекста пользователя + токен

Так что в случае Cook ie 1 было легко заменить другое зашифрованное значение, поскольку оно представляло только один токен, хотя он был зашифрован ed.

Но в случае Cook ie 2 он содержал объект с несколькими значениями, поэтому только значение токена не может быть изменено, зашифровано и возвращено в тот же самый Cook ie.

Перед аутентификацией. Мы делаем дешифрование целого повара ie 2, извлекаем из него часть токена и проверяем его часть против повара ie 1.

Это решило нашу проблему !!

Спасибо всем за ваше время и руководство.

Answer 4

Вы можете использовать jwt - это стандарт Inte rnet для создания маркеров доступа на основе JSON, которые утверждают некоторое количество утверждений. Например, сервер может сгенерировать токен с заявкой «вошел в систему как администратор» и предоставить его клиенту. Затем клиент может использовать этот токен, чтобы доказать, что он вошел как администратор.

Как это работает?

Во-первых, он содержит закрытый ключ, сгенерированный разработчиком:

, давайте нам этот ключ: sfcqw@sav%$#fvcxv*s_s515, и этот называется приватным ключом, и у нас также есть ключ publi c this publi c сгенерированный ключ зависел от пользовательских данных и закрытого ключа, и невозможно узнать, что в нем содержится, если вы не знаете секретный ключ.

для более подробного объяснения:

publi c key:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.plpJkAcgrgCIsoRyV2kjGsvWF6OsXU1mD785OSWTH4o

у нас есть вышеуказанный ключ, сгенерированный нашим закрытым ключом: sfcqw@sav%$#fvcxv*s_s515 Чтобы быть более понятным, зайдя на этот сайт: https://jwt.io/ и попробуйте пройти ключ publi c без ввода секретного ключа, как на картинке, и вы все поймете.

Answer 5

Для меня не было способа предотвратить кражу доступа к токену JWT, кроме

• , настроив короткий тайм-аут для токена
• , более защищенного на уровне HTTP-запроса разрешено указывать только c `User-Agent. Подробнее
• больше защищено на уровне HTTP-запроса путем настройки ключа заголовка для организации, например, Authorization= Bearer <token> вместо *1011*
• больше защищено в HTTP уровень запроса путем ограничения доверенных URL-адресов / доменов, например X-Content-Security-Policy. Подробнее