Я провел много исследований по "лучшим практикам", окружающим это, и прочитал сообщение в блоге после сообщения в блоге, вопрос SO после вопроса SO и статью OWASP после статьи OWASP. Я пришел к нескольким ясным ответам, но некоторые неизвестные.
Во-первых, "Do's":
- Использовать JWT для авторизации пользователей в моем REST API [1] [2]
- Храните JWT в файле cookie HTTPOnly/Secure и создайте защиту CSRF. НЕ храните в локальном хранилище HTML5 [3] [4] [5] (На самом деле этот вопрос спорный, проще ли защищать его от XSS или CSRF? [6])
- Проверьте метод подписи JWT [7]
Теперь я начал с предположения, что наличие SPA (построенного с помощью Angular) и использование HTML5 sessionStorage будет достаточно безопасным для краткосрочных токенов, но есть смысл сделать, что атаки XSS могут произойти из "плохой актер", происходящий из одной из многих библиотек, загруженных из CDN.
В моем конкретном случае использования я не планирую иметь долгоживущие токены - истечение после 10 минут неиспользования, но я все еще выясняю, хочу ли я отслеживать истечение сеанса или использовать токены обновления - StormPath рекомендует первый (больше не является апатридом?), но я считаю, что крупные игроки, использующие JWT, используют токены обновления (Google использует их, но заявляет, что вам нужно хранить их в надежном долгосрочном хранилище, что означает, что HTML5 localStorage снова не может быть и речи).
Я хотел бы сделать так, чтобы моим пользователям не приходилось регистрироваться, если они обновляют страницу (следовательно, необходимо сохранить токен на стороне клиента). Я также хотел бы использовать мой SPA в качестве "мобильного приложения" с помощью Кордовы. Очевидная ошибка здесь заключается в том, что если я использую файлы cookie, у Кордовы нет поддержки/хранения cookie файлов cookie, и я вынужден вместо этого переключиться на локальное хранилище HTML5. Поскольку на мобильном телефоне мне действительно не нужно беспокоиться о освежающих страницах, я могу просто оставить свой токен в памяти и уйти со стратегией, на которую я рассчитываю.
Если я возьму этот подход, основанные на cookie JWT на рабочем столе, заголовки "Bearer" на мобильном телефоне, мне теперь понадобится конечная точка аутентификации, которая будет давать токены двумя разными способами, и когда я авторизуюсь на стороне REST API, я необходимо поддерживать как JWT на основе файлов cookie (с CSRF), так и проверку JWT на основе заголовков. Это осложнение вызывает у меня беспокойство, поскольку я не знаю, могу ли я точно предвидеть последствия для безопасности здесь.
Подводя итог заграждению мыслей выше:
- Создайте обработчик проверки подлинности, который будет раздавать токены через HttpOnly/Безопасные файлы cookie на рабочий стол и на полезную нагрузку для мобильных устройств.
- В моем REST API поддерживаются оба метода проверки: на основе заголовков и файлов cookie, включая защиту CSRF для подхода, основанного на файлах cookie.
Есть ли какая-то причина, по которой я бы не хотел использовать этот подход? Я предполагаю, что если я возьму XSS в своем SPA как серьезный риск, тогда мне нужна классическая страница входа для аутентификации установите правильные файлы cookie, потому что, если я выполняю аутентификацию через SPA, любая атака XSS может также перехватить это (как на мобильном, так и на рабочем столе)! Тем не менее, на мобильном телефоне мне нужно будет внедрить JWT в SPA, возможно, через какой-то пользовательский элемент DOM (метатег?), Но в этот момент я могу просто позволить SPA выполнить вход и не учитывать угрозу XSS для мобильных устройств, Кордова упаковывает все активы в пакет установки, чтобы несколько лучше, но почему бы не использовать тот же подход в версии Desktop?
Мое приложение очень мало вводит пользователя, это в первую очередь инструмент панели инструментов/отчетов. Там будет "центр сообщений", но контент всегда должен быть создан пользователем (только этим пользователем) и дезинфицирован. В моем случае использования, было бы нормально отклоняться от "лучших практик" и полагаться на localStorage, не считая XSS как серьезный риск для моего SPA?. Это упростило бы все это (используйте HTML5 sessionStorage как первоначально планировалось) и уменьшить сложность, которая уменьшит поверхность атаки для возможных ошибок в безопасности. Я просто хочу убедиться, что понимаю риски перед тем, как двигаться вперед.
Нет ли безопасного способа сделать это безопасным, кроме как создав собственное приложение для мобильных устройств и не используя Кордову для преобразования моего SPA в мобильное приложение?. Я бы не хотел, чтобы это было случай, но вполне может быть.
Буду признателен за все мысли по этому поводу!