Защита CSRF с помощью веб-маркеров JSON

Я читал, что при использовании JWT нет необходимости защищать от атак CRSF, например: ", поскольку вы не полагаетесь на файлы cookie, t необходимо защитить от запросов на межсайтовый сайт".

Однако я не понимаю: если я храню токен в localStorage (как мне посоветовали в учебнике того же сайта), что мешает злоумышленнику подделывать вредоносный запрос, читая мой localStorage вместо моих файлов cookie?

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

Ответ 1

Строго говоря, да, все, что хранится в локальном/сеансовом хранилище (которое я буду называть хранилищем HTML5), можно было бы украсть при атаке на межсайтовый скриптинг (XSS). См. в этой статье.

Тем не менее, есть много движущихся частей.

Во-первых, есть тонкие различия в том, как HTML5 Хранение и файлы cookie связаны с доступом к JavaScript.

HTML5 Хранение:

делится между http и https. Элемент, хранящийся в хранилище http://example.com HTML5, не может быть доступен JavaScript, работающим на https://example.com.
делится между субдоменами. Однако элемент, хранящийся в хранилище http://example.com HTML5, не может быть доступен JavaScript, работающим на http://sub.example.com (вы можете сделать трюки, чтобы обойти это, однако).

Печенье более рыхло-гуся:

Файл cookie с доменом example.com будет отображаться как http://example.com, так и https://example.com, если у него нет атрибута secure, и в этом случае он будет отправлен только на https.
Куки файлы, не отправленные с явным доменом, будут отправляться обратно в точный домен, который его отправил. Если домен явно определен как example.com, он будет отправлен как на example.com, так и на sub.example.com. (Это самая запутанная часть "spec" cookie, к сожалению, см. в этой статье).
Файл cookie может быть прочитан JavaScript, если он запущен на странице с соответствующим доменом (и соблюдает флаг secure cookie), если cookie не имеет атрибут httpOnly, и в этом случае JavaScript не сможет прочитайте его.

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

Последняя часть - это то, как выполняется CSRF-атака (политика одного и того же происхождения помогает только так). Страница OWASP на CSRF является хорошим ресурсом для изучения того, как эти виды атак работают.

Причина хранения маркера аутентификации в локальном хранилище и ручное добавление его к каждому запросу защищает от CSRF - это ключевое слово: manual. Поскольку браузер не отправляет автоматический токен, если я нахожусь в evil.com, и ему удастся отправить POST http://example.com/delete-my-account, он не сможет отправить мой токен authn, поэтому запрос будет проигнорирован.

С учетом вышеизложенного, следует ли использовать куки файл или хранилище HTML5 ряд компромиссов:

Сохранение маркера аутентификации в хранилище HTML5 означает:

(-) Опасность его похищения при атаке XSS.
(+) Предоставляет защиту CSRF.
(-) Необходимо вручную изменить каждый запрос, отправляемый на сервер, ограничив вас веб-приложениями SPA (например, AngularJs).

С другой стороны, если вы храните маркер authn в файле cookie с надписью httpOnly и secure, тогда:

(+) Идентификатор authn не может быть украден XSS.
(-) Вам нужно будет обеспечить защиту CSRF самостоятельно. Реализация защиты CSRF проще в некоторых рамках, чем в других.

Какой вариант лучше зависит от ваших потребностей.

Ваш токен authn защищает все, что связано с деньгами? Вероятно, вам понадобится опция cookie httpOnly secure.
Является ли уровень усилий, необходимых для реализации защиты CSRF, нецелесообразным для защиты активов? Тогда хранилище HTML5 может быть правильным.