Lo sé como URL de token seguro, maby hay otro nombre por ahí. Pero creo que todos lo saben.

e aplica principalmente a un teqniuque si desea restringir la entrega de contenido a un determinado cliente, que ha entregado una URL específica por adelantado.

Toma un token secreto, concatenelo con el recurso que desea proteger, lo tiene y cuando el cliente solicita esta URL en uno de su servidor, el hash se reconstruye a partir de la información recopilada de la solicitud y el hash es comparado. Si es lo mismo, el contenido se entrega, de lo contrario, el usuario es redirigido a su sitio web u otra cosa.

También puede poner una marca de tiempo en la hora de vivir en la url, o incluir la dirección IP de los usuarios para restringir la entrega a su conexión.

This teqnique es utilizado por Amazon (S3 y Cloudfront), Level 3 CDN, Rapidshare y muchos otros. También es una parte básica de la autenticación de resumen http, aunque hay un paso más con la invalidación de enlaces y otras cosas.

Aquí hay un enlace a laDocumentos de Amazon si quieres saber más.

Ahora mi preocupación con este método es que si una persona descifra un token de sus enlaces, el atacante obtiene su token de texto sin formato y puede firmar cualquier URL a su nombre.

O peor, en el caso de Amazon, acceda a sus servicios en un ámbito administrativo.

Granted, el hash de cadena aquí suele ser bastante largo. Y puede incluir muchas cosas o incluso forzar que los datos tengan una longitud mínima agregando algunos datos innecesarios a la solicitud. Maby alguna pseudo variable en la URL que no se utiliza y rellénela con datos aleatorios.

Por lo tanto, los ataques de fuerza bruta para romper el sha1 / md5 o lo que sea que uses hash son bastante difíciles. Pero el protocolo está abierto, por lo que solo tiene que llenar el espacio donde está el token secreto y llenar el resto con los datos conocidos de la solicitud. Y hoy el hardware es increíble y puede calcular md5 a una velocidad de varias decenas de megabytes por segundo. Este tipo de ataque se puede distribuir a una nube informática y no está limitado a algo así como "10 intentos por minuto por un servidor de inicio de sesión más o menos", lo que hace que los enfoques de hash generalmente sean bastante seguros. Y ahora con Amazon EC2 incluso puedes alquilar el hardware por poco tiempo (¡bátalos con sus propias armas jaja!)

¿Entonces, qué piensas? ¿Mis preocupaciones tienen una base o soy paranoico?

Sin embargo

Actualmente estoy diseñando una nube de almacenamiento de objetos para necesidades especiales (codificación trans integrada de medios y métodos de entrega especiales como transmisión, etc.)

Now level3 introdujo un enfoque alternativo para asegurar las URL de token. Actualmente es beta y solo está abierto a clientes que lo soliciten específicamente. Lo llaman "autenticación de proxy".

Lo que sucede es que el servidor de entrega de contenido realiza una solicitud HEAD a un servidor especificado en la configuración (del cliente) e imita la solicitud de los usuarios. Entonces, se pasa la misma ruta GET y la dirección IP (como x_forwarder). Responde con un código de estado HTTP que le dice al servidor que vaya con la entrega de contenido o no.

También puede introducir algún proceso de token seguro en esto y también puede ponerle más restricciones. Como permitir que solo se solicite una URL 10 veces más o menos.

Obviamente viene con muchos gastos generales porque se realizan solicitudes y cálculos adicionales, pero creo que es razonable y no veo ninguna advertencia. ¿Vos si