Где хранить JWT в браузере? Как защитить от КСРФ?

Я знаю проверку подлинности на основе файлов cookie. Флаг SSL и HttpOnly может быть применен для защиты аутентификации на основе файлов cookie от MITM и XSS. Однако для его защиты от КСРФ потребуются более специальные меры. Они просто немного сложнее. (ссылка)



недавно я обнаружил, что JSON Web Token(JWT) довольно горячий как решение для аутентификации. Я знаю материалы о кодировании, декодировании и проверке JWT. Однако, я не понимаю, почему некоторые веб-сайты / учебники не говорят о необходимости защиты CSRF, если используется JWT. Я прочитал довольно много и пытаюсь суммировать проблемы ниже. Я просто хочу, чтобы кто-то мог предоставить общую картину JWT и прояснить понятия, которые я неправильно понял о JWT.




  1. Если JWT хранится в cookie, я думаю, что это так же, как аутентификация на основе cookie, за исключением того, что серверу не нужно иметь сеансы для проверки cookie/токена. Существует еще риск о CSRF, если нет специальной меры выполненный. Не вышлю, хранящихся в куки?


  2. Если JWT хранится в localStorage / sessionStorage, то нет cookie, поэтому не нужно защищать от CRSF. Вопрос в том, как отправить JWT на сервер. Я нашел здесь предлагает использовать jQuery для отправки JWT по HTTP-заголовку запросов ajax. Итак, только запросы ajax могут выполнять аутентификацию?


  3. кроме того, я нашел еще один блог показывает использовать "заголовок Authorization " и "носитель", чтобы отправить JWT. Я не понимаю метод, о котором говорит блог. Может ли кто-нибудь объяснить больше о "заголовке авторизации" и "Предъявителе"? Это сделает проверки подлинности передаваемых по HTTP-заголовка всех запросов? Если да, то как насчет CSRF?


986   2  

2 ответов:

токены JWT популярны, так как они используются в качестве формата токена по умолчанию в новых протоколах авторизации и аутентификации, таких как OAuth 2.0 и OpenID Connect.

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

аутентификация носителя является одним из схемы проверки подлинности определено в HTTP. Оно в основном означает, что YOU вставьте маркер (JWT) в заголовок HTTP авторизации запроса. Браузер будет NOT сделать это для вас автоматически, так что это не подходит для защиты вашего сайта. Поскольку браузер автоматически не добавляет заголовок к вашему запросу, он не уязвим для атаки CSRF, которая зависит от того, что ваши данные аутентификации автоматически отправляются в исходный домен.

схема носителя часто используется для защиты веб-API (служб REST) которые потребляются через вызовы AJAX или от мобильных клиентов.

40  
2015-12-14 07:23:19

нам нужно сохранить JWT на клиентском компьютере. Если мы храним его в LocalStorage / SessionStorage, то он может быть легко захвачен атакой XSS. Если мы храним его в cookies, то хакер может использовать его (не читая) в атаке CSRF и олицетворять пользователя и обращаться к нашему API и отправлять запросы на выполнение действий или получение информации от имени пользователя.

но есть несколько способов защитить JWT в cookies, чтобы его не украли легко (но есть еще некоторые продвинутые методы, чтобы украсть их). Но если вы хотите полагаться на LocalStorage / SessionStorage, то к нему можно получить доступ с помощью простой атаки XSS.

поэтому, чтобы решить проблему CSRF, я использую Double Submit Cookies в своем приложении.

Метод Двойной Отправки Куки

  1. храните JWT в файле cookie HttpOnly и используйте его в безопасном режиме для передачи по HTTPS.

  2. большинство атак CSRF имеют другое происхождение или заголовок реферера с вашим оригинальный хост в своих запросах. Так что проверьте, если у вас есть какой-либо из них в заголовке, они приходят из вашего домена или нет! Если не отвергнуть их. Если оба источника и реферер не доступны в запросе, то не беспокойтесь. Вы можете положиться на результат проверки заголовка X-XSRF-TOKEN, который я объясню в следующем шаге.

  3. в то время как браузер будет автоматически предоставлять ваши куки для домена запроса, есть одно полезное ограничение: код JavaScript то, что работает на веб-сайте, не может читать файлы cookie других веб-сайтов. Мы можем использовать это для создания нашего решения CSRF. Чтобы предотвратить атаки CSRF, мы должны создать дополнительный читаемый файл cookie Javascript, который называется: XSRF-TOKEN. Этот файл cookie должен быть создан при входе пользователя в систему и должен содержать случайную, не угадываемую строку. Мы также сохраняем этот номер в самом JWT как частное требование. Каждый раз, когда приложение JavaScript хочет сделать запрос, ему нужно будет прочитать этот токен и отправить это в заголовок HTTP. Поскольку эти операции (чтение файла cookie, установка заголовка) могут выполняться только в одном домене приложения JavaScript, мы можем знать, что это делается реальным пользователем, который использует наше приложение JavaScript.

угловой JS делает вашу жизнь проще

К счастью, я использую Angular JS в нашей платформе и угловых пакетах подход токена CSRF, что упрощает его реализацию. Для каждого запроса что наше Угловое приложение делает из сервера, то Угловое $http сервис будет делать эти вещи автоматически:

  • найдите файл cookie с именем XSRF-TOKEN в текущем домене.
  • если этот файл cookie найден, он считывает значение и добавляет его в запрос в качестве заголовка X-XSRF-TOKEN.

таким образом, реализация на стороне клиента обрабатывается для вас автоматически! Нам просто нужно установить куки с именем XSRF-TOKEN на текущем домене на стороне сервера и когда наш API получил какой-либо вызов от клиента, он должен проверить X-XSRF-TOKEN заголовок и сравнить его с XSRF-TOKEN в JWT. Если они совпадают, то пользователь реален. В противном случае, это поддельный запрос и вы можете игнорировать его. Этот метод вдохновлен методом "Double Submit Cookie".

осторожностью

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

храните ли вы ваш JWT в localStorage или вы храните свой XSRF-токен в не HttpOnly cookie, оба могут быть легко захвачены XSS. Даже ваш JWT в файле cookie HttpOnly может быть захвачен продвинутой атакой XSS, такой как способ XST.

таким образом, в дополнение к методу Double Submit Cookies, вы всегда должны следовать рекомендациям против XSS, включая экранирование содержимого. Это означает удаление любого исполняемого кода, который может вызвать браузер, чтобы сделать то, что вы не хотите, чтобы он. Обычно это означает удаление // <![CDATA[ теги и атрибуты HTML, которые вызывают JavaScript для оценки.

подробнее здесь:

82  
2017-09-10 00:15:51

Comments

    Ничего не найдено.
Click here to cancel reply.