Сам ключ API, скорее всего, является односторонним хешем домена, с которым связан ключ, и секретом, о котором знает только сервер API Google. Он может содержать некоторые другие части общеизвестной (конечно, для Google) информации. Когда вы делаете запрос из этого домена, сервер API берет домен, из которого исходит запрос, выполняет тот же односторонний расчет хэша и сравнивает два значения.
Для вызовов Ajax они, скорее всего, используют реферер для получения домена узла документа. Хотя реферер может быть подделан, в конечном итоге, чтобы использовать API, вам нужно заставить Google javascript выполняться в документе. На этом этапе этот javascript может проверить, действительно ли документ, вызвавший вызов Ajax API, исходит от целевого сервера. Конечно, это тоже можно подделать, если у вас есть собственная реализация DOM или «на лету» модификация скрипта. Однако этот спуфинг должен происходить на стороне клиента, и вероятность того, что веб-сайт, который хочет использовать Google API, сможет подделать клиентское программное обеспечение, довольно мала.
Обратите внимание: поскольку API по сути бесплатный, они могли также предложить анонимный доступ к своему API. Очевидно, намерение Google состоит не в защите от несанкционированного доступа к нему, а в том, чтобы гарантировать, что они смогут собрать как можно больше данных об этом использовании данных и иметь возможность связать это использование с другими данными, которые они собрали о целевом домене. Таким образом, я бы не ожидал, что проверка ключа API будет намного сложнее, чем то, что я описал выше - рентабельность инвестиций при более продвинутом подходе слишком низкая.
И, конечно же, есть опасения по поводу возможных XSS-атак через их API. Но я не верю, что их API-ключ слишком сильно привязан к какому-либо анти-XSS-коду, который у них есть.
person
Franci Penov
schedule
13.02.2010
