Как Карты Google защищают свой ключ API? Как сделать что-то похожее?

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

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

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

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

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

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

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

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

Из FAQ

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

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

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

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

Однако это также означает, что вы ДОЛЖНЫ предоставить библиотеку Javascript для доступа к коду, поскольку вы не можете проверить эту серверную сторону, я полагаю.

Я согласен со всеми пунктами, которые перечисл Franci Penov. Я хотел бы немного рассказать об использовании другого ключа API. Предположим, вы зарегистрировали key1 с http://mysite.com.

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

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

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

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