Как ограничить AJAX API от нежелательного использования (например, кто выполняет SELECT *)

У меня есть веб-приложение для поиска ресторанов, которое объединяет расположение ресторанов с Google Maps.

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

Эти ползунки JQuery вызывают через AJAX API-интерфейс, который я создал для обновления карты без обновления веб-страницы.

JQuery вызывает RESTFUL API следующим образом:

http://example.com/search/?city=NYC&max-price:50&cuisine=french

Это возвращает строку ресторанов JSON, которые соответствуют этому критерию, так что мое веб-приложение может отображать на карте все рестораны, которые соответствуют поисковому запросу.

Чего я не хочу, чтобы это произошло, так это того, чтобы кто-то пришел и выяснил мой API и выкинул ВСЕ списки моих ресторанов.

Есть ли способ, которым я могу ограничить, кто вызывает вышеупомянутый HTTP API, так, чтобы только мой веб-сервер вызывал URL, а не спамер / хакеры, желающие сбросить мою базу данных?

Спасибо

13.10.2009 05:04:33
Вы можете записать, кто они на стороне сервера, и обрабатывать только один запрос дампа от пользователя каждые X секунд.
Robert Massaioli 13.10.2009 05:08:46
Это сообщение похоже на то, что я спрашиваю -> stackoverflow.com/questions/856045/how-to-restrict-json-access
JacobT 13.10.2009 05:13:25
2 ОТВЕТА

Все большие REST API, как правило, используют токенизированную аутентификацию - в основном, прежде чем выполнить запрос REST, вы должны отправить какой-то другой запрос в службу токенов, чтобы получить токен для включения в ваш запрос данных. Bing Maps делает это, Amazon делает это, Flickr делает это ... и т. Д.

Я не слишком много знаю об этом, кроме того, что работал с Bing Maps. Вам нужно будет прочитать о токенизированной аутентификации с помощью REST. Вот сообщение в блоге, с которого можно начать: http://www.naildrivin5.com/daveblog5000/?p=35

3
13.10.2009 05:29:16

Сначала заявите о своих намерениях robots.txt.

Затем отправьте заголовок Set-Cookie с одноразовым или каким-то уникальным идентификатором на главной странице, но не в своих ответах API. Если cookie никогда не отправляется на конечную точку вашего API, верните 401 Bad Requestответ, потому что это бот, очень сломанный браузер или кто-то отклоняет ваши cookie. Заголовок Referer также можно использовать в качестве дополнительной проверки, но подделать его тривиально. Отслеживайте, сколько вызовов API было сделано с этим идентификатором. Вы также можете сопоставить идентификаторы с IP-адресами. Если оно превысит ваш порог, наплевать на 403 Forbiddenответ. Сделайте свой порог достаточно высоким, чтобы законные пользователи не попали под него.

Ведите хорошие журналы и выделите 401 и 403 ответов.

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

  • Такое поведение нарушает условия обслуживания.
  • Вы активно пытаетесь предотвратить это.
  • Вы знаете, что преступник существует и примерно кто они.
  • Страшные адвокаты могут начать вмешиваться, если это продолжится.

(У вас есть адвокат, верно?)

Чтобы достичь этого, убедитесь, что тело вашего 403 Forbiddenответа передает страшно звучащее сообщение в виде строки «Этот запрос превышает максимально допустимое использование API. Ваш IP-адрес был зарегистрирован. Пожалуйста, ознакомьтесь с условиями обслуживания и подчиняйтесь директивам». в robots.txt«.

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

Я не поощряю использование назначенных API-ключей / токенов, потому что они оказываются препятствием для принятия и своего рода болью в шее, с которой приходится справляться. В качестве контраргумента ответа @ womp, Google постепенно отходит от их использования. Кроме того, я не думаю, что они на самом деле применимы в этом случае, потому что похоже, что ваш «API» больше похож на вызов JSON, который используется в основном на вашем собственном сайте.

10
13.10.2009 19:38:19
Заголовок HOST тоже очень легко подделать?
Jack Marchetti 11.04.2014 03:02:52