защита доступа к REST-API через мобильное приложение без входа

Question

Я хочу получить безопасный доступ к REST API (.net) через мобильное приложение (act-native), у которого нет логина, но пользователь создается в фоновом режиме с уникальным идентификатором при первом запуске приложения.

клиентское приложение - которое можно идентифицировать по некоторому UID.

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

Какова была бы лучшая практика для защиты этого бэкэнда? Я не хочу защищаться с помощью логина / пароля (поскольку клиенту не нужно «входить в систему» ​​для получения списков), однако я бы не хотел, чтобы кто-либо легко вызывал этот бэкэнд-API и получал эти списки для своих собственных цели.

Спецификация: приложение не имеет логина. так как я могу получить токен для первого использования и сделать API безопасным.

REST API: безопасный отдых API с именем пользователя и паролем.

Мобильное приложение: отправляйте имя пользователя и пароль при каждом вызове API остальных.

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

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

Answer 1

Это выглядит очень похоже на ваш вопрос Аутентификация REST API для мобильных приложений iOS и Android несколько дней назад.

1) Похоже, авторизация пользователей не является главной проблемой здесь, но я бы определенно рекомендовал OAuth2 многократно отправлять имя пользователя и пароль.Это хорошо понято, и есть как открытые, так и бесплатные коммерческие реализации.На мобильных устройствах PKCE очень важен для предотвращения атак перехвата кода авторизации.

2) Использование HTTPS для вызовов REST API - это само собой разумеющееся, но я бы посоветовал вам закрепить и эти соединения.Злоумышленник может легко скомпрометировать мобильное устройство и, в противном случае, стать посредником в вызовах API.Пиннинг сложно для React Native;взгляните на пакет act-native-cert-pinner npm и / или прочитайте Укрепление TLS в React Native с помощью закрепления сертификатов (Android) или iOS .

3) Использование статических ключей API будет практически невозможно защитить.Если вы также используете OAuth2, PKCE не остановит атаку олицетворением, и особенно если вы идентифицируете пользователей с доверием при первом использовании, вы будете очень уязвимы к атакам ботов.На один шаг лучше, чем ключи API, было бы подписывать ваши вызовы API, используя ваш ключ API.Таким образом, по крайней мере, ваш ключ API не виден в самом вызове API.Вам нужно добавить некоторую энтропию, чтобы предотвратить повторные атаки, и запутывание вашего ключа API в приложении имеет решающее значение.Более того, используйте некоторую форму аттестации приложения, которая полностью удаляет ключ API из приложения.Для React Native см. Первые опыты с React Native: соединение собственного модуля Android для аутентификации приложений или аналогично для iOS , чтобы получить представление об этом подходе.

Answer 2

Вы не можете избежать того, чтобы люди перепроектировали и получили ваш API-ключ (или комбо-код пользователя / пароля).Вы можете сделать это сложнее, например, применяя HTTPS с закреплением сертификата во время связи с вашим сервером или применяя ограничение скорости API на основе IP, так что люди не могут легко шпионить за связью или сбрасывать все, что ваш API возвращает массово, но вы не можете сделатьэто невозможно.Ожидайте, что люди всегда будут иметь те же привилегии, что и ваше приложение (на их устройстве).В вашем случае это означает, что злоумышленник может также генерировать неограниченные идентификаторы UID, поскольку они генерируются по запросу клиента.Это делает использование UID для любой серьезной аутентификации довольно бесполезным.

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