Ограничить запросы API только моим собственным мобильным приложением

Есть ли способ ограничить количество запросов к моему REST API только запросами, поступающими из моего двоичного файла моего мобильного приложения? Это приложение будет распространяться в Google Play и Apple App Store, поэтому следует иметь в виду, что кто-то получит доступ к его двоичному файлу и попытается восстановить его.

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

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

Я открыт для любого эффективного решения, независимо от того, насколько сложно. Решения шляпы оловянной фольги очень ценятся.

Источник

8 ответов

Решение

Любые учетные данные, которые хранятся в приложении, могут быть предоставлены пользователем. В случае с Android они могут полностью декомпилировать ваше приложение и легко их извлекать.

Если соединение с сервером не использует SSL, их можно легко прослушать в сети.

Серьезно, любой, кто хочет получить полномочия, получит их, так что не беспокойтесь о том, чтобы их скрыть. По сути, у вас есть публичный API.

Есть некоторые подводные камни, и для управления публичным API требуется дополнительное время.

Многие публичные API по-прежнему отслеживают IP-адреса и внедряют tarpits, чтобы просто замедлять запросы с любого IP-адреса, который, по-видимому, нарушает работу системы. Таким образом, законные пользователи с того же IP-адреса могут продолжать работать, хотя и медленнее.

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

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

Другой вариант - зарегистрировать пользователей, чтобы при обнаружении злоупотреблений вы могли заблокировать учетные данные, а не IP-адрес.

Источник

Да, это публично

Это приложение будет распространяться в Google Play и Apple App Store, поэтому следует иметь в виду, что кто-то будет иметь доступ к его двоичному файлу и попытается его реконструировать.

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

Разница между КТО и ЧТО получает доступ к серверу API

Прежде чем погрузиться в вашу проблему, я хотел бы сначала развеять неправильное представление о том, кто и что обращается к серверу API. Я написал серию статей по API и безопасности мобильных устройств, а также в статье " Зачем вашему мобильному приложению нужен ключ API ?" вы можете подробно прочитать разницу между тем, кто и что обращается к вашему серверу API, но я извлечу здесь основные моменты:

, Что это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем сервере API с помощью такого инструмента, как Postman?

, Кто является пользователем мобильного приложения, которое мы можем аутентификации, авторизации и идентификации несколькими способами, например, с использованием OpenID Connect или oauth2 потоки.

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

Поэтому, если вы не используете аутентификацию пользователя в приложении, вам остается попытаться подтвердить, что делает запрос.

Мобильные приложения должны быть максимально простыми

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

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

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

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

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

Атаки во время выполнения

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

Все, что вы делаете во время выполнения для защиты запроса, который собираетесь отправить в свой API, можно реконструировать с помощью таких инструментов, как Frida:

Внедряйте свои собственные сценарии в процессы черного ящика. Подключайте любую функцию, шпионите за криптографическими API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите "Сохранить" и сразу увидите результаты. И все это без этапов компиляции и перезапуска программы.

Предлагаемые вами решения

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

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

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

Аппаратное хранилище ключей Android

Доступность доверенной среды выполнения в системе на кристалле (SoC) дает возможность устройствам Android предоставлять аппаратные надежные услуги безопасности для ОС Android, службам платформы и даже сторонним приложениям.

Хотя его можно победить, я все же рекомендую вам использовать его, потому что не все хакеры имеют набор навыков или готовы тратить на это время, и я бы рекомендовал вам прочитать эту серию статей о методах безопасности мобильных API, чтобы узнать о некоторые дополнительные / похожие методы по сравнению с описанными вами. В этой статье вы узнаете, как ключи API, токены доступа пользователей, HMAC и закрепление TLS можно использовать для защиты API и как их можно обойти.

Возможные лучшие решения

В настоящее время я вижу разработчиков, использующих Android SafetyNet для подтверждения того, что делает запрос к серверу API, но они не понимают, что оно не предназначено для подтверждения того, что мобильное приложение является тем, что делает запрос, вместо этого оно предназначено для подтверждения целостности устройства., и я более подробно отвечу на вопрос Android-эквивалент ios devicecheck. Так я должен его использовать? Да, вы должны, потому что это еще один уровень защиты, который в этом случае сообщает вам, что ваше мобильное приложение не установлено на корневом устройстве, если только SafetyNet не была обойдена.

