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

Друзья,

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

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

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

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

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

Я понимаю что на все 100% защитить API от использования вне приложений невозможно, моя задача чуть-чуть усложнить этот процесс, чтобы при помощи сниффера (charles) не могли узнать адреса и использовать их.
  • Вопрос задан
  • 1505 просмотров
Решения вопроса 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
Похожие вопросы
PiRL Ventures Москва
от 180 000 до 220 000 руб.
от 2 500 до 4 000 usd.
17 дек. 2018, в 01:36
700 руб./в час
16 дек. 2018, в 22:06
700 руб./в час
16 дек. 2018, в 21:48
1000 руб./за проект