¿La divulgación de la hora local del servidor a los usuarios causa algún riesgo de seguridad?

No puedo ver cómo la divulgación del tiempo local del servidor podría ayudar en los ataques. Supongo que la mayoría de los servidores de producción utilizan la sincronización, por lo que su tiempo UTC es exacto y es el mismo en cualquier servidor.

Más para mí, la noción de hora local en solo un entorno local a uno: diferentes procesos en el mismo servidor podrían usar diferentes horas locales. A lo sumo, podría ayudar a un atacante a localizar dónde podría estar el servidor en el planeta. Pero incluso esta información tiene un valor limitado porque en una gran organización, los servidores y las aplicaciones se ejecutan internamente en horario UTC para permitir copias de seguridad fáciles entre servidores en diferentes continentes.

Nota: Supongo que aquí, restablecer la contraseña es una operación que se puede realizar sin iniciar sesión en el sitio.

  

¿Si me escribo una URL que coincida con el formato, funcionará? Seguro que funcionará, solo tienes que pasar los valores de cookie adecuados con la solicitud (que es lo que hace cualquier navegador).

Tiene un problema, esto significa que si yo uso esto para comprobar cómo formatea su URL, y luego cambio mi ID para que coincida con otro usuario, y actualizo la parte de tiempo para estar en los 5 millones de ventanas que estoy probablemente pueda restablecer la contraseña de todos.

¿Cómo manejar esto? Considere el siguiente formato <userID>|<time> que codificamos en 64 bits para asegurarnos de no tener problemas con los navegadores.

Este formato es realmente fácil de descifrar, sin embargo, no es difícil mejorar la seguridad:

1. cada vez que genere un token, guárdelo en la base de datos
2. cada vez que verifique un token, verifique si sale de la base de datos, si no ha caducado, acepte la solicitud.
3. Agregue un pequeño programador que eliminará cada token que dure más de 5 millones.

Si desea aumentar aún más: utilice un usuario diferente cuando escriba datos (insertar / eliminar) en la tabla de los tokens y elimine insertar / actualizar / eliminar escribir al usuario principal que maneja el resto de la aplicación. Por lo tanto, si tiene un defecto de inyección de SQL en algún lugar, siempre que se localice con la otra cuenta de usuario, no podrá tocar esa tabla.

Parece que estoy interpretando la pregunta con algunos matices. Los enumeraré como los entiendo:

• El foco está solo en el token de tiempo. ¿Existe algún riesgo de seguridad? Disparando desde la cadera, diría que asegúrate de que no haya patrones en tokens Si soy el atacante y el token es una combinación de algunos piezas estáticas (o aleatoriedad predecible) y el token de tiempo, sería capaz de predecir los tokens. Burp, por ejemplo, me permite probar un montón de tokens y predecir nuevos.
• El foco está en la sincronización con el servidor : omite el token de tiempo por completo. Almacene el token completo en el lado del servidor cuando genere, y luego verifique esto cuando el usuario envíe este token para su frescura, validez, etc. (en la línea de la respuesta de Walfrat)

Personalmente, siempre creo que el malo siempre está dos pasos por delante de mí. Intento dar la menor información posible sobre el ecosistema de mi aplicación.

No veo ningún problema por el hecho de que el atacante pueda indicar la hora del reloj de su servidor por el uso de marcas de tiempo en las URL de restablecimiento, porque si:

1. Su servidor está razonablemente sincronizado con la hora oficial (¡como debería!);
2. El atacante puede observar algunas de las acciones de su servidor o interactuar con él;
3. El atacante tiene algún conocimiento sobre cómo funciona su servidor (que debe asumir pesimista);

... entonces asumo que el atacante puede adivinar qué eventos ocurrieron en su servidor y estimar razonablemente a qué hora lo hicieron.

En lo que pensaría más es si un atacante puede falsificar las URL de forma rentable. Al describir su sistema, tal falsificación sería casi trivial. Así que pensaría en qué ataques podría habilitar esto, por ejemplo, un atacante podría enviar correos electrónicos falsificados a sus usuarios con enlaces de restablecimiento de API válidos. Aunque tal vez no sea el mayor problema del mundo.

En cualquier caso, si las falsificaciones son un problema, una solución sería incorporar un código de autenticación del mensaje en la clave API restablecer URLs. El más popular es HMAC ; Harías algo como esto:

1. Cada servidor que genera URL de restablecimiento y responde a las solicitudes genera una clave secreta aleatoria. Idealmente uno efímero, uno que vive solo en la memoria y nunca se guarda en el disco.
   • Alternativa: si la clave de la API del cliente es un secreto compartido generado criptográficamente, use una clave MAC derivada de ella. Una función de derivación adecuada sería HMAC(api_key, "URL authentication subkey") , donde la cadena "URL authentication subkey" es una "cadena de información" que describe el uso de la clave derivada; la cadena literal "URL authentication subkey" es una buena opción.
2. Cuando genera una URL de restablecimiento de contraseña, calcula una MAC con esa clave secreta sobre una cadena delimitada que contiene estos campos:
   • Protocolo de URL, nombre de host y ruta;
   • Nombre de usuario, marca de tiempo y cualquier otro parámetro de URL.
3. Coloque el resultado de MAC en la URL como un parámetro adicional.
4. En el controlador que responde a la URLS restablecida, vuelva a calcular el MAC usando la clave secreta y la URL de solicitud, y verifique que coincida con el MAC que envió el cliente. Asegúrese de comparar los valores de MAC con comparación de igualdad de tiempo constante !

Tenga en cuenta que este tipo de comprobación de autenticidad de la URL no tiene nada que ver con las marcas de tiempo en particular, por lo que es algo que podría desear utilizar de forma genérica para prevenir otros ataques .

Ha habido (y probablemente todavía hay) algunas personas que escribieron código para generar una ficha aleatoria usando el tiempo como la semilla de su generador aleatorio. Ahí es donde saber la hora de su servidor puede permitir que un pirata informático adivine tal token. (es decir, el token se basa en un tiempo específico y, por lo tanto, un pirata informático puede "adivinar" el token probando con los tokens que la función generaría entre el momento en que accedió al servidor y el momento en que recibió una respuesta, es ciertamente bastante limitado). por lo tanto, es posible obtener el token.)

Sin embargo, el proceso que estás describiendo no funciona en absoluto de esa manera.

1. Cree un token aleatorio (por ejemplo, use OpenSSL RAND_bytes() o una equivalente, simplemente no use una marca de tiempo de ninguna manera para hacer esa parte).
2. Guarde ese token y la fecha en que se generó en su base de datos.
3. Envíe un correo electrónico a su usuario con la URL y el token.
4. Cuando el usuario vuelva a acceder a su servidor, verifique que el token existe en la base de datos y luego use la fecha allí y asegúrese de que now < date + 5min. .
5. Eliminar el token, por lo que no se puede reutilizar más de una vez.

Esto significa que su base de datos se llenará con tokens que nadie usó a menos que también agregue un proceso CRON que lo escanee y elimine las entradas antiguas. En SQL sería algo como esto (verifique sus documentos SQL para asegurarse):

DELETE FROM tokens WHERE date < NOW() + '5min.'

En lo que describiste, pondrías la marca de tiempo a lo largo del token, lo que significa que cuando vuelva, puedo poner cualquier marca de tiempo que me gustaría y eso significa que puedo hacer que el token dure todo lo que quiera. Esto se llama datos contaminados. En seguridad, tiene que pensar que los datos enviados a su cliente por el cliente siempre están atenuados con ...