L'ora del server è di scarsa utilità per un utente malintenzionato, in genere, purché sia ​​accurata. In effetti, ciò che viene rivelato non è il tempo attuale (dopotutto, a parte la fisica relativistica, il tempo è coerente ovunque) quanto la differenza di tempo. Si noti che, anche se non si rivela esplicitamente l'ora, spesso ci sono molti modi per ottenere comunque l'ora del server locale. Ad esempio, TLS fino alla versione 1.2 incorpora l'ora corrente nell'handshake, le pagine web possono mostrare le date dell'ultima modifica delle pagine dinamiche, le risposte HTTP stesse possono includere l'ora e la data correnti nelle intestazioni delle risposte, ecc.

Conoscere l'esatto disallineamento dell'orologio di un server è un problema solo in modelli di minacce molto specifici:

• L'inclinazione dell'orologio può essere utilizzata negli attacchi per rendere anonimi i servizi nascosti di Tor.

• Le applicazioni scritte male possono utilizzare l'ora del server per generare valori segreti.

• Le condizioni ambientali dell'RTC possono essere rivelate in situazioni artificiose.

"Servlet" sembra che tu stia già eseguendo un server complesso.

Ci sono molti modi in cui i protocolli perdono l'ora del server. Ad esempio, HTTP ha un campo di intestazione popolare per l'ora di creazione / modifica e i dati generati dinamicamente avrebbero sempre l'ora di sistema corrente, se usati correttamente.

Per motivi di autenticazione TLS, puoi anche cercare binarie per trovare la data e l'ora di un endpoint utilizzando i certificati client in scadenza.

Questo è un male necessario: se stai facendo TLS, il tuo server deve avere un'idea del tempo per sapere cos'è una chiave / certificato valido e cosa no . Se è così, molto probabilmente sarà un momento coordinato dall'NTP. Quindi, non puoi davvero dire nulla sul server che un utente malintenzionato non saprebbe già: c'è davvero solo un momento "corretto".

Se non stai facendo TLS: l'ora di sistema che perde è probabilmente non è la prima cosa da sistemare.

Per quanto riguarda la sicurezza: Non sono proprio sicuro che dovresti esporre ancora un altro servlet solo per i dispositivi per capire l'ora mondiale.

Per spiegare di più, questo endpoint verrà utilizzato dalle app mobili per migliorare la loro sicurezza (per evitare barare modificando la data del dispositivo).

Bandiera rossa . Dipende dalla mancanza di modifiche del tuo cliente per la sicurezza. Non farlo mai. Semplicemente non puoi fidarti di tutto ciò che accade sui dispositivi dei tuoi utenti. Questi non sono i tuoi dispositivi. Possono semplicemente collegare un debugger e modificare le nozioni di tempo in memoria del processo, indipendentemente dal fatto che sia mantenuto dal sistema operativo del telefono o dall'applicazione.

L'unica cosa che potrebbe davvero esporre un rischio per la sicurezza sono i timer ad alta precisione e i contatori delle prestazioni. Questi potrebbero essere usati per calcolare con precisione quanto tempo un processo crittografico impiega sul server e da lì dedurre dati segreti.

È improbabile che i dati temporali al millisecondo o alla normale frequenza di "tick" lo rivelino. p>

L'ora del server non è un segreto . Al contrario, sei fortemente incoraggiato a sincronizzare il tuo tempo con una fonte di tempo oggettiva esterna (come un orologio atomico esposto attraverso un server orario).

Non essere un segreto ha due conseguenze:

1. non è necessario proteggerlo o nasconderlo. Puoi tranquillamente presumere che l'attaccante sia in grado di capire qual è l'ora corrente.
2. non dovrebbe avere una funzione su tutto ciò che desideri proteggere o nascondere. Ad esempio, non dovresti derivare chiavi o segreti dall'ora. Tutte le funzioni casuali che stai utilizzando dovrebbero essere inizializzate non con l'ora corrente (ancora un valore predefinito pigro in molti), ma con una migliore fonte seed.

Conoscere l'ora del server è di scarsa utilità per un utente malintenzionato. Quindi qui dovresti trovare i possibili effetti collaterali.

• La protezione per quel servlet è più debole (in qualche modo) di quella degli altri servlet? Quali sono le possibili implicazioni della non necessità di autenticazione in termini di attacchi DOS / DDOS. Potrebbe essere importante se l'autenticazione fosse elaborata in altri server più protetti. C'è qualche differenza per il proxy inverso?
• quali sono i rischi di falle di sicurezza in quel servlet? Ha seguito gli stessi controlli assicurativi di qualità degli altri servlet? E il suo ciclo di manutenzione?
• e il suo contenitore servlet?

Vorrei rispondere sottolineando ciò che deriverebbe dal presupposto che l'esposizione dell'ora del server sarebbe di fatto un rischio, significherebbe che gli amministratori di sistema dovrebbero impostare orari casuali sui loro sistemi, perché qualsiasi il server impostato sull'ora corretta sarebbe vulnerabile, poiché l'ora del server corretta o quasi corretta è solo facile da indovinare. Significherebbe anche uno sforzo di sviluppo estremo per tradurre un'impostazione falsa in un'ora corretta da utilizzare in ogni applicazione correlata al tempo. Ogni singolo file sul sistema avrebbe un timestamp errato.

In base alla mia esperienza, si creano molti più problemi impostando orari del server sbagliati, di quanto ci si possa aspettare con l'impostazione corretta. Alcuni esempi sono menzionati in altre risposte, ma devi anche considerare applicazioni o cluster distribuiti, dove le impostazioni corrette dell'ora sono generalmente essenziali. Fondamentalmente, qualsiasi informazione relativa al tempo che memorizzi sarebbe difettosa.

Quindi, se esporre il tuo tempo di sistema fosse il tuo rischio più grande, sei stato fortunato. Ma molto probabilmente ci sono molte altre preoccupazioni a cui non hai prestato abbastanza attenzione. Vedi https://www.owasp.org/index.php/Main_Page per problemi e best practice relativi alla sicurezza.

L'unica cosa a cui posso pensare è se hai esposto il tempo di "uptime" del server - questo potrebbe fornire un'indicazione delle ultime patch installate; tuttavia, credo che di solito questo non sia esposto pubblicamente, ma non l'ho verificato, quindi potrebbe valere la pena confermarlo se sei interessato.