¿Asegurar una URL accesible anónima con un segmento GUID?

Question

¿Asegurar una URL accesible anónima con un segmento GUID?

#1 de tylerl (2 votos)
#2 de CodesInChaos (0 votos)

4

En mi problema, hay un sistema existente que funciona como un servicio de alerta o de recorte que ejecuta búsquedas definidas por el usuario y genera listas de resultados. Estos son configurados por usuarios autenticados y este sistema interno utiliza un GUID como el identificador para obtener los resultados, que se almacenan en una base de datos.

Hay un requisito para exponer estos resultados a través de RSS. Sin embargo, aparte de incluir username:password@ en la URL, no conozco ninguna técnica que funcione con los lectores RSS. La idea ingenua es hacer que las URL sean algo como /alert/{guid}/rss , que tiene algunos problemas. Debido a que los GUID están diseñados para ser únicos y no aleatorios, me preocupa la posibilidad de adivinar ataques, ya que cada intento de adivinación apuntalará la solicitud del sistema web hacia el sistema interno y accederá a la base de datos. Estoy buscando una manera de agregar un poco de singularidad a la URL y evitar el acceso innecesario a la base de datos, a la vez que se conserva la clave basada en GUID.

Mi idea es expandir la URL /feed/{guid}/rss a algo como /feed/v1/{hash}/{guid}/rss que contiene un segmento de hash adicional. Este segmento se generaría combinando el guid existente y una aplicación proporcionada de forma secreta a través de concatenación o XORing o algo así. Esta sería la URL que se proporcionaría a los lectores RSS desde la aplicación. Luego, cuando una URL entra en el sistema, el segmento de hash puede volver a calcularse en la memoria, compararse y rechazarse sin un viaje al servicio interno y la base de datos. El segmento /feed/ líder de la URL es único en el sistema para permitir el enrutamiento de URL / equilibrio de carga en el futuro para alimentar la caché. El segmento /v1/ está en su lugar si el secreto tiene que cambiar para futuras URL de fuentes.

Ya que no quiero ser otra prueba para "Ley de Schneier" , ¿cuáles son los problemas con este patrón? Creo que ayuda con la denegación de servicio para ataques de fuerza bruta (pero no si se conoce al menos una URL válida). También creo que crea URL "aleatorias" para la sensibilidad de los datos. Estoy abierto a críticas u otras ideas, pero estoy atascado con las claves basadas en GUID.

brute-force denial-of-service rest

pregunta Kevin Hakanson 21.11.2012 - 20:56

fuente

2 respuestas

Lea otras preguntas en las etiquetas brute-force denial-of-service rest

¿Cuántos datos debo almacenar en la computadora de un usuario sobre su información de inicio de sesión? ¿Las claves públicas hacen que Kerberos sea más seguro (RFC4556)?

score 2 · Answer 1

La solución básica es codificar una contraseña semi-pública de un solo propósito en la URL. Normalmente, la solución se parece a esto:

http://<base>/<content_identifier>/<auth_identifier>/<random_password>

Entonces, <base> y <content_identifier> son lo que quieras; Hacen que la URL apunte a algo para tu sitio. El < auth_identifier> apunta a un token de autenticación correspondiente en su base de datos que indica quién autorizó esta URL, etc. El bit <random_password> está allí para garantizar que no se pueda adivinar la URL. Es simplemente aleatorio. El token de autenticación en la base de datos almacena la contraseña aleatoria correcta. Debería poder revocar o caducar las URL antiguas actualizando (o eliminando) el token de autenticación en su base de datos. También debería poder emitir una URL única adicional después de que se haya revocado una anterior (o quizás al mismo tiempo que otra). Es difícil hacer esto si su secreto es un hash, ya que solo hay una respuesta correcta y, por lo tanto, una URL correcta.

Si le preocupan los secretos, puede cifrar los datos antes de publicarlos en una URL y descifrarlos antes de procesarlos. Por lo general, eso es una exageración, pero todo depende de los datos que esté exponiendo.

Tenga en cuenta que su idea de codificar suficiente información en la URL para que sea verificable sin la base de datos significa que el contenido de la base de datos no puede afectar la validez de la URL. Específicamente, no puedes revocarlo. A menudo, esa restricción resulta problemática en el futuro.

score 0 · Answer 2

Mi primera idea es simplemente generar un valor aleatorio de 16 bytes usando un PRNG seguro y usarlo en lugar de un GUID generado por el sistema. Esto debería ser un reemplazo en lugar de un GUID (sin cambio de protocolo :) y debería ser seguro siempre que la url no se escape.

Tu también debería estar seguro, si usas un MAC como HMAC-SHA-2 (esencialmente un hash con clave). No use un esquema de combinación ad hoc, use HMAC que es estándar y seguro.