Насколько я должен беспокоиться об открытии JWT для уязвимости XSS?

Question

Я создаю node.js веб-приложение с реакцией для GUI и graphQL, обслуживаемым Apollo для серверного соединения с экземпляром RDS (MySQL) в AWS.

Я аутентифицирую пользователей, а затем возвращаю JWT. Я выяснил, как продлевать / истекать токены, но теперь я сталкиваюсь с вопросом, где сохранить его на стороне клиента, когда пользователь посещает сайт ...

Есть две основные концепции с третьим, являющимся гибридной моделью. 1) Сохраните его как localStorage с JavaScript, как описано в HowToGraphQL 2) Сохраните его в Cook ie с http-only установленным в true, как описано в вышеупомянутой статье как катионный ссылка на Randall Degges

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

Концепция 1 уязвима для XSS, только если уже используется другая уязвимость XSS. Но это безопасно только для сайта, поэтому только скрипты, работающие на сайте, могут получить к нему доступ, но не скрипты на любом сайте. Там много говорят о безопасности, что его не следует хранить таким способом, хотя это распространенный способ, потому что разработчик не может доверять КАЖДОМУ JavaScript сценарию, который они запускают на своем сайте, и может быть один, который читает localStorage и затем отправляет это вне сайта.

Concept 2 устраняет уязвимость XSS, объявляя только http-адрес, чтобы сделать его доступным только для сервера на вашем сайте. Проблема здесь заключается в том, что затем необходимо создать отдельный метод для использования той же внутренней аутентификации для других целей, таких как стандартный API (для собственных приложений или других сайтов), где JWT отправляется в заголовке через https, где он хранится. безопасно на другом сервере.

Итак, я исследовал и обнаружил, что этот гибридный метод, описанный Беном Авадом 3), использует токен запроса и токен refre sh. Токен запроса может затем работать нормально для стандартного API, но также и на нашем сайте приложения реакции мы можем сохранить его только в памяти и сохранить токен refre sh в файле cook ie для отправки токена запроса, когда пользователи refre sh или закройте и снова откройте браузеры.

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

Мой вопрос: как беспокоюсь о том, стоит ли открывать JWT для уязвимости XSS? Это то, что в будущем я бы проделал долгий путь, когда у меня будет больше времени, но я настаиваю на крайнем сроке. Мой сайт будет менее известен и не похож на Facebook или Sales-Force, на которые обязательно нацелятся хакеры. Мой сайт не хранит данные кредитной карты или другие высокочувствительные данные, кроме базового c CRM и списка задач. Если бы мой сайт был открыт для XSS с помощью другого кода, не был бы уязвим весь процесс аутентификации с помощью сценариев кейлоггинга или тому подобного, даже не зная JWT. Мне кажется, что я бы проделал большую дополнительную работу, чтобы обезопасить себя от возможной угрозы, что в случае ее возникновения вся система уже будет взломана.

Answer 1

Если ваш сайт удобен для работы с Inte rnet Explorer и некоторыми более старыми версиями основных браузеров, вы можете воспользоваться новым свойством cookie, называемым Same-Site (точнее, сайтом). будет работать, но повар ie не будет в безопасности).

Определяя повара ie как HttpOnly, вы немедленно защищены от атак XSS, но оставляете себя открытым для атак CSRF.

Теперь, определив для повара ie свойство Same-Site = Strict, повар ie будет отправляться только через вызовы Http и только в том случае, если домен соответствует домену вашего сайта. Так, например, если кто-то создает форму на другом сайте и пытается выполнить почтовый запрос на ваш собственный сайт, повар ie никогда не будет отправлен.

Если вы хотите, чтобы повар ie был передается только по запросам GET, вы можете установить для свойства Same-Site значение Lax, но, как вы упомянули.

Дополнительную информацию об этой функции можно найти по следующей ссылке в разделе файлов cookie SameSite:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Также следует проверить совместимость функции браузера с помощью следующей ссылки:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Browser_compatibility

Answer 2

Прежде чем я продолжу свой ответ, вы можете проверить OW ASP для набора общих рекомендаций относительно XSS и CSRF , так как вы упомянули куки.

Cedomir уже покрыл значительную часть баллов за хранение JWT на стороне клиента. Стоит упомянуть одну вещь: если в вашем веб-приложении запущены сторонние скрипты, они также имеют доступ к API хранилища. Так что, если загруженный вами скрипт должен был быть похищен, они могли бы украсть токен там. Что касается XSS со входами, если вы избегаете каждого возможного пользовательского ввода, то это в значительной степени смягчается как вектор атаки. Но вам нужно всего лишь один раз испортить, чтобы кто-то воспользовался дырой и украл JWT в этот момент. (Подробнее см. В этом блоге post )

Теперь, если вы вместо этого сохраните JWT в Http-Only, вы в значительной степени обойдете проблему XSS, как уже отмечали. Однако теперь вы представили новую проблему - подделка межсайтовых запросов. Так как файлы cookie отправляются с каждым запросом, злоумышленник может настроить веб-сайт для выполнения мошеннического запроса от имени пользователя и выполнения действий без его согласия. Теперь я не буду подробно останавливаться на митигации здесь, поскольку OW ASP и другие места уже проделали довольно хорошую работу, но кратко о ней можно подвести итог, установив самый популярный и поддерживаемый пакет Anti-CSRF для Ваш язык: -)

