Как 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 должны быть правильными для веб-сайта, чтобы даже добраться до вас.

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

из FAQ

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

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

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

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

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

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

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

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

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

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