Как Google Maps защищают свой ключ API? Как сделать что-то подобное?

сам ключ API, скорее всего, является односторонним хэшем домена, с которым связан ключ, и секретом, о котором знает только сервер Google API. Он может содержать некоторые другие части хорошо известной (для Google, конечно) информации. Когда вы делаете запрос из этого домена, сервер API принимает домен, из которого поступает запрос, и делает тот же самый односторонний расчет хэша и сравнивает два значения.

для вызовов Ajax они, скорее всего, используют реферер для получения домена узел документа. Хотя реферер может быть подделан, в конечном счете, чтобы использовать API, вам нужно получить Google javascript для выполнения в документе. На этом этапе этот javascript может проверить, действительно ли документ, который вызвал вызов API Ajax, был создан с целевого сервера. Это также поддельно, конечно, при условии, что у вас есть собственная реализация DOM или модификация сценария на лету. Тем не менее, это спуфинг должен происходить на стороне клиента и шансы, что веб-сайт то, что хочет использовать Google API, сможет подделать клиентское программное обеспечение довольно мало.

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

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

Как говорит мой комментарий:

реферер поддельный, поэтому, вероятно, маловероятно, что Google будет использовать его в качестве средства проверки. Смотрите эта запись в Википедии.

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

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

из FAQ

обратите внимание, что ключ для http://www.mygooglemapssite.com/ будет приниматься только при доступе к сайту по этому адресу. Он не будет принят, если сайт доступен по ip-адресу (например. http://10.1.2.3/) или по имени хоста, которое имеет псевдоним www.mygooglemapssite.com использование DNS CNAME запись.

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

мое предположение подкрепляется тем фактом, что он не работает для IP-адресов или псевдонимов, что означает, что он не выполняет проверку DNS.

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

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

Я согласен со всеми пунктами что Франси Пенов перечислил. Я хотел бы немного остановиться на использовании чужого ключа API. Допустим, вы регистрируетесь key1 с example.com.

1. первая попытка – если anothersite.com и <script src="http://www.google.com/jsapi?key=key1">, Google может проверить свой реферер (упомянутая хэш-схема), и в этом случае есть несоответствие. Как злой злоумышленник преодолевает это, так как многие люди упоминали, что реферер может быть подделан? Это не совсем применимо здесь. Конечно, вы можете отправить произвольные заголовки, если вы сделаете запрос, но как злой хакер подделывает реферер для пользователей на anothersite.com? Это вообще непросто. Были старые версии flash на IE 6, которые позволяли злоумышленнику устанавливать произвольные заголовки при выполнении междоменных запросов, но в целом это не работает для script src. Я не уверен, что включенный Javascript выполняет какую-либо проверку document.location чтобы предотвратить это (вероятно не.)

2. вторая попытка-злой злоумышленник копирует Google Javascript для ключа API из mysite.com'S Источник страницы, а затем вставляет измененный javascript на anothersite.com. Теперь Google ничего не может проверить (удаленный IP-адрес будет компьютером пользователя, и вы или Google не можете много сделать).

Итак, если вы хотите по какой-то причине сохранить свой ключ API в секрете (одна из причин, злонамеренный человек может получить ваш ключ в черном списке/заблокирован), то не делайте этого внедрите ключ в клиентские и прокси-запросы через ваш сервер (ваш код приложения теперь имеет ключ).

причина, по которой он работает, заключается в том, что вы не можете выполнять вызовы API с помощью javascript. Безопасность браузера запрещает javascript делать запросы в любом месте, кроме домена, из которого был создан javascript. Из-за этого любые вызовы API из javascript должны быть отскочены через ваш сервер, где хранится ключ API (ключ api никогда не виден javascript).