¿Cómo puedo asegurar un servicio REST destinado a ser utilizado por los clientes de mis clientes a través de su sitio web público?

Question

¿Cómo puedo asegurar un servicio REST destinado a ser utilizado por los clientes de mis clientes a través de su sitio web público?

#1 de ThoriumBR (2 votos)
#2 de Riking (0 votos)

0

Estoy desarrollando un servicio con una API REST asociada para el uso de los clientes (empresas que tienen sus propios sitios web). En otras palabras, uno de mis clientes normalmente realiza la llamada REST directamente desde su sitio web (es decir, la solicitud se origina en uno de los navegadores de sus clientes).

Por supuesto, puedo proporcionar un token de acceso para que mis clientes puedan acceder, pero, por definición, tendrá que publicarse públicamente en su sitio, lo que significa que cualquiera tendrá acceso a él.

La situación parece análoga al uso de las claves API de Google Maps, por ejemplo. A menos que me equivoque, si inserto un mapa en mi página, mi clave API debe ser pública. Que yo sepa, las únicas protecciones contra otras personas que usan mi clave son que puedo restringir las solicitudes (con Google) a ciertos dominios.

¿Es esto lo único que puedo hacer para restringir el acceso a mis clientes? ¿Es posible que un no cliente falsifique su dominio de referencia? Si es así, ¿la gente hace esto para usar otras claves API de Google?

web-application authentication rest

pregunta Jer 15.10.2018 - 19:36

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application authentication rest

Las páginas de inicio de sesión de Oauth alojadas en la aplicación: ¿qué detiene la falsificación? ¿El exploit XSS siempre es ilegal? [cerrado]

score 2 · Answer 1

El campo Referer es fácilmente simulable, ya que es una variable del lado del cliente. No confíe en ello para nada serio, como el control de acceso.

Para controlar los dominios permitidos para usar su API, debe solicitarles que realicen todos los accesos a su servicio y utilicen la autenticación de su lado. De esta manera, cuando sus clientes accedan a su sitio, la solicitud pasará a través de sus servidores, una secuencia de comandos agregará los detalles de autenticación y se enviará a su servidor.

El cliente nunca verá las credenciales, y usted puede prohibir o estrangular las claves que sospecha que están haciendo mal uso del servicio.

score 0 · Answer 2

Los navegadores modernos siempre envían el encabezado Origin en las solicitudes de origen cruzado (que incluyen credenciales), pero los navegadores más antiguos no pueden hacerlo. Puede verificar que las solicitudes que se originan en un navegador moderno solo provienen de sitios web de clientes aprobados al marcar el encabezado de Origen.

El algoritmo comprobar el encabezado de origen es el siguiente:

Si no hay un encabezado de origen, o si un encabezado de origen está presente con un valor en blanco ¹, no se puede extraer una conclusión. Devuelva "permitir" del algoritmo comprobar el encabezado de origen .
Si el encabezado Origin está presente y es no exactamente uno de los sitios web de sus clientes (en la forma https://www.contoso.com ), o un subdominio de uno de sus sitios web de clientes, entonces la solicitud es desde un navegador genuino en un sitio no cliente . Devuelva "denegar" del algoritmo comprobar el encabezado de origen .
Si el encabezado Origin está presente, y es exactamente uno de los sitios web de sus clientes o sus subdominios, la solicitud puede provenir de un navegador o de otra herramienta. Devuelva "permitir" del algoritmo comprobar el encabezado de origen .

Nota al pie 1: el texto null , enviado desde data: y file: URL, no se considera un valor en blanco aquí. Es un valor que no coincide.