Как защитить Rest API от использования третьими лицами?

Друзья,

есть Rest API которое используется в мобильных приложении iOS и Android.

Данное API работает без авторизации пользователя.

Задача состоит в том, чтобы защитить API от использования его вне мобильного приложения. Чтобы ни кто не забирал данные прямиком из API.

Какие есть варианты?

Генерировать на сервере и в мобильном приложении OTP-код и в мобильном приложении подписывать им все запросы к API?

Я понимаю что на все 100% защитить API от использования вне приложений невозможно, моя задача чуть-чуть усложнить этот процесс, чтобы при помощи сниффера (charles) не могли узнать адреса и использовать их.
  • Вопрос задан
  • 1383 просмотра
Решения вопроса 2
deksden
@deksden
Enterpreneur
Давайте рассмотрим вопрос чуть поструктурнее.

Несанкционированное использование неофициальным клиентом - значит пытаемся защитить клиента.

Https с ключом к API защитит только от тривиального перехвата трафика сниффером (mitm).

Если расковыряют приложение и достанут идентификационный ключ для подписания запросов - будет проблема. Тут уже включаем защиту от «расковыривания». Имхо, лучший вариант - плановый выпуск обновления приложения с заменой ключа, и, возможно, внесением определенных изменений в хранение этого ключа (чтобы взлом клиента требовал определенного времени). Когда то народу надоест ломать.

Если ломать не надоело - то следует задуматься над причинами: почему кому то так хочется иметь неофициальный клиент к вашему api. Тут будет проще договорится - или продолжить играть в мечи и щиты.
Ответ написан
@forspamonly2
https с pinned серверным сертификатом и аутентификация клиента по клиентскому сертификату.

тогда сниффер уже не поможет и придётся расковыривать саму софтину. разумеется, если будет надо кому - выковыряют без проблем.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
bro-dev
@bro-dev
Проблема скорее всего не в том что левые люди будут использовать, а в злоупотреблении, но тоже самое можно делать и прямо из вашей проги, так что лучшее решение сделать публичное апи но внести количественные и частотные ограничения.
Ответ написан
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
https + app_key
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Здесь подробно всё описано.

Данное API работает без авторизации пользователя.
В качестве "прозрачной" (для пользователя) авторизации приложения (на серверном API), на клиенте - используем два параметра для формирования запрашивающего токена авторизации: идентифицирующую устройство информацию и публичный серверный ключ.

Токен: ID-устройства (или любую идентифицирующую информацию мобильного устройства) мы шифруем открытым/публичным ключом сервера, хранящимся в приложении.

На сервере API - логируем все ошибки авторизации.
При их появлении - выпускаем новый клиент с новым открытым/публичным серверным ключом и новой логикой формирования токена.
Ответ написан
devalone
@devalone
̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻
Если кратко, - никак, т.к. любую защиту можно обойти, а реверсить андроид приложения очень просто.
А так, часто используют подпись запросов, в идеале алгоритм подписи должен быть написан на компилируемом языке вроде C++. Ещё к запросу нужно добавлять timestamp, чтоб нельзя было просто отправлять запросы тупо скопировав пакет снифером. Также можно обфусцировать API, чуть усложняя его использование. Но что не делай - обойти это всё можно.
Ответ написан
@Stqs
senior software developer
Предлагаю использовать Google Cloud Messaging (GCM).

Устройство регистрируется в GCM, получает registrationId – токен, – сохраняет его у себя локально и передает вашему серверу. Далее пуш-сервер использует этот registrationId для отправки сообщений вашему приложению на этом устройстве. В сообщении передайте сгенерированную на сервере строку. Эту строку приложение должно вернуть серверу. И только после совпадения строк разрешаете для этого устройства доступ к API.

Таким образом доступ к API будет только у вашего приложения. Даже, если кто-то расковыряет приложение, или создаст его клон, то оно не пройдёт валидацию и не сможет получать ваши push'и. Ни менять API, ни шифровать запросы/ответы, ни переходить на https и т.п. вам в таком решении не потребуется.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы