Agregar valor hash a la URL proporcionada por el usuario en una aplicación web: ¿algún beneficio de seguridad?

0

Administramos una aplicación web Java desde un proveedor externo donde tenemos acceso al código fuente.

El usuario puede proporcionar una URL externa que se almacena en una base de datos y luego se incrusta en un sitio web generado por la aplicación web. Sólo los miembros de cosas pueden proporcionar URLs. La URL se ha escapado e incrustado correctamente en la página web como una llamada a un servlet de redirección junto con tres parámetros:

  • URL externa
  • marca de tiempo de la entrada de la base de datos
  • código hash

El hash se calcula a partir de la URL, la marca de tiempo y un secreto del servidor. El secreto del servidor es un GUID calculado al inicio.

El servlet de redirección recalcula el hash y emite un error si no coincide con el hash incrustado.

La desventaja es que en cada servidor, reinicie los cambios secretos del servidor y cualquier hash no será válido. El problema surge con los bots de búsqueda como Google o Yahoo, que ponen en cola las URL rastreadas a través de los reinicios del servidor. Por lo tanto, después de reiniciar el servidor, el registro de errores se inunda con mensajes de URL externas no válidas.

Mis preguntas:

  1. ¿Es este un patrón común en las aplicaciones web?
  2. ¿Cuáles son los beneficios de seguridad del hash?
  3. ¿Es "seguro" calcular el hash sin el secreto del servidor?
  4. ¿Existen patrones de seguridad que brinden el mismo beneficio de seguridad pero que no sean susceptibles a los reinicios del servidor?

Gracias

    
pregunta Claude 29.09.2014 - 10:12
fuente

1 respuesta

1

El esquema que describe se usa comúnmente para garantizar que un enlace esté actualizado, por lo que si alguien cambió el contenido, no habrá otras referencias que continúen funcionando. La generación de un nuevo GUID al reiniciar protege contra alguien que realiza cambios en la base de datos mientras el servidor está inactivo, lo que garantiza que se invaliden los enlaces antiguos.

Este esquema no tiene casi nada que ver con la seguridad, y todo que ver con la integridad de los datos. Aunque relacionadas, estas no son las mismas cualidades.

Así que ahora pregúntate: "¿Por qué necesitamos el hash? ¿Contra qué estamos tratando de protegernos?" Si no garantiza que sus usuarios siempre tengan datos absolutamente correctos y actuales, no necesita el hash. Si crees que sí, y puedes confiar de alguna manera en que tu base de datos no se modificará si el servidor se desconecta, entonces podrías eliminar el GUID del servidor para que las URL sobrevivan a los reinicios (aquí es donde surge el pequeño problema de seguridad, en En caso de que un atacante pueda desactivar su servidor y cambiar los datos mientras está fuera de línea.)

Si está viendo muchas entradas en sus registros debido a los reinicios del servidor, tal vez deba determinar por qué el servidor se está reiniciando tan a menudo que presenta un problema a sus usuarios. O quizás el problema no sea reiniciar el sistema, y sus datos cambian con mucha más frecuencia de lo que usted espera. O tal vez sus usuarios están dejando pasar el tiempo de espera de sus sesiones y están tratando de reutilizar los datos obsoletos con más frecuencia de lo que cree. Asegúrate de que las sesiones de usuario tengan un tiempo de espera adecuado para la tasa de cambio de tus datos.

    
respondido por el John Deters 29.09.2014 - 19:47
fuente

Lea otras preguntas en las etiquetas