L'exposition du temps du serveur est-elle un risque pour la sécurité?
Si je crée un servlet qui retournerait l'heure du serveur publiquement (pas besoin d'authentification), serait-ce un problème de sécurité? Je ne pouvais penser à aucun problème avec cela, mais quelque chose me dit que je peux me tromper.
Pour en savoir plus, ce point final sera utilisé par les applications mobiles pour améliorer leur sécurité (pour éviter la tricherie en ajustant la date de l'appareil).
Le temps du serveur est de peu d'utilité pour un attaquant, généralement, tant qu'il est précis. En fait, ce qui est révélé n'est pas l'heure actuelle (après tout, sauf physique relativiste, le temps est cohérent partout), mais le décalage temporel. Notez que, même si vous ne révélez pas explicitement l'heure, il existe souvent de nombreuses façons d'obtenir l'heure du serveur local. Par exemple, TLS jusqu'à la version 1.2 incorpore l'heure actuelle dans la poignée de main, les pages Web peuvent afficher les dernières dates de modification des pages dynamiques, les réponses HTTP elles-mêmes peuvent inclure l'heure et la date actuelles dans les en-têtes de réponse, etc.
Connaître le décalage d'horloge exact d'un serveur n'est qu'un problème dans des modèles de menace très spécifiques:
Le décalage d'horloge peut être utilisé dans les attaques pour désanonymiser les services cachés de Tor.
Les applications mal écrites peuvent utiliser le temps du serveur pour générer des valeurs secrètes.
Les conditions environnementales du RTC peuvent être révélées dans situations artificielles .
"Servlet" sonne comme si vous y exécutiez déjà un serveur complexe.
Il existe de nombreuses façons dont les protocoles font perdre du temps au serveur. Par exemple, HTTP a un champ d'en-tête populaire pour l'heure de création/modification, et les données générées dynamiquement auront toujours l'heure système actuelle, si elles sont utilisées correctement.
Pour des raisons d'authentification TLS, vous pouvez même effectuer une recherche binaire pour trouver la date et l'heure d'un point de terminaison à l'aide de certificats clients expirants.
C'est un mal nécessaire - si vous faites TLS, votre serveur doit avoir une notion du temps pour savoir ce qui est une clé/cert valide et ce qui ne l'est pas. Si tel est le cas, ce sera très probablement une heure coordonnée par le NTP. Donc, vous ne pouvez vraiment rien dire sur le serveur qu'un attaquant ne connaîtrait pas déjà - il n'y a vraiment qu'une seule "bonne" heure.
Si vous ne faites pas TLS: la fuite d'heure système n'est probablement pas la première chose que vous devez corriger.
En ce qui concerne la sécurité: je ne suis pas sûr de devoir exposer une autre servlet juste pour que les appareils puissent comprendre l'heure mondiale.
Pour en savoir plus, ce point final sera utilisé par les applications mobiles pour améliorer leur sécurité (pour éviter la tricherie en ajustant la date de l'appareil).
Drapeau rouge. Vous dépendez de la non-modification de votre client pour la sécurité. Ne fais jamais cela. Vous ne pouvez tout simplement pas faire confiance à ce qui se passe sur les appareils de vos utilisateurs. Ce ne sont pas vos appareils. Ils peuvent simplement brancher un débogueur et modifier les notions de temps en mémoire de votre processus, qu'il soit conservé par le système d'exploitation du téléphone ou par votre application.
L'heure du serveur n'est pas un secret. Au contraire, vous êtes fortement encouragé à synchroniser votre temps avec une source de temps objective extérieure (telle qu'une horloge atomique exposée via un serveur de temps).
Ne pas être un secret a deux conséquences:
- vous n'avez pas besoin de le protéger ou de le cacher. Vous pouvez supposer en toute sécurité que l'attaquant est capable de déterminer l'heure actuelle.
- il ne devrait pas avoir de fonction sur tout ce que vous souhaitez protéger ou cacher. Par exemple, vous ne devez pas dériver de clés ou de secrets de l'époque. Toutes les fonctions aléatoires que vous utilisez doivent être amorcées non pas avec l'heure actuelle (toujours par défaut paresseux dans de nombreux cas), mais avec une meilleure source d'amorçage.
La seule chose qui pourrait vraiment exposer un risque de sécurité est les temporisateurs et les compteurs de performance de haute précision. Ceux-ci pourraient être utilisés pour chronométrer avec précision le temps que prend un processus cryptographique sur le serveur, et à partir de là déduire des données secrètes.
Il est peu probable que les données de synchronisation à la milliseconde ou au taux normal de "tick" l'exposent.
La seule chose à laquelle je peux penser est que si vous exposiez le temps de "disponibilité" du serveur - cela pourrait donner une indication des derniers correctifs installés; Cependant, je pense que ce n'est généralement pas divulgué publiquement, mais je n'ai pas vérifié, donc cela pourrait valoir la peine de le confirmer si vous êtes intéressé.
Connaître l'heure du serveur est de peu d'utilité pour un attaquant. Donc, ici, vous devriez trouver des effets secondaires possibles.
- la protection de ce servlet est-elle plus faible (en aucune façon) que celle des autres servlets? Quelles sont les implications possibles de pas besoin d'authentification en termes d'attaques DOS/DDOS. Il pourrait être important que l'authentification soit traitée sur d'autres serveurs plus sécurisés. Y a-t-il une différence pour le proxy inverse?
- quels sont les risques de failles de sécurité dans cette servlet? A-t-il suivi les mêmes contrôles d'assurance qualité que les autres servlets? Et son cycle de maintenance?
- qu'en est-il de son conteneur de servlet?
Je voudrais répondre à cela en soulignant, ce qui découlerait de l'hypothèse, que l'exposition du temps du serveur serait en fait un risque. Cela signifierait que les administrateurs système devraient définir des heures aléatoires sur leurs systèmes, car tout serveur réglé à l'heure correcte serait vulnérable, car une heure de serveur correcte ou presque correcte est juste trop facile à deviner. Cela signifierait également un effort de développement extrême pour traduire un faux paramètre en une heure correcte à utiliser dans chaque application liée au temps. Chaque fichier du système aurait un horodatage incorrect.
D'après mon expérience, vous invitez beaucoup plus de problèmes en définissant des heures de serveur incorrectes, que vous ne pouvez vous attendre avec le paramètre correct. Certains exemples sont mentionnés dans d'autres réponses, mais vous devez également prendre en compte les applications distribuées ou les clusters, où des paramètres horaires corrects sont généralement essentiels. Fondamentalement, toute information liée au temps que vous stockez serait erronée.
Donc, si exposer l'heure de votre système était votre plus grand risque, vous aviez de la chance. Mais il y a très probablement de nombreuses autres préoccupations auxquelles vous n'avez pas prêté suffisamment d'attention. Voir https://www.owasp.org/index.php/Main_Page pour les problèmes liés à la sécurité et les meilleures pratiques.