Защита MY REST API для использования только с MY IOS APP

Я разрабатываю REST API в Laravel для использования с моим приложением ios. В настоящее время я застрял в следующем: как защитить мой REST API, чтобы разрешить доступ ТОЛЬКО к моему приложению ios?

Я прочитал о базовой аутентификации HTTP, HMAC, oAuth2.

1) Для обычной аутентификации требуется SSL, и вам необходимо отправлять имя пользователя: пароль при каждом вызове API.

  • Но это не мешает другим использовать API из других приложений, если они отправляют свои учетные данные для входа в конечные точки?

2) Я понимаю метод HMAC и то, как клиент & Сервер оба знают о Публичной & Закрытый ключ Закрытый ключ шифруется вместе с запросом и другими данными. Открытый ключ отправляется в заголовках. Когда сервер получает запрос, он обнаруживает открытый ключ в заголовках и связывает его с закрытым ключом в БД. Затем он пересчитывает хэш и проверяет, совпадает ли он. Итак, у меня есть следующие вопросы:

  • Как только что зарегистрированный пользователь получает закрытый ключ для хранения в приложении IOS, если закрытый ключ не нужно отправлять по проводам?
  • Это больше ориентировано на приложения, которые будут использовать ваше приложение? Обычно я вижу это на панели инструментов API, такой как Instagram & Facebook, где тебе дают секретный ключ приложения, верно?

3) oAuth2 - для меня это больше похоже на то, что люди могут входить в мое приложение, используя другой API. Например, разрешить пользователям входить в мое приложение с помощью FB и разрешить моему API использовать данные Facebook? Мне на самом деле не нужно делать это в данный момент.

  • я неправильно понял это?

Звучит так, будто мне нужно включить что-то похожее на метод HMAC, предоставив моему приложению IOS закрытый ключ, где я храню его в своем коде приложения IOS. Когда запрос запускается из приложения ios, я передаю хэш с закрытым ключом и другими данными, а затем, когда запрос принимается на сервере, я определяю, пришел ли запрос от пользователя в приложении, путем пересчета хеша. Я понятия не имею, если это безопасно & Я бы предположил, что это не так?

Каких знаний мне не хватает? Я так растерялся, что написание этого вопроса было большой борьбой. Я пересмотрю его, как только все станет яснее.

7 голосов | спросил Alex Lacayo 21 +04002014-10-21T14:00:46+04:00312014bEurope/MoscowTue, 21 Oct 2014 14:00:46 +0400 2014, 14:00:46

1 ответ


0

1. Вы правы, это не мешает неподтвержденным клиентам.

2. На самом деле это не способ предотвратить неутвержденные клиенты, это скорее проверка того, что сообщение не было подделано по сети.

3. Вы правильно понимаете oAuth, речь идет о проверке подлинности клиентов для использования вашего API особым образом, а также об ограничении разрешений.

На самом деле невозможно заблокировать ваш API, поэтому его может использовать только конкретный клиент, потому что нет способа проверить, кто на самом деле является клиентом. Кроме того, любая форма аутентификации или проверки, выполненная на стороне клиента, может в конечном итоге быть подвергнута обратному проектированию, а затем может быть отправлена ​​на сервер в качестве «одобренного» клиента.

Нечто подобное можно сделать с помощью токена. Сервер отправляет токен клиенту, клиент выполняет некоторую известную операцию над токеном, такую ​​как соление и хеширование, с известной операцией соли и хеша, а затем возвращает токен в prove клиент настоящий.

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

Еще один способ это сломать, если кто-то может MiTM ваш запрос. Запрос может быть захвачен и изменен до того, как он достигнет сервера, и на самом деле нет никаких способов предотвратить это, кроме использования SSL, который может быть нарушен чем-то вроде SSLStrip.

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

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

ответил Adam 21 +04002014-10-21T14:43:45+04:00312014bEurope/MoscowTue, 21 Oct 2014 14:43:45 +0400 2014, 14:43:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132