Как защитить REST API для SPA и мобильного приложения с помощью Cordova

Я провел много исследований по "лучшим практикам", окружающим это, и прочитал сообщение в блоге после сообщения в блоге, вопрос 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 в мобильное приложение?. Я бы не хотел, чтобы это было случай, но вполне может быть.

Буду признателен за все мысли по этому поводу!

Ответы

Ответ 1

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

Что касается безопасности, решаете ли вы использовать JWT или простые маркеры OAuth, убедитесь, что все ваши сообщения связаны через https.

Используйте localStorage столько, сколько хотите. Если вы рассматриваете анатомию HTTP-запроса, все это действительно отправляет текстовое сообщение, разделенное на несколько разделов на сервер. Заголовок запроса не более безопасен, чем любая другая его часть, включая файлы cookie. Таким образом, точки зрения с точки зрения безопасности - генерация/валидация/недействительность токена, хранение токена на устройстве и механизм транспорта запросов.

  • Generation/Validation/Invalidation: Создайте токены на вашем сервере. Используйте некоторые технологии/стратегии, чтобы гарантировать, что нет возможности для столкновений или кровотечений. Кроме того, убедитесь, что ваша стратегия позволит вам аннулировать токен на сервере, который впоследствии лишает доступ к данным, запрашиваемым с сервера, при дальнейшем использовании токена. Тогда вы в своем приложении должны обрабатывать пользовательский интерфейс пользователя, когда сервер отказывает в доступе к ресурсам.

  • Как вы храните токен на устройстве, ограничено тем, что делает операционная система устройства доступной для вас. Что касается того, что использование родного приложения лучше кросс-платформенного, я думаю, что создание плагина native-cordova для хранения вашего токена с использованием какой-либо конкретной собственной стратегии, если вы не удовлетворены "из коробки" (например, локальное хранилище), возможно, хотя, по моему опыту, это обычно излишне. Рад быть исправлен на этом, если у кого-то есть другой опыт.

  • Пожалуйста, используйте HTTPS ВСЕГДА без исключений для всех сообщений конечной точки Webservice. Является ли HTTPS надежным, НЕТ, но вы бы не строили дом без входной двери просто потому, что посвященные грабители могли научиться выбирать замки. Это значительно облегчает транспортный механизм.

Обычно это все родные приложения тоже должны работать.