Что касается признания недействительным токена, как его воспитал Седомир, то использование этого механизма может быть весьма полезным. Однако его реализация означает, что вы отказываетесь от некоторых преимуществ использования JWT. Сохраняете ли вы текущий JWT, назначенный пользователю, и проверяете его или уникальный ключ, используемый для подписи JWT для каждого пользователя, вы теперь можете отслеживать состояние пользователя, устраняя одну из причин использования JWT. В зависимости от вашего приложения вам нужно будет взвесить этот компромисс. Гораздо более простой способ может состоять в том, чтобы просто иметь краткосрочные токены, так что любой украденный токен потенциально не будет иметь очень полезного срока службы. Однако, как вы, вероятно, понимаете, короткий срок службы может быть очень раздражающим для пользователя. Ваш сайт может периодически опрашивать сервер на наличие нового токена, в то время как ваш пользователь продолжает использовать сайт как способ улучшить работу. Вы также можете сбалансировать свои проблемы безопасности с временем жизни токена, например, 15-минутный срок действия токена для приложения электронной коммерции и час или более для социального приложения.

Однако я бы не советовал использовать его. маркера refre sh, по крайней мере, для веб-приложения на основе браузера. Как правило, браузер просто не считается способным защитить секретные секреты. Используя токен refre sh, вы просто откладываете кражу учетных данных на другой уровень, поскольку по природе токенов refre sh они 1) долговечны и 2) эффективно используются в качестве учетных данных для получения больше JWTs. Таким образом, если маркер refre sh должен быть украден, злоумышленник может просто получить больше действительных JWT от имени пользователя. Если у вас есть мобильное или настольное приложение, у вас есть механизмы, которые можно использовать для безопасного хранения токенов refre sh, и этот совет неприменим.

... Или вы можете просто использовать сеансы; -)

Answer 3

Просто используйте HTTP только + SSL только куки, чтобы сохранить ваш JWT. Практически невозможно украсть пользовательский jwt с помощью программного или любого другого типа кода.

Кто-то сказал здесь, что это не разница между LocalStorage и Cookies. Он не прав, сторонние библиотеки bcs и расширения chrome могут легко украсть данные LocalStorage. Но они не могут украсть HTTP только cook ie.

Он защитит от любых известных и наиболее вероятных новых типов атак.

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

Upd: Хорошая статья о передовых методах стратегии JWT: https://ducktypelabs.com/5-mistakes-web-developers-should-avoid-when-using-jwts-for-authentication/

Answer 4

Это проблема, на которую я потратил много времени. Как надежно хранить токен авторизации. У людей разные стратегии решения этой проблемы, поэтому я поделюсь тем, что работает для меня. Пользователи моих приложений подвергались различным атакам, и все они до сих пор не смогли ничего украсть. Никто не использовал XSS.

Вот что я делаю

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

Почему я так делаю

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

Сохранение маркер в файлах cookie не дает никаких преимуществ по сравнению с локальным хранилищем, если предположить, что приложение защищено от атак злоумышленников, которые могут внедрить JavaScript в ваше приложение, в основном через формы и API в вашем приложении. Убедитесь, что все пользовательские данные JS безопасны для инъекций. Кроме того, с файлами cookie возникают проблемы при использовании WebSockets, которые вы должны go вокруг.

Существует также точка взлома одной из учетных записей, и вы хотите аннулировать этот токен как можно скорее. JWT по умолчанию должен иметь механизм отзыва. Реализация этой функции сводит на нет масштабируемость JWT, потому что проверка JWT потребует вызова базы данных, чтобы узнать, может ли этот пользователь выполнить указанное действие c. Есть 2 способа, которыми вы можете go узнать об этом. Один из них - просто проверить пользовательские данные, если пользователь заморожен из базы данных, он менее масштабируем из-за вызова, но если вы уже извлекаете пользовательские данные в промежуточном программном обеспечении, это достаточно хорошая ТМ. Другой способ заключается в извлечении «замороженных пользователем» данных из базы данных только при внесении изменений в базу данных или при важности вызова от клиента.

В сумме

Я бы хранил токен в локальном хранилище. Защитите приложение от инъекций кода. И сделайте переключатель уничтожения для учетных записей, если они каким-либо образом скомпрометированы.

РЕДАКТИРОВАТЬ СПАСИБО ЗА КОММЕНТАРИИ @ @ JerryCauser

Хранить токен более безопасно в безопасном http только повар ie. Не ожидайте, что выбор механизма хранения автоматически спасет ваших пользователей от взлома. Существуют способы захвата сеансов и других эксплойтов, включая пользователей, использующих веб-расширения и одобряющих их запрос на чтение защищенных данных.

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

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

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

РЕДАКТИРОВАТЬ В СООТВЕТСТВИИ С КОММЕНТАРИЙ ОТ АСКЕРА @ amaster

Если вы совершаете поездку в базу данных Возможно, JWT не самый лучший солютон. Суть JWT заключается в том, чтобы иметь подписанные заявки и идентификатор пользователя без вызова базы данных. В этом случае, возможно, выберите сеансы вместо JWT.