¿Es el token de URL aleatorio lo suficientemente seguro para adjuntar archivos y otro contenido de usuario? [duplicar]

Aunque definitivamente proporciona un grado de seguridad, aún le deja una serie de brechas de seguridad que pueden o no ser importantes dependiendo del tipo de aplicación que esté desarrollando. Para una lista no exhaustiva:

• El contenido puede estar limitado a un grupo selecto de usuarios, ¿qué sucede si uno de ellos filtra la URL?

• Las URL con parámetros GET se almacenan en una gran cantidad de lugares, por ejemplo, el historial web

• Ocasionalmente, se ven problemas importantes cuando Google rastrea cosas para las que no están destinadas, por ejemplo, instawallet fiasco .
• Las vulnerabilidades de seguridad en otras partes de su sitio pueden exponer los enlaces y, sin ninguna seguridad adicional, estarán expuestos.

Si fuera usted, me gustaría implementar seguridad adicional vinculando archivos a personas / grupos específicos que puedan acceder a ella y confirmar su sesión antes de servir el contenido.

El uso de tokens aleatorios largos como secretos para proporcionar acceso a un archivo puede proporcionar una seguridad efectiva. Recomendaría más de 128 bits para hacerlo realmente fuera del rango de adivinar al azar. Probablemente podría salirse con menos bits, especialmente si califica el límite de IP en función de las conjeturas erróneas. Por ejemplo, si tenía un token de 64 bits u 80 bits y mil millones de estos archivos y fue atacado por una botnet con un millón de direcciones IP distintas, cada una de las cuales podría probar 10 intentos cada 10 minutos, por ejemplo, prohibió una IP durante 10 minutos. después de 10 intentos incorrectos, les llevaría aproximadamente 12 días (token de 64 bits) o 2300 años (token de 80 bits) para encontrar un solo archivo aleatorio.

Sin embargo, para hacer esto de manera segura debe tener en cuenta algunas advertencias:

1. Utilice HTTPS. Los intrusos de la red pueden ver (o alterar en secreto) cualquier tráfico a través de HTTP.
2. Si el documento tiene enlaces a otras páginas web y un usuario hace clic en dichos enlaces, el servidor web en el otro extremo generalmente verá un encabezado HTTP Referer en la solicitud HTTP que proporcionará la URL completa (incluidos los secretos; incluso si el secreto está en un parámetro de consulta como enlace ) y seguirá ocurriendo si el usuario está en modo de navegación privada .
3. Es probable que el token aleatorio se almacene en el historial de su computadora (a menos que navegue en modo privado y finalice su sesión).
4. Algunos motores de búsqueda se apoderan de su token aleatorio y lo indexan.
5. El mecanismo para informar al usuario de la clave posiblemente lo filtre a terceros. El correo electrónico se intercambia potencialmente sin cifrar y, si utiliza un proveedor de correo electrónico externo, los administradores de ese proveedor de correo electrónico podrán acceder a su clave secreta. Muchos usuarios también guardan el correo electrónico de texto sin formato en su computadora con un disco no cifrado (por ejemplo, se puede quitar el disco duro o alguien inicia un CD en vivo para leer el contenido del disco) o dejar la computadora conectada a su cuenta de correo electrónico.

El problema 4 generalmente se puede evitar manteniendo un robots.txt y prohibiendo un directorio.

User-Agent: *
Disallow: /private/

Puede mitigar los problemas 2 y 3 solicitando al usuario que solicite su documento mediante HTTP POST (a través de HTTPS). Eso es en lugar de hacer clic en un enlace como:

<a href="https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw">File</a>

Podrías hacer algo como incrustar lo siguiente en un correo electrónico HTML:

<p> Click the button below to get your file:
<form action="https://example.com/private_file/" method="post">
  <input type="hidden" name="token" value="LfliQdgOAkjs9H0Oi5ZZcw">
  <input type="submit" value="Get File">
</form>
<p>Or go to https://example.com/private_file/ and cut and paste the token <pre>LfliQdgOAkjs9H0Oi5ZZcw</pre>.

Esto evitaría que el secreto apareciera en el historial de su navegador o recibiera enlaces de referencia (ya que la URL simplemente sería https://example.com/private_file/ ).

Alternativamente, podría permitir enlaces del formulario https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw , pero luego redirigir al usuario a otra URL cuando en realidad sirva al https://example.com/private/document privado. Esto evitaría el problema # 2 con los encabezados del Referer, pero aún así puede dejar el enlace en el historial de su navegador.

Este tipo de preguntas surgen de vez en cuando.

Esencialmente, esto es seguridad por oscuridad .

El hecho de que es difícil de adivinar solo aborda un tipo de problema. No protege contra:

• Los usuarios comparten accidentalmente el enlace, marcan el enlace, etc.
• El usuario escribe accidentalmente la url en Google u otro motor de búsqueda, lo que da como resultado que se indexe.
• Supervisión externa o intercepción de tráfico de red, almacenamiento en caché

Puede estar interesado en este ejemplo con DropBox y similares de hace unos años:

  

La vulnerabilidad fue descubierta por un bloqueador de archivos basado en la nube Intralinks   en una campaña de Google AdWords en la que se anuncian sus servicios   utilizando palabras clave que identifican a sus competidores, que en este caso son   Caja y Dropbox. La vulnerabilidad existe cuando los usuarios comparten archivos a través de   Compartir enlaces, que luego se insertan en el cuadro de búsqueda   (a diferencia de la barra de URL) en sus navegadores; esto permitió Intralinks   para recopilar los datos en la interfaz de administración de campañas de AdWords.

     

De la misma manera, los usuarios son vulnerables a un poco diferente   Ataque que involucra la retransmisión de encabezados HTTP Referrer, como Dropbox.   se describen en este escenario de ejemplo:

     

Un usuario de Dropbox comparte un enlace a un documento que contiene un hipervínculo   a un sitio web de terceros. El usuario, o un destinatario autorizado de la   enlace, hace clic en un hipervínculo en el documento. En ese punto, el   El encabezado de referencia [sic] revela el enlace compartido original al   sitio web de terceros. Alguien con acceso a ese encabezado, como el   webmaster del sitio web de terceros, podría acceder al enlace para   El documento compartido. En el mismo post, Dropbox nota que el problema   con el cuadro de búsqueda es "bien conocido y no lo consideramos una   vulnerabilidad. "En última instancia, la única protección que los archivos compartidos   tienen es que son difíciles de encontrar, requiriendo un excepcional   URL larga para acceder, en efecto, seguridad a través de la oscuridad.

Poner una imagen frente a una caja fuerte no es lo mismo que cerrar la caja fuerte ...

Parece que está intentando evitar implementar la autenticación real. Es posible que desee considerar la implementación del control de acceso real (autenticación y autorización), así como algo parecido a la gestión de derechos de información.

Como mínimo, puede solicitar algún código, token o identificador cuando el archivo se carga como puerta de enlace antes de proporcionar acceso. Por ejemplo, usted envía el enlace por correo electrónico y solo pueden acceder al archivo real una vez que ingresan nuevamente su correo electrónico. Proporciona cierta protección contra la indexación accidental, pero no en otros casos.