#android #security #webserver
#Android #Безопасность #веб-сервер
Вопрос:
Я пишу приложение для Android, которое не будет доступно в магазине Google Play. Я изучаю, как я могу выполнить проверку того, что любой пользователь приложения действительно является верифицированным пользователем.
Я хотел бы использовать сервер для этого процесса, который приложение использует в любом случае для отправки / получения данных. Моя идея заключалась в создании чего-то вроде challenge, который могли бы пройти только проверенные клиенты. Таким образом, любой, кто использует поддельное приложение, не сможет обойти это.
Существует ли какой-либо стандартный подход к этой проблеме? Я немного поискал, но не нашел ничего, что полностью охватывало бы это. Пожалуйста, имейте в виду, что я осознаю тот факт, что, учитывая тот факт, что приложение работает на телефоне Android, который является устройством вне моей досягаемости, вероятно, всегда найдутся способы обойти проблемы. Я хочу посмотреть, что делает большинство в этих случаях.
Комментарии:
1. Это невозможно, вы не можете аутентифицировать приложение. Все, что может быть в приложении, доступно пользователям для создания другого приложения.
2. значит, это невозможно сделать?
3. Не таким образом, который можно было бы считать достаточно безопасным, если под безопасным вы подразумеваете, что невозможно (или, по крайней мере, очень сложно) создать «поддельное» приложение. Вы можете несколько усложнить его, но решительные злоумышленники всегда смогут это сделать. Хитрость в том, что в 99,99% случаев они на самом деле этого не хотят.
4. Так что же на самом деле делают крупные компании, чтобы бороться с поддельными приложениями?
5. Они публикуют отличные приложения, которые никто не может превзойти по разумной цене, в основном. Также они добавляют юридические положения, я думаю, чтобы они могли принять меры, если кто-то предпринял честную попытку в другом приложении.
Ответ №1:
Здесь возможны две проблемы. Первый — это аутентификация пользователя (authn) и авторизация (authz), а второй — проверка подлинности самого клиентского приложения.
Для аутентификации пользователя / authz я бы использовал некоторую форму OAuth2 с OpenID / Connect. Конечным результатом является то, что вы разрешаете своему клиентскому приложению получать доступ к вашим конечным ресурсам от имени пользователя. Для начала доступны сервисы с открытым исходным кодом и бесплатные коммерческие сервисы.
Более проблематичной является аутентификация самого приложения. Ключи API являются стандартным подходом здесь, но это статические секреты, которые не приносят большой пользы, если приложение подделано или ключ обнаружен в канале связи. Независимо от того, как сильно вы пытаетесь скрыть или вычислить секрет по мере необходимости, если ваша конечная точка достаточно ценна, кто-то выполнит работу, необходимую для извлечения и злоупотребления секретом, а затем вашим бэкэндом.
Вы на правильном пути, думая о какой-либо форме протокола запроса-ответа. Капчи здесь являются каноническим подходом, но они довольно раздражают пользователей мобильных приложений и не всегда очень эффективны. Я считаю (и, полное раскрытие, моя компания тоже), что подтверждение подлинности приложения с помощью криптографически защищенной проверки является надежной стратегией. Служба подтверждения запрашивает приложение и анализирует его ответ. Задача оценивает, был ли изменен код приложения, и оценивает состояние среды выполнения (внедрено ли приложение? выполняется в отладчике? присутствуют такие фреймворки, как frida или xposed? и т.д.). Приложению выдается токен с коротким сроком службы, правильно подписанный, если проверка прошла успешно, недействительный в противном случае. В приложении нет секрета, и приложение не принимает решение об аутентификации; оно просто передает токен вашему серверному интерфейсу, который проверяет время жизни токена и подпись, чтобы определить подлинность приложения. Нет токена или недопустимый токен, и вы знаете, что это бот или подделанное приложение.
Для получения информации о подлинности пользователя и приложения ознакомьтесь с сообщением в блоге из 3 частей, начиная с методов обеспечения безопасности мобильного API, или, если вы предпочитаете видео, ознакомьтесь с обзором недостаточной защиты мобильного API. Я рекомендую вам также ознакомиться с approov.io о том, как это может быть реализовано как сервис.