Se creo un servlet che restituirebbe pubblicamente il tempo del server (nessuna necessità di autenticazione), questo sarebbe un problema di sicurezza? Non potevo pensare a nessun problema con questo, ma in qualche modo qualcosa mi dice che potrei sbagliarmi.
Per spiegare meglio, questo end-point verrà utilizzato dalle app mobili per migliorare la loro sicurezza (per evitare barare regolando la data del dispositivo).
Il tempo del server è di scarsa utilità per un utente malintenzionato, generalmente, purché sia accurato. In realtà, ciò che viene rivelato non è il tempo corrente (dopotutto, escludendo la fisica relativistica, il tempo è costante ovunque), così come il tempo si alza. Si noti che, anche se non si rivela esplicitamente il tempo, ci sono spesso numerosi 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 potrebbero mostrare date dell'ultima modifica di pagine dinamiche, le risposte HTTP possono essere include l'ora e la data correnti nelle intestazioni di risposta, ecc.
Conoscere l'esatta inclinazione del clock di un server è solo un problema in modelli di minacce molto specifici:
L'inclinazione dell'orologio può essere utilizzata negli attacchi per deanonimizzare i servizi nascosti Tor.
Le applicazioni scritte male possono utilizzare il tempo del server per generare valori segreti.
Le condizioni ambientali del RTC possono essere rivelate in situazioni artificiali .
"Servlet" sembra che tu stia già utilizzando un server complesso.
Ci sono molti modi in cui i protocolli perdono tempo al server. Ad esempio, HTTP ha un popolare campo di intestazione per il tempo di creazione / modifica e i dati generati dinamicamente avranno sempre il tempo di sistema corrente, se usato correttamente.
Per motivi di autenticazione TLS, puoi anche eseguire una ricerca binaria 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 una nozione di tempo per sapere cos'è una chiave / certificato valido e cosa no. Se questo è il caso, molto probabilmente sarà un tempo coordinato da NTP. Quindi, non puoi davvero dire nulla sul server che un utente malintenzionato non saprebbe già - c'è davvero solo un tempo "corretto".
Se non stai facendo TLS: la perdita di tempo del sistema probabilmente non è la prima cosa da risolvere.
Per quanto riguarda la sicurezza: non è proprio sicuro che dovresti esporre un altro servlet solo per i dispositivi per capire il tempo mondiale.
To explain more, this end-point will be used by mobile apps to enhance their security (to avoid cheating by adjusting the device date).
Bandiera rossa . Stai dipendendo dall'integrità del tuo cliente per la sicurezza. Non farlo mai. Semplicemente non puoi fidarti di nulla che accada 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 siano conservate dal sistema operativo del telefono o dall'applicazione.
L'unica cosa che potrebbe davvero esporre un rischio per la sicurezza sono i timer e i contatori delle prestazioni ad alta precisione. Questi potrebbero essere utilizzati per determinare con precisione la durata del processo di crittografia sul server e da lì dedurre i dati segreti.
È improbabile che i dati di temporizzazione al millisecondo o alla normale frequenza di "tick" lo espongano.
Il tempo del server non è un segreto . Al contrario, sei strongmente incoraggiato a sincronizzare il tuo tempo con un'origine temporale oggettiva esterna (come un orologio atomico esposto attraverso un server orario).
Non essere un segreto ha due conseguenze:
Conoscere il tempo del server è di scarsa utilità per un utente malintenzionato. Quindi qui dovresti trovare i possibili effetti collaterali.
Vorrei rispondere a ciò sottolineando ciò che deriverebbe dal presupposto che esporre il tempo del server sarebbe di fatto un rischio. Significa che gli amministratori di sistema dovrebbero impostare orari casuali sui loro sistemi, perché qualsiasi server impostato sull'ora corretta sarebbe vulnerabile, dal momento che un tempo corretto o quasi corretto del server è solo facile da indovinare. Significherebbe anche uno sforzo di sviluppo estremo per tradurre una falsa impostazione in un tempo corretto per l'uso in ogni applicazione correlata al tempo. Ogni singolo file sul sistema avrebbe un timestamp sbagliato.
Nella mia esperienza, si invitano molti più problemi impostando orari errati del server, di quanto ci si possa aspettare con l'impostazione corretta. Alcuni esempi sono menzionati in altre risposte, ma è anche necessario considerare applicazioni o cluster distribuiti, dove le impostazioni di tempo corrette sono generalmente essenziali. Fondamentalmente qualsiasi informazione relativa al tempo memorizzata sarebbe errata.
Quindi se esponendo il tuo tempo di sistema sarebbe il tuo più grande rischio, sei stato fortunato. Ma molto probabilmente ci sono molte altre preoccupazioni alle quali non hai prestato abbastanza attenzione. Vedi link per problemi relativi alla sicurezza e best practice.
L'unica cosa che posso pensare è se hai esposto il tempo di "uptime" del server - questo potrebbe dare un'indicazione delle ultime patch installate; tuttavia ritengo che di solito non venga esposto pubblicamente, ma non è stato controllato, quindi potrebbe valer la pena di confermarlo se sei interessato.
Leggi altre domande sui tag api web-application