Как предотвратить прямой доступ к моему сервису JSON?
У меня есть веб-сервис JSON для возврата домашних маркеров, которые будут отображены на моем Google Map.
По существу, http://example.com называет веб-сервис для обнаружения местоположения всех маркеров карты для отображения как так:
http://example.com/json/?zipcode=12345
И это возвращает строку JSON, такую как:
{"address": "321 Main St, Mountain View, CA, USA", ...}
Таким образом на моем index.html страница, я беру это, JSON представляют в виде строки и помещают маркеры карты.
Однако то, что я не хочу иметь, происходят, является людьми, обращающимися к моему веб-сервису JSON непосредственно.
Я только хочу http://example.com/index.html смочь назвать мой http://example.com/json/ веб-сервис... и не некоторый случайный чувак, звонящий /json/ непосредственно.
Quesiton: как я предотвращаю непосредственный вызов / доступ к моему http://example.com/json/ веб-сервис?
ОБНОВЛЕНИЕ:
Дать больше ясности, http://example.com/index.html звонить http://example.com/json/?zipcode=12345 ... и сервис JSON
- полууязвимые данные возвратов,
- возвращает массив JSON,
- отвечает для ПОЛУЧЕНИЯ запросов,
- браузеру, выполняющему запрос, включили JavaScript
Снова, что я не хочу иметь, происходят, люди, просто смотрят на мой index.html исходный код и затем называет сервис JSON непосредственно.
5 ответов
Принимать только POST-запросы к URL-адресу, генерирующему JSON. Это не помешает решительным людям добраться до него, но предотвратит случайный просмотр.
Если вы используете Apache, вы можете разрешить / запретить для местоположений.
http://www.apachesecurity.net/
или вот ссылка на документацию apache по директиве Deny
http://httpd.apache.org/docs/2.0/mod/mod_access. html # deny
РЕДАКТИРОВАТЬ (в ответ на новую информацию).
Директива Deny также работает с переменными окружения. Вы можете ограничить доступ на основе строки браузера (не совсем безопасно, но не поощряет случайный просмотр), которая по-прежнему разрешает вызовы XHR.
Я бы посоветовал лучший способ добиться этого - иметь какой-то токен, который проверяет, является ли запрос «хорошим». Вы можете сделать это с помощью файла cookie, какого-либо хранилища сеансов или параметра (или некоторой комбинации).
Для чего-то подобного я бы посоветовал создать уникальный URL-адрес службы, срок действия которой истекает через короткий промежуток времени. Вы можете легко сделать что-то подобное с Memcache. Эту стратегию также можно использовать для обфускации URL-адреса службы (что не обеспечит никакой реальной безопасности, но повысит планку для тех, кто хочет совершать прямые звонки).
Наконец, вы также можете использовать для этого шифрование с открытым ключом, но это будет очень сложным. Вам нужно будет сгенерировать новую пару ключей pub / priv для каждого запроса и вернуть pubkey клиенту js (вот ссылка на реализацию в javascript) http://www.cs.pitt.edu/~ kirk / cs1501 / notes / rsademo /
Возможно, вам потребуется какая-то аутентификация на основе файлов cookie. Кроме того, Игнасио хорошо разбирается в использовании POST. Это может помочь предотвратить перехват JSON , если в вашем домене запущены ненадежные скрипты. Однако я не думаю, что использование POST строго необходимо, если только внешний тип JSON не является массивом. В вашем примере это объект.
Здесь есть более конкретные ответы, но я Я хотел бы отметить следующее общее замечание:
Все, что делается через AJAX, загружается браузером пользователя. Вы могли бы усложнить жизнь хакеру, если бы захотели, но, в конечном счете, нет никакого способа помешать мне получить данные, которые вы уже бесплатно предоставляете мне .Любая общедоступная услуга является общедоступной, простой и понятной.
Есть несколько хороших способов аутентификации клиентов.
- По IP-адресу. В Apache используйте директивы Allow / Deny.
- По HTTP-аутентификации: базовая или дайджест. Это красиво и стандартизировано, и для аутентификации используются имена пользователей и пароли.
- С помощью файлов cookie. Вам нужно будет придумать печенье.
- С помощью придуманного вами собственного HTTP-заголовка.
Редактировать:
Сначала я не заметил, что ваш веб-сервис вызывается клиентским кодом. Буквально НЕВОЗМОЖНО запретить людям обращаться к вашей веб-службе напрямую, если вы позволите Javascript на стороне клиента сделать это. Кто-то мог просто прочитать исходный код.