Pregunta

Actualmente Google requiere que cree una clave de API que es específico para el dominio de donde el mapa se sirve de. ¿Cómo Google hacer cumplir esto? Quiero hacer lo mismo.

expongo una API para mi servicio, pero quiero que los clientes puedan integrar las llamadas a la API a través de JavaScript y no sólo desde el servidor. Podía asegurarlo con sólo una muestra aleatoria pero por supuesto esto podría suplantar fácilmente por cualquier persona que mire el código en la máquina cliente.

Siempre entendido este concepto de no ser posible, pero de alguna manera Google hace un buen trabajo en la aplicación de la misma.

Editar - Suena como Google realmente no ha hecho nada sorprendente después de todo. Su API es más probable que sólo para el seguimiento y no realmente para garantizar que su API es utilizado por la persona con la clave.

¿Fue útil?

Solución

Estoy bastante seguro de que utilizan la URL de referencia para determinar donde la llamada está viniendo. Si el dominio no coincide con lo que está asignado a la tecla, se trata de una solicitud válida.

En un ejemplo práctico, el uso de PHP se puede comprobar el dominio utilizando $_SERVER['HTTP_REFERER'] para comprobar el árbitro. Si el dominio coincide, devolver una respuesta válida. Si no lo hace, puede devolver una respuesta no autorizado u otro 401.

Otros consejos

La clave de API en sí es muy probablemente un hash una forma de dominio de la tecla está asociada con un secreto y sólo el servidor API de Google conoce. Puede contener algunas otras piezas de muy conocido (a Google por supuesto) la información. Cuando se hace una solicitud de ese dominio, el servidor API lleva el dominio de la petición viene de y hace que el mismo cálculo de hash de una manera y compara los dos valores.

Para las llamadas Ajax, lo más probable es utilizar la de referencia para obtener el dominio del host documento. Mientras que la URL de referencia puede ser falsa, en última instancia, con el fin de utilizar la API, que necesita para obtener Google Javascript para ejecutar en el documento. En este punto, este JavaScript puede verificar que, efectivamente, el documento que ha invocado la llamada a la API Ajax se originó en el servidor de destino. Esto también es falsificables por supuesto, siempre y cuando tenga su propia implementación DOM o modificación en marcha del guión. Sin embargo, esta suplantación de identidad tiene que ocurrir en el lado del cliente y las posibilidades de que el sitio web que quiere utilizar la API de Google será capaz de burlar el software de cliente son bastante pequeñas.

Tenga en cuenta que, dado que la API es esencialmente libre, que podría haber ofrecido acceso anónimo a su API también. Al parecer, la intención de Google no es para proteger el acceso no autorizado a ellos, sino para garantizar que puedan reunir la mayor cantidad posible de datos acerca de que el uso de datos y ser capaz de asociar que el uso con otros datos que han recopilado sobre el dominio de destino. Como tal, yo no esperaría que la verificación de clave de API a ser mucho más complejo que lo que he descrito más arriba - el retorno de la inversión en el enfoque más avanzado es demasiado baja

.

Y, por supuesto, también existe la preocupación de posibles ataques XSS a través de su API. Pero no creo que la clave de la API está ligado demasiado en cualquier anti-XSS código que tienen.

Como dice mi comentario:

  

El árbitro es falsificables, por lo que es probable que sea poco probable que Google va a utilizarlo como un medio de verificación. Ver esta entrada de Wikipedia.

Mi conjetura es que probablemente Google utiliza la dirección IP de la persona que llama, junto con una búsqueda de DNS. DNS no es realmente falsificables, como sus entradas DNS tienen que ser correcta para el sitio web para incluso llegar a usted.

Pero, incluso eso tiene sus problemas, porque si el servidor utiliza una configuración de dirección DNS Round-Robin IP, Google será redirigido a una dirección IP diferente cuando se hace una búsqueda de DNS.

Desde el FAQ

  

Tenga en cuenta que una clave para http://www.mygooglemapssite.com/ sólo se aceptará cuando el sitio se accede a través de esta dirección. No se aceptará si el sitio se accede mediante la dirección IP (por ejemplo. http://10.1.2.3/ ) o por un nombre de host que está utilizando un alias a www.mygooglemapssite.com un registro DNS CNAME.

Mi conjetura es que podría estar utilizando la cabecera Host que se envía cuando se solicita la página, que funcionaría como normalmente Google le pide que se encuentra su escritura API directamente en la página. Luego de que la escritura tiene acceso a las cabeceras de la página actual y se puede utilizar para comprobar que.

Mi opinión está respaldada por el hecho de que no funciona para direcciones IP o alias, lo que significa que no está haciendo una comprobación de DNS.

Este método no puede ser falsa, ya que debe ser la cabecera correcta para acceder a la página. Sin embargo, esto significa que cualquier alias al dominio no funcionarán.

Sin embargo, esto también significa que debe proporcionar una biblioteca Javascript para acceder al código, ya que no se puede comprobar este lado del servidor, creo.

Estoy de acuerdo con todos los puntos que Franci Penov ha enumerado. me gustaría elaborar un poco sobre el uso de otra persona API llave. Supongamos que se registre key1 con example.com.

  1. Primer intento - Si tiene anothersite.com <script src="http://www.google.com/jsapi?key=key1">, Google podría comprobar su referente (esquema de hash mencionado) y en este caso hay un desajuste. ¿De qué manera el mal atacante superar esto, ya que muchas personas han mencionado que URL de referencia puede ser falsificada? Esto en realidad no se aplican aquí. Claro que podría enviar cabeceras arbitrarias si se hace el pedido, pero ¿cómo funciona mal pirata informático de referencia de la parodia para los usuarios en anothersite.com? Esto es, en general, no es fácil. Ha habido versiones antiguas de Flash en Internet Explorer 6 que permitió atacante para establecer cabeceras arbitrarias al realizar solicitudes de dominios cruzados, pero en general esto no es viable para src guión. No estoy seguro de si el Javascript incluido hace ninguna validación de document.location para evitar esto (probablemente no).

  2. Segundo intento - Un atacante copias malas JavaScript de Google para la clave de API desde la fuente de la página de mysite.com y luego se incrusta modificados javascript en anothersite.com. Ahora Google no puede comprobar cualquier cosa (el control remoto IP será el ordenador del usuario, y no hay mucho que puede hacer o Google).

Por lo tanto, si desea por alguna razón mantener en secreto su clave de API (una de las razones, persona con malas intenciones puede conseguir su clave en la lista negra / bloqueado), entonces no incrustar clave en las solicitudes del cliente y de proxy a través de su servidor (el código de aplicación ahora tiene la llave).

La razón por la que funciona es que no se puede hacer llamadas a la API con JavaScript. la seguridad del navegador impide Javascript de hacer peticiones a cualquier parte excepto el dominio que el javascript originó. Debido a esto, las llamadas a la API de JavaScript necesidad de ser rebotaron a través de su servidor donde está almacenada la clave de API (API la clave no es visto por el javascript).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top