Может ли Android подписать вызов http/https, чтобы однозначно идентифицировать приложение, выполняющее запрос?
Скажем, CORS для приложений. Ну, не то же самое, но...
Предположим, я загрузил приложение для воспроизведения в магазине, и теперь я хочу, чтобы мой сервер принимал только подключения из этого приложения.
Как мне это сделать?
Что я ожидаю от ОС, так это некоторый процесс, такой как добавление в мой http-запрос пары заголовков, указывающих идентификатор приложения на рынке, и подписание всего запроса подписью в цепочке Android -или на соответствующем рынке. ЦС сертификат цепочки. Тогда мой сервер может проверить, что запрос поступил от нужного приложения.
Кроме того, ОС может добавить некоторую сертифицированную информацию об оборудовании, поэтому, если приложение запускается в эмуляторе, я тоже могу отказать в обслуживании.
Конечно, другим способом может быть включение "секретного" в приложение, но оно всегда может быть перепроектировано декомпиляцией, не так ли? Или существует какое-то хранилище ключей, связанное с хранилищем воспроизведения, которое можно использовать для предоставления этого секрета во время запросов https на сервер?
Третий способ может заключаться в использовании поля azp для входа в систему OAuth, но, опять же, оно может быть скомпрометировано декомпиляцией, и, кроме того, оно заставляет пользователя войти в систему.
2 ответа
Предположим, я загрузил приложение для воспроизведения в магазине, и теперь я хочу, чтобы мой сервер принимал только подключения из этого приложения.
Как мне это сделать?
Для достижения наилучшего уровня безопасности между вашим приложением и сервером API вы должны использовать службу аттестации мобильных приложений вместе с решением SafetyNet, а также службу OAUTH2 и, наконец, закрепление сертификата для защиты канала связи между сервером API и мобильным приложением, так как рассмотрено в этой серии статей о методах Mobile API.
Роль службы аттестации мобильных приложений заключается в том, чтобы во время выполнения гарантировать, что ваше приложение не было взломано или не запущено на корневом устройстве с помощью SDK, встроенного в ваше приложение, и службы, работающей в облаке.
При успешной аттестации целостности приложения выдается токен JWT, который подписывается с секретом, о котором знают только сервер API вашего приложения и служба аттестации мобильных приложений в облаке.
В случае сбоя в Аттестации приложения JWT подписывается с секретом, который сервер API не знает.
Теперь приложение должно отправлять при каждом вызове API токен JWT в заголовках запроса. Это позволит серверу API обслуживать запросы только в том случае, если он может проверить подпись в маркере JWT и отклонить их в случае неудачной проверки.
Поскольку секрет, используемый службой аттестации мобильного приложения, не известен приложению, невозможно восстановить его во время выполнения, даже когда приложение подделано, работает на корневом устройстве или осуществляет связь через соединение, являющееся целью человека в середине атаки. Именно здесь этот вид услуг сияет в связи с решением SafetyNet.
В качестве дополнительного примечания, если ваше приложение взаимодействует напрямую со сторонними службами, то я предлагаю вам делегировать эту ответственность серверу API, что предотвратит несанкционированное использование ваших служб третьих сторон от вашего имени, если только оно теперь обслуживает только аутентичные запросы от Мобильное приложение, которое прошло испытания целостности.
Так почему бы не использовать только SafetyNet? Несмотря на то, что это хорошая функция безопасности, добавленная в Android, она не была разработана для использования в качестве единственной защиты вашего приложения, по словам самого Google:
Цель этого API - предоставить вам уверенность в целостности устройства, на котором выполняется ваше приложение. Затем вы можете получить дополнительные сигналы, используя стандартные API Android. Вы должны использовать API аттестации SafetyNet в качестве дополнительного сигнала всесторонней защиты как части системы защиты от злоупотреблений, а не как единственный сигнал защиты от злоупотреблений для вашего приложения.
Прежде чем я уйду, я хотел бы обратить внимание на следующее в решении SafetyNet:
Он является частью Google Mobile Services (GMS), поэтому работает только на устройствах, которые имеют это. На некоторых рынках, например, на Дальнем Востоке, существует значительное количество устройств, у которых этого нет.
Существует ограниченное количество аттестационных вызовов, которые можно сделать с помощью стандартного бесплатного API-ключа, поэтому для использования в масштабе (предположительно) потребуется платный уровень.
Он в первую очередь предназначен для проверки того, считается ли образ ОС, на котором работает конкретное устройство Android, безопасным и совместимым или нет. Таким образом, его можно рассматривать как довольно продвинутую корневую проверку, которая способна проверять изменения файловой системы, указывающие на корневые устройства.
Поскольку SafetyNet выполняет полный анализ хэшей образа ОС, он может быть довольно медленным (иногда несколько секунд). Это означает, что он не может работать непрерывно, и при его использовании требуется некоторая осторожность, чтобы скрыть эту задержку от пользователя, но без создания возможности для взлома.
SafetyNet специально не анализирует карту памяти запущенных приложений для обнаружения платформ инструментов (она основана на том факте, что они могут работать только на корневых устройствах), таких как XPposed и Frida.
SafetyNet предоставляет аттестацию работающего приложения с помощью функции apkDigestSha256. Однако на это можно положиться, только если сообщается о полной целостности. Это означает, что целостность приложения неизвестна, если оно работает на каких-либо необычных или рутированных устройствах. Некоторые пользователи рутируют свои устройства только для целей настройки, и если в мобильном приложении их значительный процент, то SafetyNet лишит их возможности использовать приложение. В этих сценариях мы хотим знать конкретно о целостности работающего приложения, а не о системе в целом. SafetyNet не может этого сделать, но служба аттестации мобильных приложений может.
Чтобы выполнить аттестационную проверку способом, который не может быть подделан, приложение не может выполнить свою собственную проверку (как, очевидно, этот код может быть подделан сам по себе). Таким образом, существует необходимость в реализации серверной части для надежного использования этой функции.
Используйте поток Аттестации сети безопасности, чтобы запросить секретный токен серверу.
После прочтения связанных вопросов, я думаю, уловка заключается в использовании потока безопасности сети:
- с помощью API аттестации SafetyNet приложение получает подписанный JSON от сервисов Android.
- приложение генерирует некоторый идентификатор из android_id, случайного uuid или обоих.
- И Id, и JSON отправляются на сервер, который затем может проверить, поступил ли запрос от реального приложения, сохранить данные идентификатора и конфигурации и согласовать токен для дальнейшей связи.
- используя API цепочки для ключей, приложение сохраняет идентификатор и токен в хранилище ключей для будущего использования
Это умозрительный ответ (я являюсь ОП), пожалуйста, голосуйте только в том случае, если вы уверены, что он правильный и лучшей альтернативы нет в списке.
Я думаю, что один из способов защитить ваш Backend состоит в том, чтобы прикрепить токен из приложения в заголовке (или что-то уникальное из вашего приложения), чтобы никто не мог вызвать API, если он не присоединяет токен в заголовке. Но вы должны проверить это в бэкэнде, чтобы убедиться, что заголовок содержит необходимый действительный токен.