Как защитить ASP.NET Core Web API от украденного токена JWT для олицетворения - PullRequest
Новая
       15

Как защитить ASP.NET Core Web API от украденного токена JWT для олицетворения

0 голосов
/ 02 января 2019

У меня ASP.NET core REST API, развернутый на сервере за IIS. API REST используется веб-приложением Angular JS и мобильным приложением (Android / IOS). Для авторизации я использую токен JWT (). Недавно прошел Аудит Безопасности, и они обнаружили, что JWT, хранящийся в Локальном хранилище, может быть украден и использован другим злоумышленником из той же организации для олицетворения (например, Сотрудник, использующий функции Менеджера).

Я хочу пометить человека или эту машину на этот JWT, чтобы при краже JWT злоумышленник не мог использовать его ненадлежащим образом или не использовать его с этим украденным токеном. Я попытался пометить IP с помощью токена JWT и сохранил их поиск на сервере (в кеше памяти). Ниже приведен код, который я пробовал, но он не работал. 

private readonly IHttpContextAccessor _httpContextAccessor;
public TestController(IHttpContextAccessor httpContextAccessor)
{
    _httpContextAccessor = httpContextAccessor;
}
var ipAddress = _httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString();

Я ожидал, что вывод будет отличаться каждый раз, когда я запрашиваю с разных машин. Но фактический результат - тот же IP каждый раз как этот 15.11.101.25 (хотя я пробовал с разных машин). Пожалуйста, поделитесь со мной лучшим решением, если есть. Извините за мой английский.

1 Ответ

0 голосов
/ 02 января 2019

Если вам действительно необходим такой тип безопасности, вы можете объединить токен JWT с безопасным (= куки-файлы, разрешенные к отправке только через https) cookie-файл только для http, и хранить в нем своего рода маркер запроса, который отправляется на каждый запрос.

Вы можете прочитать Где хранить ваши JWT - файлы cookie и веб-хранилище HTML5 , который охватывает тему и объясняет преимущества и недостатки локального хранилища по сравнению с файлами cookie для JWT.

Файлы cookie только для HTTP не могут быть прочитаны с помощью скриптов JavaScripts (и, следовательно, не украдены) и, следовательно, защищены от атак XSS. А атакам на основе CSRF не удается получить токен JWT (поскольку он отправляется через заголовки).

Таким образом, в атаках на основе XSS не будет маркера на основе файлов cookie, а в запросе на основе CSRF не будет маркера JWT, необходимого для аутентификации пользователя. Маркер cookie может быть создан при входе в систему, поэтому он привязан к пользователю, который входит в систему на этом компьютере.

Конечно, вы также можете перевернуть его и получить JWT в защищенном коке и токен анти-запроса в качестве заголовка.

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

В качестве альтернативы, не храните токены JWT в локальном хранилище. Когда вы используете поток OpenID, ваше приложение при первой загрузке увидит, что оно не авторизовано, перенаправит вас к провайдеру OpenID, позволит пользователю ввести свои учетные данные и перенаправит их обратно с токеном (или кодом для кода авторизации). поток).

Когда пользователь закрывает браузер и снова открывает сайт, токена больше нет, пользователь будет перенаправлен к поставщику OpenID. Поскольку пользователь все еще вошел в систему, учетные данные не будут запрашиваться, и он будет перенаправлен обратно на страницу, с которой он пришел, включая новый набор токенов. Вам просто нужно сохранить токены в памяти (и обновить их по истечении срока) для текущего сеанса приложения.

...