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

Question

[German Zvonchuk]

Друзья,

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

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

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

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

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

Я понимаю что на все 100% защитить API от использования вне приложений невозможно, моя задача чуть-чуть усложнить этот процесс, чтобы при помощи сниффера (charles) не могли узнать адреса и использовать их.

Answer 1

[Denis Kiselev]

Давайте рассмотрим вопрос чуть поструктурнее.

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

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

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

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

Comments

[Юрий]

Имхо, лучший вариант - плановый выпуск обновления приложения с заменой ключа

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

Answer 2

[forspamonly2]

https с pinned серверным сертификатом и аутентификация клиента по клиентскому сертификату.

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

Answer 3

[bro-dev]

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

Answer 4

[Сергей Горностаев]

https + app_key

Comments

[German Zvonchuk]

При помощи снифера я получу всю информацию отправляемую на API:

• URL
  
• HTTP HEADERS
  

скопирую все к себе и буду обращаться к API откуда угодно :=)

[sim3x]

inside22, https://stackoverflow.com/questions/187655/are-htt...

[awesomer]

При помощи снифера я получу всю информацию отправляемую на API:

URL
HTTP HEADERS

скопирую все к себе и буду обращаться к API откуда угодно :=)

по httpS же - ты получишь только имя сервера.

[Saboteur]

При помощи снифера я получу всю информацию отправляемую на API:

URL
HTTP HEADERS

Но не HTTPS headers.

[German Zvonchuk]

Saboteur, awesomer, sim3x друзья, проблема заключается в том, что можно через прокси (Charlie for iOS) прослушать все данные, потому что прокси подделает сертификат и свободно прочитает все данные спрятанные в HTTP HEADERS.

[Сергей Горностаев]

inside22, какое отношение менеджер контактов имеет к прокси? Каким образом можно подделать сессионный ключ асимметричного шифрования? Но самое главное, почему тоталитарным диктатурам этот метод недоступен и им приходится применять тупые методы типа MITM и навязывания установки их CA в доверенные?

[sim3x]

inside22, при нормальной настройке - нет

[Saboteur]

inside22, Поддельный сертификат сразу отобразится в заголовке браузера.
Если вы не добавили сертификат от этого прокси себе в доверенные сертификаты, то незаметно это не делается.

[Odissey Nemo]

Сергей Горностаев, возможно, потому, что тайные диктатуры уже заложили такие бэкдуры для себя, а вторичным и тоталитарным не дают этим воспользоваться. Впрочем, как и всеми другими своими реальными технологиями. Вот и приходится бедолагам выкручиваться, при этом являясь вторичными к тайным диктатурам, и оттягивая праведный гнев населения на себя. Оттого и так много платят этим самым диктатурам, в валютах тайных, естественно. За унижение платят.

[Сергей Горностаев]

odissey_nemo, то есть German Zvonchuk может тайно перехватывать HTTPS трафик, а спецслужбы РФ нет. Интересно получается.

[Odissey Nemo]

Сергей Горностаев, это же лениво, да и не нужно, на самом то деле. Денег не несёт, революции не предвидится. Так для чего трудиться? Это Звончук ещё не понял, что буря страстей бурлит в стакане воды, вот и интересуется))

Answer 5

[xmoonlight]

Здесь подробно всё описано.

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

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

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

На сервере API - логируем все ошибки авторизации.
При их появлении - выпускаем новый клиент с новым открытым/публичным серверным ключом и новой логикой формирования токена.

Answer 6

[devalone]

Если кратко, - никак, т.к. любую защиту можно обойти, а реверсить андроид приложения очень просто.
А так, часто используют подпись запросов, в идеале алгоритм подписи должен быть написан на компилируемом языке вроде C++. Ещё к запросу нужно добавлять timestamp, чтоб нельзя было просто отправлять запросы тупо скопировав пакет снифером. Также можно обфусцировать API, чуть усложняя его использование. Но что не делай - обойти это всё можно.

Answer 7

[Алексей]

Предлагаю использовать Google Cloud Messaging (GCM).

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

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

Answer 8

[Stanislav Pugachev]

https://jwt.io/

Comments

[bro-dev]

без авторизации пользователя