web services - keys - ¿Cómo protege Google Maps su clave de API? ¿Cómo hacer algo similar?
google maps library (5)
Como dice mi comentario:
El REFERER es falso, por lo que es poco probable que Google lo use como medio de verificación. Vea esta entrada de wikipedia.
Supongo que probablemente Google use la dirección IP de la persona que llama junto con una búsqueda de DNS. DNS no es realmente spoofable, ya que sus entradas de DNS deben ser correctas para que el sitio web llegue a usted.
Pero, incluso eso tiene sus problemas, porque si un servidor utiliza una configuración DNS de dirección IP de Round-Robin, Google será redireccionado a una dirección IP diferente cuando haga 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 usando esta dirección. No se aceptará si se accede al sitio por una dirección IP (por ej., http://10.1.2.3/ ) o por un nombre de host con alias a www.mygooglemapssite.com usando un registro DNS CNAME.
Supongo que podría ser el uso del encabezado Host que se envía al solicitar la página, lo que funcionaría, ya que normalmente Google le pide que incluya su script API directamente en la página. Entonces esa secuencia de comandos tiene acceso a los encabezados de la página actual y puede usar eso para verificar.
Supongo que está respaldado 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 se puede falsificar, ya que debe ser el encabezado correcto para acceder a la página. Sin embargo, esto significa que los alias del dominio no funcionarán.
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.
Actualmente, Google requiere que cree una clave de API que sea específica del dominio de donde se servirá el mapa. ¿Cómo aplica Google esto? Quiero hacer lo mismo.
Expongo una API para mi servicio pero quiero permitirles a los clientes insertar llamadas a la API a través de JavaScript y no solo desde el servidor. Podría asegurarlo con solo un token al azar, pero por supuesto esto podría ser fácilmente falsificado por cualquiera que mire el código en la máquina del cliente.
Siempre entendí que este concepto no es posible, pero de alguna manera, Google hace un buen trabajo al aplicarlo.
Editar - Parece que Google realmente no ha hecho nada sorprendente después de todo. Su API probablemente solo sea para rastrear y no para garantizar que su API sea utilizada por la persona que tiene la clave.
Estoy bastante seguro de que usan la URL REFERER para determinar de dónde viene la llamada. Si el dominio no coincide con lo asignado a la clave, se trata de una solicitud no válida.
Para un ejemplo práctico, usando PHP puede verificar el dominio usando $_SERVER[''HTTP_REFERER''] para verificar el referer. Si el dominio coincide, devuelve una respuesta válida. Si no lo hace, puede devolver una respuesta 401 no autorizada u otra respuesta.
Estoy de acuerdo con todos los puntos que Franci Penov ha enumerado. Me gustaría elaborar un poco sobre el uso de la clave de API de otra persona. Supongamos que registras key1 con http://misitio.com .
1) Primer intento: si anothersite.com tiene el script src = http://www.google.com/jsapi?key=key1 , google podría verificar la referencia (se mencionó el esquema de hash) y en este caso hay una discrepancia. ¿Cómo puede el malvado atacante superar esto? Mucha gente ha mencionado que el referente puede ser falso. Esto realmente no se aplica aquí. Claro que puedes enviar encabezados arbitrarios si realizas la solicitud, pero ¿cómo puede el pirata informático engañar a los usuarios de anothersite.com? En general, esto no es fácil. Ha habido versiones anteriores de flash en IE 6 que permitieron al atacante establecer encabezados arbitrarios al realizar solicitudes de dominios cruzados, pero en general esto no es factible para script src. No estoy seguro si el js incluido hace alguna validación de document.location para evitar esto (probablemente no).
2) Segundo intento: el atacante maligno copia google javascript para la clave API de la fuente de la página de mysite.com y luego inserta javascript modificado en anothersite.com. Ahora google no puede verificar nada (la IP remota será la computadora del usuario y no hay mucho que tú o Google puedan hacer).
Por lo tanto, si desea mantener su clave API en secreto por algún motivo (una de las razones es que una persona malintencionada puede poner su clave en la lista negra / bloqueada), no inserte la clave en las solicitudes de cliente y proxy a través de su servidor (su código de aplicación ahora tiene llave).
La clave API en sí misma es probablemente un hash de una dirección del dominio al que está asociada la clave y un secreto que solo el servidor API de Google conoce. Puede contener algunas otras piezas de información conocida (a 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 hash de una manera y compara los dos valores.
Para las llamadas Ajax, lo más probable es que usen la referencia para obtener el dominio del host del documento. Si bien la referencia puede ser falsa, en última instancia, para usar la API, necesita obtener Google JavaScript para que se ejecute en el documento. En este punto, este javascript puede verificar que, de hecho, el documento que invocó la llamada API Ajax se originó desde el servidor de destino. Esto también es factible, por supuesto, siempre que tenga su propia implementación de DOM o la modificación en 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 usar Google API pueda falsificar el software del cliente son bastante pequeñas.
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, 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 objetivo. Como tal, no esperaría que la verificación de la clave API fuera 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.
La razón por la que funciona es que no puedes hacer llamadas a API con javascript. La seguridad del navegador evita que JavaScript haga solicitudes en cualquier lugar, excepto en el dominio del que se originó el javascript. Debido a esto, todas las llamadas API de javascript deben rebotarse a través de su servidor donde se almacena la clave API (la clave api nunca es vista por javascript).