Proteger una URL web cuando la llama una aplicación cliente

Question

Proteger una URL web cuando la llama una aplicación cliente

#1 de jacobbaer (1 votos)

1

Estamos desarrollando una aplicación Angular2 / NodeJS de una sola página que tendrá un formulario web para que nuestros usuarios puedan completar y enviar. No tenemos ninguna aplicación web para que nuestros usuarios inicien sesión (por lo tanto, no hay SSO), pero nuestro los usuarios inician sesión en nuestras aplicaciones asociadas, que pueden ser una aplicación web o dispositivo móvil, cada una con su propio mecanismo de autenticación. Nuestras aplicaciones asociadas básicamente llaman a nuestra API para obtener varios contenidos y mostrarlos en su interfaz de usuario. Ahora, uno de nuestros contenidos tendrá el enlace a la nueva aplicación de formulario que estamos desarrollando.

Queremos asegurar la llamada a la aplicación de Formulario de tal manera que la solicitud solo pueda ser activada desde nuestras aplicaciones asociadas y desde ningún otro lugar. Las aplicaciones asociadas no pueden impedir que el usuario copie la URL, pero queremos asegurarnos de que la solicitud haya llegado desde nuestras aplicaciones asociadas.

¿Cuál es la mejor manera de lograr esto con una codificación mínima o nula para nuestros socios, ya que no tenemos control sobre sus ciclos de desarrollo o lanzamiento? Pocas de las opciones que estamos evaluando

Opción 1:

Comprueba el encabezado http, Referer. enlace . Esta puede no ser la solución correcta como a) se puede falsificar fácilmente ( enlace ) y b) El cliente puede ser una aplicación móvil y decidir no enviar el encabezado

Opción 2:

Otra opción sería que nuestros socios pasen un token como un parámetro oculto. Entonces, suponiendo que cualquier usuario no experto en tecnología no buscará en la fuente de la página para encontrar lo que es el token. Por supuesto, esto puede requerir cierta actividad de desarrollo de nuestros socios que nos gustaría evitar.

¿Hay alguna otra solución elegante que podamos probar?

web-application web-browser node.js

pregunta Tatha 16.06.2017 - 20:38

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application web-browser node.js

Configuración de problemas de Knockd ¿Qué información se puede encontrar sobre una unidad cifrada con LUKS?

score 1 · Answer 1

Está intentando utilizar a sus proveedores como proveedores de inicio de sesión único. Eso es absolutamente posible ... si están dispuestos a implementar algún protocolo de identidad federado como OAuth, SAML, Kerberos, etc. Esto implicaría un trabajo de ingeniería sustancial por su parte, y probablemente un trabajo burecruático sustancial y una responsabilidad legal ya que HIPAA está en juego. (No lo sé. No soy tu abogado).

Por las razones que ha enumerado, confiar totalmente en el encabezado del Referer o en un secreto compartido, de uso ilimitado e irresponsable es absolutamente imposible. Además, confiar en un usuario simplemente porque se conectó a un proveedor de confianza también está fuera de discusión. Su API necesita saber quién, específicamente, está actuando sobre ella, y almacenar / registrar esa información. Puede que a tu negocio no le importe, pero a HIPAA sí.

Los protocolos de identidad federados / SSO son formas de generar, pasar y verificar tokens como su Opción 2 que son específicos para el usuario, la ventana de tiempo, etc. No invente los suyos. OAuth es probablemente el más fácil de implementar.

La solución más sencilla es crear cuentas de usuario en su aplicación NodeJS. Los usuarios deben iniciar sesión (tener cookies de sesión) para llegar a cualquier lugar con la URL de su proveedor. No hay problema de identidad federada.

Otra solución bastante simple es hacer que su API y los backends de sus proveedores se comuniquen directamente, sin el navegador del usuario final en el bucle. HTTPS y un token simple en un encabezado HTTP serían razonables. TLS mutuo con certificados de cliente es el estándar de oro. Pero esto se basa en los secretos que se mantienen en el backend. Esto también significaría que cualquier cambio en la forma en que interactúa son cambios de código para sus proveedores.

La solución real es implementar un Proveedor de Identidad (compartirlo con Microsoft Azure, AWS o OneLogin, o contratar consultores para hacerlo dentro de su firewall) e integrarlo con todos sus proveedores y su API para que sus usuarios solo tener una cuenta para tratar. Sus proveedores existentes casi seguramente no quieren este rol. Es posible que la gente de SaaS no lo quiera porque HIPAA, pero probablemente uno de ellos estará dispuesto a ejecutar un Acuerdo de Asociado de Negocios HIPAA por el precio correcto.