Есть ли способ ограничить почтовые запросы к моему REST API только запросами, поступающими из моего собственного двоичного файла мобильного приложения?

Вы можете позволить серверу API иметь высокую степень уверенности в том, что он действительно принимает запросы только от подлинного двоичного файла приложения, реализовав концепцию аттестации мобильных приложений, и я описываю ее более подробно в этом ответе, который я дал на вопрос Как защитить API REST для мобильного приложения? , особенно разделы Защита API-сервера и Возможное лучшее решение.

Вы хотите пройти дополнительную милю?

В любом ответе на контрольный вопрос я всегда хотел бы сослаться на отличную работу фонда OWASP.

Для APIS

Топ-10 безопасности OWASP API

OWASP API Security Project стремится предоставить ценность разработчикам программного обеспечения и специалистам по оценке безопасности, подчеркивая потенциальные риски в небезопасных API-интерфейсах и показывая, как эти риски могут быть снижены. Чтобы способствовать достижению этой цели, OWASP API Security Project создаст и будет поддерживать документ "10 основных рисков безопасности API", а также портал документации для передовых методов создания или оценки API.

Для мобильных приложений

OWASP Mobile Security Project - 10 основных рисков

OWASP Mobile Security Project - это централизованный ресурс, предназначенный для предоставления разработчикам и командам безопасности ресурсов, необходимых для создания и поддержки безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски мобильной безопасности и обеспечить средства управления разработкой, чтобы уменьшить их влияние или вероятность использования.

OWASP - Руководство по тестированию мобильной безопасности:

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

Источник

Нет. Вы публикуете сервис с открытым интерфейсом, и ваше приложение, вероятно, будет взаимодействовать только через этот REST API. Все, что может отправить ваше приложение, может отправить и любой другой. Это означает, что единственный способ обеспечить безопасный доступ - это каким-то образом пройти аутентификацию, то есть сохранить секрет. Тем не менее, вы также публикуете свои приложения. Это означает, что любой секрет в вашем приложении также раскрывается. Вы не можете иметь это обоими способами; вы не можете ожидать, что вы раскроете свой секрет и сохраните его в секрете

Источник

Хотя это старый пост, я подумал, что должен поделиться обновлениями от Google в этом отношении.

Вы действительно можете убедиться, что ваше приложение Android вызывает API, используя API мобильной аттестации SafetyNet. Это добавляет небольшие накладные расходы на сетевые вызовы и предотвращает запуск вашего приложения на корневом устройстве.

Ничего подобного SafetyNet для iOS не нашел. Следовательно, в моем случае я сначала проверил конфигурацию устройства в своем API входа в систему и принял разные меры для Android и iOS. В случае iOS я решил сохранить общий секретный ключ между сервером и приложением. Поскольку приложения iOS немного сложно реверсировать, я думаю, что эта дополнительная проверка ключей добавляет некоторую защиту.

Конечно, в обоих случаях вам нужно общаться по HTTPS.

Источник

Вы ничего не можете сделать. потому что когда вы впускаете кого-то, они могут вызывать ваши API. максимум, что вы можете сделать, это как показано ниже:

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

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

даже подпись apk может быть издевана в некоторых сложных ситуациях, но это лучшее, что вы можете сделать.

Источник

Как показывают другие ответы и комментарии, вы не можете действительно ограничить доступ API только к вашему приложению, но вы можете принять различные меры, чтобы уменьшить количество попыток. Я считаю, что лучшее решение - это отправлять запросы к вашему API (конечно же, из собственного кода) с пользовательским заголовком, таким как "App-Version-Key" (этот ключ будет определен во время компиляции), и заставить ваш сервер проверять этот ключ на решить, должен ли он принять или отклонить. Также при использовании этого метода вы ДОЛЖНЫ использовать HTTPS/SSL, так как это снизит риск того, что люди увидят ваш ключ при просмотре запроса в сети.

Что касается приложений Cordova/PhoneGap, я буду создавать плагин для выполнения вышеупомянутого метода. Я обновлю этот комментарий, когда он будет завершен.

Источник

Кто-то смотрел Firebase App Check?

https://firebase.google.com/docs/app-check

Источник

Есть ли способ ограничить почтовые запросы к моему REST API только запросами, поступающими из моего собственного бинарного файла мобильного приложения?

Я не уверен, что есть абсолютное решение.
Но вы можете уменьшить количество нежелательных запросов.

Источник
Другие вопросы по тегам