Si creo un servlet que devolvería la hora del servidor públicamente (sin necesidad de autenticación), ¿sería un problema de seguridad? No se me ocurrió ningún problema con esto, pero de alguna manera algo me dice que podría estar equivocado.
Para explicar más, este punto final será utilizado por las aplicaciones móviles para mejorar su seguridad (para evitar trampas al ajustar la fecha del dispositivo).
El tiempo del servidor es de poca utilidad para un atacante, en general, siempre que sea preciso. De hecho, lo que se está revelando no es el tiempo actual (después de todo, salvo la física relativista, el tiempo es consistente en todas partes) tanto como el sesgo del tiempo. Tenga en cuenta que, incluso si no revela explícitamente la hora, a menudo hay muchas formas de obtener la hora del servidor local. Por ejemplo, TLS hasta la versión 1.2 incrusta la hora actual en el protocolo de enlace, las páginas web pueden mostrar últimas fechas modificadas de páginas dinámicas, las respuestas HTTP en sí mismas pueden incluya la hora y fecha actuales en los encabezados de respuesta, etc.
Conocer el sesgo de reloj exacto de un servidor es solo un problema en modelos de amenazas muy específicos:
El sesgo del reloj se puede usar en ataques para desasonizar los servicios ocultos de Tor.
Las aplicaciones mal escritas pueden usar la hora del servidor para generar valores secretos.
Las condiciones ambientales del RTC pueden revelarse en situaciones ideadas .
"Servlet" suena como si ya estuvieras ejecutando un servidor complejo allí.
Hay muchas formas en que los protocolos pierden tiempo del servidor. Por ejemplo, HTTP tiene un campo de encabezado popular para el tiempo de creación / modificación, y los datos generados dinámicamente siempre tendrían la hora actual del sistema, si se usan correctamente.
Por razones de autenticación TLS, incluso puede realizar una búsqueda binaria para encontrar la fecha y la hora de un punto final utilizando certificados de cliente caducados.
Este es un mal necesario: si está haciendo TLS, su servidor debe tener una noción de tiempo para saber qué es una clave / certificado válido y qué no. Si ese es el caso, es muy probable que este sea un tiempo coordinado por el NTP. Por lo tanto, realmente no se puede decir nada sobre el servidor que un atacante no supiera ya, en realidad solo hay un tiempo "correcto".
Si no estás haciendo TLS: la pérdida de tiempo del sistema probablemente no sea lo primero que deberías solucionar.
Respecto a la seguridad: no estoy seguro de que debas exponer otro servlet solo para que los dispositivos puedan calcular la hora mundial.
Para explicar más, este punto final será utilizado por las aplicaciones móviles para mejorar su seguridad (para evitar trampas al ajustar la fecha del dispositivo).
Bandera roja . Dependes de la modificación de tu cliente para la seguridad. Nunca hagas eso. Simplemente no puedes confiar en nada que suceda en los dispositivos de tu usuario. Estos no son tus dispositivos. Simplemente pueden conectar un depurador y modificar las nociones de tiempo en memoria de su proceso, sin importar si el sistema operativo del teléfono o su aplicación lo mantienen.
Lo único que realmente podría exponer un riesgo de seguridad son los temporizadores de alta precisión y los contadores de rendimiento. Se podrían usar para medir con precisión el tiempo que tarda un proceso criptográfico en el servidor, y de ahí deducir datos secretos.
Es improbable que los datos de tiempo en milisegundos o la tasa normal de "tick" expongan esto.
Saber la hora del servidor es de poca utilidad para un atacante. Así que aquí debería encontrar información sobre posibles efectos secundarios.
Me gustaría responder que al señalar, lo que seguiría de la suposición, que exponer la hora del servidor sería de hecho un riesgo. Esto significaría que los administradores del sistema tendrían que establecer tiempos aleatorios en sus sistemas, porque cualquier servidor configurado en el momento correcto sería vulnerable, ya que una hora del servidor correcta o casi correcta es simplemente fácil de adivinar. También significaría un esfuerzo de desarrollo extremo para traducir una configuración falsa a una hora correcta para su uso en cada aplicación relacionada con el tiempo. Cada archivo en el sistema tendría una marca de tiempo incorrecta.
En mi experiencia, invitas muchos más problemas al configurar tiempos de servidor incorrectos, de lo que puedes esperar con la configuración correcta. Algunos ejemplos se mencionan en otras respuestas, pero también debe considerar las aplicaciones distribuidas o los clústeres, donde la configuración de la hora correcta suele ser esencial. Básicamente, cualquier información relacionada con el tiempo que almacene será errónea.
Entonces, si exponer el tiempo de tu sistema sería tu mayor riesgo, tuviste suerte. Pero lo más probable es que haya muchas otras preocupaciones a las que no le hayas prestado suficiente atención. Consulte enlace para conocer los problemas relacionados con la seguridad y las mejores prácticas.
La hora del servidor no es un secreto . Por el contrario, se recomienda enfáticamente que sincronice su tiempo con una fuente de tiempo objetivo externa (como un reloj atómico expuesto a través de un servidor de tiempo).
No ser un secreto tiene dos consecuencias:
Lo único en lo que puedo pensar es si expuso el tiempo de "tiempo de actividad" del servidor: esto podría dar una indicación de los últimos parches instalados; Sin embargo, creo que esto no suele exponerse públicamente, pero no lo he comprobado, por lo que vale la pena confirmarlo si está interesado.
Lea otras preguntas en las etiquetas web-application api