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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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