¿Cómo protege Google Maps su clave API? Cómo hacer algo similar?

La clave API en sí es probablemente un hash de un solo sentido del dominio al que está asociada la clave y un secreto del que solo conoce el servidor API de Google. Puede contener algunas otras piezas de información bien conocida (para Google, por supuesto). Cuando realiza una solicitud desde ese dominio, el servidor API toma el dominio del que proviene la solicitud y realiza el mismo cálculo de hash de una sola manera y compara los dos valores.

Para las llamadas Ajax, lo más probable es que usen el referente para obtener el dominio de la host del documento. Si bien el referente se puede falsificar, en última instancia, para usar la API, debe obtener Google javascript para ejecutarse en el documento. En este punto, este javascript puede verificar que el documento que invocó la llamada a la API Ajax se originó desde el servidor de destino. Esto también es suplantable, por supuesto, siempre que tenga su propia implementación DOM o modificación sobre la marcha del script. Sin embargo, esta suplantación debe ocurrir en el lado del cliente y las posibilidades de que el sitio web que quiere utilizar la API de Google será capaz de falsificar el software del cliente son bastante pequeños.

Tenga en cuenta que, dado que la API es esencialmente gratuita, también podrían haber ofrecido acceso anónimo a su API. Aparentemente, la intención de Google no es proteger el acceso no autorizado a él, sino asegurarse de que puedan recopilar la mayor cantidad de datos posible sobre ese uso de datos y poder asociar ese uso con otros datos que hayan recopilado sobre el dominio de destino. Como tal, no esperaría la clave API la verificación es mucho más compleja de lo que describí anteriormente: el ROI en un enfoque más avanzado es demasiado bajo.

Y, por supuesto, también existe la preocupación de posibles ataques XSS a través de su API. Pero no creo que su clave API esté demasiado ligada a ningún código anti-XSS que tengan.

Como dice mi comentario:

El REFERENTE es suplantable, por lo que es probablemente poco probable que Google lo use como un medio de verificación. Ver esta entrada de wikipedia.

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

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

De las Preguntas frecuentes

Tenga en cuenta que una clave para http://www.mygooglemapssite.com / solo se aceptará cuando se acceda al sitio utilizando esta dirección. No se aceptará si se accede al sitio por dirección IP(ej. http://10.1.2.3 / ) o por un nombre de host que tiene un alias www.mygooglemapssite.com usando un registro CNAME DNS.

Mi conjetura es que podría estar utilizando el Host encabezado que se envía al solicitar la página, que funcionaría como normalmente Google le pide que incluya su script API directamente en la página. Luego, ese script tiene acceso a los encabezados de la página actual y puede usarlo para verificar.

Mi suposició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 falsificado, ya que debe ser el encabezado correcto para acceder a la página. Sin embargo, esto significa que cualquier alias del dominio no funcionará.

Sin embargo, esto también significa que debe proporcionar una biblioteca Javascript para acceder al código, ya que no puede verificar 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 la clave API de otra persona. Supongamos que se registra key1 con example.com.

1. Primer intento-Si anothersite.com tiene <script src="http://www.google.com/jsapi?key=key1">, Google podría comprobar su referente (esquema hash mencionado) y en este caso hay un desajuste. ¿Cómo el mal atacante supera esto, ya que muchas personas han mencionado que el referente puede ser falsificado? Esto no se aplica realmente aquí. Seguro podría enviar encabezados arbitrarios si realiza la solicitud, pero ¿cómo evil hacker spoof referrer para los usuarios en anothersite.com? Esto en general no es fácil. Ha habido versiones antiguas de flash en IE 6 que permitían al atacante establecer encabezados arbitrarios al hacer solicitudes de dominios cruzados, pero en general esto no es viable para script src. No estoy seguro de si el Javascript incluido hace alguna validación de document.location para evitar esto (probablemente no).

2. Segundo intento-Un atacante malvado copia Google Javascript para la clave API de la fuente de página de mysite.com y luego incrusta javascript modificado en anothersite.com. Ahora Google no puede verificar nada (la IP remota será la computadora del usuario, y no hay mucho que usted o Google puedan hacer).

Por lo tanto, si por alguna razón desea mantener su clave API en secreto (una razón, una persona maliciosa puede obtener su clave en la lista negra/bloqueada), entonces no incruste la clave en las solicitudes de cliente y proxy a través de su servidor (su código de aplicación ahora tiene la clave).

La razón por la que funciona es que no puede realizar llamadas a la API con javascript. La seguridad del navegador impide que javascript realice solicitudes en cualquier lugar, excepto en el dominio del que se originó el javascript. Debido a esto, cualquier llamada API de javascript debe ser rebotada a través de su servidor donde se almacena la clave API (la clave API nunca es vista por javascript).