Si quiero proteger una cadena de una modificación, ¿es suficiente para saltearla y trashearla?

Esta técnica se puede implementar de forma razonablemente segura. Vería esto como una técnica avanzada para un alto rendimiento: algo que solo debería hacer si está seguro de que sabe lo que está haciendo. Si no necesita un alto rendimiento, es más sencillo que el servidor valide que el usuario está autorizado para cada solicitud. Dicho esto, este patrón es en realidad bastante utilizado, especialmente cuando un sitio web dinámico entrega una red de distribución de contenido.

Debes usar HMAC para generar tu hash. Puedes usar HMAC con cualquier hash; Para este propósito, SHA-1 es bastante adecuado. Entre otras cosas, esto lo protege de los ataques de extensión de longitud .

El arreglo más simple es que el hash contiene un secreto de servidor fijo y la URL. El problema con esto es que una vez que un usuario tiene una URL con el hash, esto es válido para siempre. No puede revocar el acceso de un usuario a un recurso en particular.

Podemos solucionar esto parcialmente incluyendo una marca de tiempo en la URL. Cuando genere el hash, use la marca de tiempo actual. Cuando verifique un hash, también verifique que la marca de tiempo se encuentre dentro de un período que considere aceptable (quizás 24 horas). Existen otros enfoques para solucionar esto, como incluir el ID de sesión del usuario en la URL, aunque esto requeriría una búsqueda en la base de datos para verificar el hash.

Si tuviera que resolver esto, consideraría la creación de una variable de sesión temporal o una entrada de base de datos (cualquiera de los cuales se mantiene en el lado del servidor) y le daría una URL genérica al cliente donde esa URL genérica incluye la clave de búsqueda para el servidor URL lateral. La URL genérica determinaría la ubicación correcta y la redirigiría a ella.

Dado que indica que el navegador que tiene la URL verdadera (o que solo la modifica a algo similar) sería un problema, un mejor enfoque podría ser simplemente utilizar las URL únicas que se entregan a los clientes. La URL real no es accesible a través de las reglas del servidor, y usted crea un enlace que el cliente obtiene; ese enlace se limpia cuando ya no es necesario.

La primera regla de criptografía es que no escribas tu propia criptografía. El hash es criptográfico.

Desea garantizar la integridad y autenticidad de un mensaje. Lo que necesita es un código de autenticación de mensaje (MAC). Le recomiendo que use HMAC con un algoritmo de hashing apropiadamente fuerte. Ya debería haber una biblioteca o módulo en su idioma con una implementación probada de HMAC-SHA1 o HMAC-SHA256, por ejemplo.

Tu primer método no es una sal. Una sal, por definición, no debería tener ningún impacto en la seguridad si se filtra. Es para evitar revertir el hash, no para proporcionar seguridad contra la falsificación del hash.

De manera similar, un hash en sí mismo no prueba nada sobre el archivo a menos que esté firmado de tal manera que se pueda verificar su autenticidad. Lo que necesita es una firma para la URL que está pasando.

Si bien, fundamentalmente, hay otros problemas que realmente hacen que esto no sea una forma ideal de tratar la situación (y, como resultado, hay otros problemas en el modelo de seguridad), puede firmar el hash ya sea cifrando con una clave privada para que pueda ser verificada tanto por el cliente como por el servidor o por una clave simétrica para que el cliente no pueda generar un hash falso porque carecería de la verificación de autenticidad ya que no pudieron producir un valor cifrado para el hash.

No cree su propio sistema, use un sistema existente para firmar un valor si realmente necesita pasar el valor a través del cliente y mantenerlo inalterado. Sin embargo, preferiblemente, debe escribir su sistema de modo que el servidor pueda realizar un seguimiento de los valores que deben devolverse y debe vincular todos esos valores a algún token de sesión que intercambie de forma segura con el cliente (como el uso de una sesión HTTPS). ).

  

El navegador deberá inspeccionar la cadena y luego enviarla de vuelta sin modificar (es decir, solicitar el recurso al que apunta la URL). Si el navegador pudiera modificar la cadena, sería un riesgo de seguridad.

Siento que te estás acercando al problema desde un ángulo incorrecto. ¿Por qué es un riesgo de seguridad para un navegador modificar la URL? Ese es el trabajo del navegador.

Si desea proteger el recurso al que apunta la URL, hágalo en el lado del servidor . Requiera una forma de autenticación antes de que el servidor entregue el recurso solicitado al navegador. Esto puede ir desde una simple autenticación basada en sesión hasta esquemas más complejos como OAuth. Haz tu elección.

Puede almacenar los recursos solicitados en una ubicación temporal pero aleatoria en el sistema de archivos, y usar esa URL para recuperarla.

Considere los sitios que lo hacen completar una encuesta para descargar un PDF en particular. A menudo devuelven una URL como enlace

Una forma de hacerlo es cuando el usuario completa la encuesta, genera un número aleatorio, crea una carpeta temporal con ese nombre, coloca una copia del recurso en esa carpeta (más específicamente, crea un enlace simbólico al recurso). en esa carpeta), luego devuelva la URL al cliente. Cada 24 horas barre la carpeta de documentos y elimine todos los directorios con más de un día.

Esto resuelve sus problemas de persistencia y vida útil: use el sistema de archivos en lugar de una base de datos. La limpieza es un trabajo cron. Siempre que el número aleatorio sea lo suficientemente grande (he visto sitios que usan GUID para esta tarea), no se pueden adivinar. Ni siquiera requiere ningún conocimiento de criptografía, aunque siempre recomiendo usar un generador de números pseudoaleatorios seguro criptográficamente.