Подлинность запроса
Альтернативой является аутентификация на основе токенов, которая хорошо работает для мобильных приложений и устраняет необходимость в токенах CSRF, поскольку они сами проверяют подлинность запроса.
Аутентичным токенам нельзя доверять для проверки подлинности запроса, поскольку они идентифицируют только пользователя, а не подлинное мобильное приложение, выполняющее запрос.
Злоумышленник, управляющий устройством, на котором запущено мобильное приложение, может извлечь токен авторизации для автоматизации запросов к серверу API. Другой метод, используемый злоумышленниками, - это создание поддельного портала для бесплатного Wi-Fi (аэропорты, вокзалы и другие общественные места), где они обманывают, кто входит в систему, чтобы установить собственный сертификат ssl на своем мобильном устройстве, чтобы злоумышленник мог расшифровать трафик https, таким образом крадя авторизационные токены и выполняя автоматические запросы к серверу API от имени пользователя.
Реализация обеих стратегий
Моя текущая идея состоит в том, чтобы реализовать обе стратегии, но разрешить авторизацию токена только в том случае, если источник отсутствует, и разрешить аутентификацию сеанса / cookie только в том случае, если заголовок источника присутствует и разрешен политикой CORS.
Это может быть легко обойдено и автоматизировано атакующим. Таким образом, злоумышленник будет
делать запросы только с украденным токеном и без использования источника в
Заголовки запроса, таким образом избегая безопасности для сети и обходя те
для мобильного приложения.
Предложения
Но я теперь эксперт в этом вопросе, и мог бы легко что-то неправильно понять. Любые предложения или дальнейшие объяснения будут очень приветствоваться:)!
Я рекомендую вам прочитать эту серию статей о технологиях безопасности Mobile API, которые помогут вам лучше понять, как защитить API. В этой статье мы увидим, как API-ключи, HMAC, закрепление сертификатов, OAUTH могут использоваться для защиты API, а также как их можно обойти. В то время как в рамках мобильного API некоторые из методов являются действительными в контексте веб-приложения.
Для Интернета:
Используйте заголовок «Строгая транспортная политика», чтобы гарантировать, что ваше веб-приложение всегда загружается через https.
Ваше веб-приложение должно использовать CSP (Content Security Policy) с службой отчетов , которая в режиме реального времени сообщит вам, когда какая-либо из политик будет нарушена.
Если вы используете куки, вы должны включить флаг httpOnly, чтобы защитить их от
Доступ через Javascript. Более того, вы хотите включить флаг безопасности для файлов cookie, которые будут отправляться только при подключении через https. Также попробуйте указать файлы cookie по пути, по которому они
принадлежат, т. е. файлы cookie для страницы входа должны быть ограничены путем /login,
поэтому они не будут отправлены для других страниц или ресурсов (изображений, CSS и т. д.) веб-приложения.
Добавьте recAptcha V3 на все страницы вашего веб-приложения. Он работает в фоновом режиме без какого-либо взаимодействия с пользователем и дает оценку от 0 до 1, где к 1 мы более уверены, что это человек, который делает запрос.
Цитирование Google:
Мы рады представить reCAPTCHA v3, который поможет вам обнаружить злоупотребления трафиком на вашем сайте без каких-либо проблем со стороны пользователя. Он возвращает оценку, основанную на взаимодействиях с вашим веб-сайтом, и предоставляет вам больше возможностей для принятия соответствующих действий.
Этот счет позволит иметь некоторую степень уверенности в блокировании не человеческого трафика. Если вам нужно больше уверенности, вы можете использовать также решения для анализа поведения пользователей (UBA), которые могут использовать машинное обучение и искусственный интеллект для дальнейшего анализа входящего трафика и обнаружения злоупотребления трафиком. Из-за того, как работает интернет, reCaptcha V3 и UBA не могут предоставить пуленепробиваемые решения для аутентификации запросов как законных.
Для мобильных приложений:
Используйте решение для аттестации мобильных приложений, чтобы сервер API мог знать, что он получает запросы только от подлинного мобильного приложения.
Роль службы аттестации мобильных приложений заключается в том, чтобы во время выполнения гарантировать, что ваше мобильное приложение не было взломано или не работает на корневом устройстве, запустив SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке. чтобы подтвердить целостность мобильного приложения и работающего устройства.
При успешной аттестации целостности мобильного приложения выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке. В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Поскольку секретный ключ, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно восстановить его во время выполнения, даже когда приложение подделано, работает на корневом устройстве или осуществляет связь через соединение, которое быть целью человека в средней атаке.
Сервис аттестации мобильных приложений уже существует в качестве решения SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.
Возможное решение
Итак, моя проблема в том, как мне реализовать безопасную аутентификацию для обоих приложений?
Для веб-приложения:
- OpenID или OAUTH2 как для мобильного, так и для веб-приложения, а также, возможно, использование файла cookie для хранения токена аутентификации в рамках URL-пути с включенным httpOnly и флагом безопасности.
- Далее используйте строгие политики CSP наряду с CORS, CSFR, Строгой транспортной политикой и любыми другими, которые я могу пропустить.
- Google reCaptcha V3.
Для мобильного приложения:
- OpenID или OAUTH2.
- Решение для аттестации мобильных приложений.
- Сертификат закрепления.
API будет принимать только запрос, содержащий заголовок с токеном reCaptcha V3 или с токеном JWT аттестации мобильного приложения. Любые другие запросы должны быть отклонены.
В случае веб-приложения для продолжения запроса, оценка recCaptcha V3 (от 0 до 1,0) должна давать уверенность в том, что запрос поступил от человека, может быть больше 0,9? Вам нужно будет поиграть со значением и контролировать его, чтобы найти правильный баланс.
Чтобы запрос от мобильного приложения мог продолжить обработку, сервер API должен проверить, что токен JWT имеет действительную подпись и срок ее действия не истек.
Хотя веб-запросы проверяются наилучшим образом, запросы, поступающие из мобильного приложения, защищенного службой мобильной аттестации, имеют только 2 возможных результата, действительных или недействительных.