¿Es seguro hacer una aplicación web disponible públicamente que tiene URL generadas a partir de un hash?

Navega tus respuestas
1

Si conoce un título mejor, no dude en editarlo.

Estoy creando una sencilla aplicación web de Google para que los colegas de mi lugar de trabajo puedan ver los detalles sobre el control de calidad que recibieron. El problema es que solo algunas personas tienen cuentas de Google Apps, por lo que la aplicación web no puede restringirse a los usuarios de nuestro dominio.

Estaba considerando generar un número aleatorio para cada respuesta de control de calidad, luego usar los detalles de control de calidad y ese número para generar un hash que es esencialmente una URL única. es decir, https://script.google.com/a/macros/MyDomain/MyApp/?code=UniqueCode . visitar esa URL con el código único le mostrará los detalles del control de calidad.

El código único se recuperará a través de GET.

¿Esto es seguro? ¿Se puede descifrar fácilmente para ver información muy básica sobre los empleados?

    
pregunta Douglas Gaskell 23.11.2015 - 01:12
fuente

1 respuesta

2

Su esquema es moderadamente seguro siempre que el valor aleatorio sea lo suficientemente largo y aleatorio, sin embargo, tiene una serie de fallas:

  • Pasar su token de autenticación en la URL significa que estará en los registros del servidor HTTP, el historial del navegador, etc. Los datos en estos lugares generalmente no se almacenan de una manera especialmente segura.
  • No tiene manera de revocar el acceso (por ejemplo, si un empleado se retira o si su sistema está comprometido de alguna manera)
  • No hay límite de tiempo para la validez de los tokens

Lo ideal sería tener algún tipo de método global para autenticar a todos los usuarios (por ejemplo, todos los usuarios registran una cuenta en su sistema), pero si no tiene más que direcciones de correo electrónico con las que autenticar , entonces sugeriría lo siguiente:

  1. El enlace enviado por correo electrónico al usuario es un enlace a una página de autenticación con el contenido / ID de control de calidad y el correo electrónico del usuario como parámetros.
  2. La página de autenticación genera un hash / firma que contiene el contenido / QA ID, el correo electrónico del usuario, una fecha y hora de caducidad (que caduca en unos 30 minutos) y una ID única que solo se puede aceptar una vez (es decir, nonce) , y envía un nuevo enlace con el hash / firma al usuario
  3. El usuario sigue el segundo enlace en el nuevo correo electrónico que contiene el hash / firma y los parámetros (caducidad, contenido / ID de control de calidad, nonce y correo electrónico) y la página comprueba la validez de los parámetros antes de mostrar el contenido.

Tener que esperar un correo electrónico que contenga un segundo enlace cada vez puede ser un poco molesto, pero tiene las siguientes ventajas sobre su esquema:

  • Las URL en los registros del servidor / historial del navegador no serán un problema de seguridad, ya que solo se pueden usar una vez gracias al nonce.
  • Cuando alguien deja la empresa, su correo electrónico puede ser invalidado, por lo tanto, sus URL no serán aceptadas más
  • La marca de tiempo de caducidad garantizará que los enlaces antiguos no utilizados sean benignos

También recomiendo usar tokens web JSON en lugar de lanzar su propio esquema de firma / hashing.

    
respondido por el thexacre 23.11.2015 - 02:28
fuente

Lea otras preguntas en las etiquetas

¿Cuándo se aplica CORS? tokens CSRF en aplicaciones de una sola página (JavaScript / Angular)