Как запретить произвольным клиентским приложениям использовать анонимный веб-API?

Извините, если об этом уже спрашивали и отвечали; Я осмотрел кучу, но не нашел точно, что я прошу.

-

  • Предположим, что мое веб-приложение в http://example.com/ использует частный и недокументированный веб-API на http://api.example.com/ для получения данных, например через XHR или JSONP.

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

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

В таком случае, как вы можете запретить кому-либо использовать ваш API в клиентском приложении не в Интернете? Например. приложение для iPhone или на стороне сервера.

Насколько я понимаю, пункт №2 удаляет вариант чего-то вроде OAuth, а точка № 3 удаляет вариант, например. API или даже SSL.

Я думал о таких вещах, как маркеры на основе времени или секретные соли, которые вводятся на страницу при первой загрузке, но приложение для iPhone может просто просто тайно загружать вашу веб-страницу, прежде чем делать запросы API.

Так что есть какой-то способ, кроме простой обфускации — безопасность через неясность?

-

Если все это слишком абстрактно, вот простой пример:

Google.com извлекает свои автоматически заполненные данные через некоторый API, который является частным и недокументированным — но открываются в Интернете. Что мешает мне использовать его в своем iPhone-приложении?

Ответы

Ответ 1

Вы не можете запретить людям копировать код клиента или воспроизводить сетевой трафик.

Благодаря той же политике происхождения, другие веб-приложения не могут получить доступ к вашему API от клиента. Они должны будут проксировать свои запросы через сервер, то есть эти запросы будут поступать из нескольких легко идентифицируемых IP-адресов, которые вы можете временно занести в черный список.

Что касается настольных и мобильных приложений, вы не можете много сделать. Мой совет - не беспокоиться о них, пока они не станут проблемой.

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

Ответ 2

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

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

Ответ 3

Без ключа API или какой-либо формы авторизации вы будете бороться с проигранным сражением, пытаясь не допустить несанкционированных клиентов.

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

Вы управляете другим веб-сервисом? Кроме того, если ваше веб-приложение (http://example.com/) обращается к API (http://api.example.com/) через XHR или JSONP, вы можете проксировать данные на своем сервере, используя библиотеку, такую ​​как cURL, чтобы получить данные, а затем сделать ее доступной на твой сайт. Затем вы можете контролировать доступ к нему любым удобным вам способом.

Ответ 4

Если у вашего клиента есть код, который скрыт от snoopers, не могли бы вы сделать то, что вы предлагали, использовать соли, ip-адрес и значения времени, зашифровать их и затем сделать то же самое на сервере? Это в основном то, что делает mod_auth_tkt, и оно работает хорошо. Или это будет проверка подлинности?