La divulgazione dell'ora locale del server agli utenti causa rischi di sicurezza?

Non riesco a vedere come divulgare il server in locale potrebbe aiutare negli attacchi. Presumo che la maggior parte dei server di produzione utilizzi la sincronizzazione in modo che la loro ora UTC sia precisa ed uguale su qualsiasi server.

Più per me la nozione di ora locale in locale solo per un ambiente: processi diversi sullo stesso server potrebbero utilizzare orari locali diversi. Al massimo potrebbe aiutare un aggressore a localizzare dove potrebbe trovarsi il server sul pianeta. Ma anche questa informazione ha un valore limitato perché in alcune grandi organizzazioni i server e le applicazioni vengono eseguiti internamente in UTC per consentire backup facili tra server su continenti diversi.

Nota: presumo che reimpostare la password sia un'operazione che può essere eseguita senza essere loggato sul sito.

If I type myself an URL that match to the format it will work ? Sure it will work, you just have to pass proper cookie values with the request (which is what any browser does).

Hai un problema, questo significa che se io lo uso per verificare come il tuo formato è il tuo URL, e poi cambio il mio id per abbinarlo a un altro utente, e aggiorno la parte del tempo per essere nella finestra di 5mn che sono probabilmente in grado di ripristinare la password di tutti.

Come gestirlo? Considera il seguente formato <userID>|<time> che codifichiamo a 64 bit per essere sicuro di non avere problemi con i browser.

Questo formato è davvero semplice da decifrare, tuttavia non è difficile migliorare la sicurezza:

1. ogni volta che generi un token, salvalo nel database
2. ogni volta che controlli un token, controlla se esce nel database, se non è scaduto, accetta la richiesta.
3. Aggiungi un piccolo programma di pianificazione che eliminerà tutti i token che durano per più di 5 minuti.

Se vuoi aumentare ancora di più: usa un altro utente quando scrivi dati (inserisci / cancella) nella tabella dei token e rimuovi insert / update / cancella scrivi all'utente principale che gestisce il resto dell'applicazione. Quindi, se hai qualche difetto di iniezione SQL, finché è localizzato usando l'altro account utente, non sarà in grado di toccarlo.

Sembro interpretare la domanda con alcune sfumature. Li elenco come li ho capiti:

• L'attenzione si concentra solo sul token temporale. C'è un rischio per la sicurezza? - Sparando dal fianco, direi che non ci sono modelli in gettoni. Se io sono l'attaccante e il token è una combinazione di pochi pezzi statici (o casualità prevedibile) e il token temporale, sarei in grado di prevedere i token. Ad esempio, Burp mi consente di campionare un gruppo di token e prevederne di nuovi.
• L'attenzione si concentra sulla sincronizzazione con il server - tralascia del tutto il token dell'ora. Memorizza l'intero token sul lato server durante la generazione, quindi verifica questo quando l'utente invia questo token per freschezza, validità ecc. (Sulla falsariga della risposta di Walfrat)

Personalmente, credo sempre che il cattivo sia sempre due passi avanti a me. Cerco di dare il minimo di informazioni sul mio ecosistema di applicazioni il più possibile.

Non vedo alcun problema con l'autore dell'attacco che è in grado di dire all'orario del tuo server dall'utilizzo dei timestamp negli URL di reset, perché se:

1. Il tuo server è ragionevolmente sincronizzato all'orario ufficiale (come dovrebbe!);
2. L'attaccante può osservare alcune delle azioni del tuo server o interagire con esso;
3. L'attaccante ha una certa conoscenza di come funziona il tuo server (che dovresti assumere pessimisticamente);

... quindi suppongo che l'attaccante possa indovinare quali eventi sono accaduti sul tuo server e stimare ragionevolmente a che ora hanno fatto.

Quello su cui rifletterei più è se un utente malintenzionato possa profittare forge degli URL di ripristino. Mentre descrivi il tuo sistema, tale falsificazione sarebbe quasi banale. Pertanto, vorrei riflettere su quali attacchi questo potrebbe consentire, ad esempio un pirata informatico potrebbe essere in grado di inviare email contraffatte ai propri utenti con link di ripristino API validi. Forse non è il problema più grande del mondo, però.

In ogni caso, se i falsi sono un problema, una soluzione sarebbe incorporare un codice di autenticazione dei messaggi nella chiave API reimpostare gli URL. Il più popolare è HMAC ; faresti qualcosa del genere:

1. Ogni server che genera URL di ripristino e risponde alle richieste genera una chiave segreta casuale. Idealmente un effimero one-one che vive solo nella memoria e non è mai salvato su disco.
   • Alternativa: se la chiave API client è un segreto condiviso generato da crittografia, utilizzare una chiave MAC derivata da esso. Una funzione di derivazione appropriata sarebbe HMAC(api_key, "URL authentication subkey") , dove la stringa "URL authentication subkey" è una "stringa di informazioni" che descrive l'uso della chiave derivata, la stringa letterale "URL authentication subkey" è una buona scelta.
2. Quando generi un URL di reimpostazione della password, calcoli un MAC con quella chiave segreta su una stringa delimitata che contiene questi campi:
   • Protocollo URL, nome host e percorso;
   • Nome utente, data e ora e qualsiasi altro parametro URL.
3. Inserisci il risultato MAC nell'URL come parametro aggiuntivo.
4. Nel gestore che risponde agli URL di ripristino, ricalcolare il MAC utilizzando la chiave segreta e l'URL della richiesta e verificare che corrisponda al MAC inviato dal client. Assicurati di confrontare i valori MAC con confronto dell'eguaglianza costante in tempo !

Si noti che questo tipo di controllo dell'autenticità dell'URL non ha nulla a che fare con i timestamp in particolare, quindi è qualcosa che potrebbe presumibilmente voler usare genericamente per prevenire altri attacchi .

Ci sono state (e probabilmente lo sono ancora) alcune persone che hanno scritto codice per generare un token casuale usando il tempo come seme del loro generatore casuale. È qui che sapere l'ora del tuo server può consentire a un hacker di indovinare un tale token. (cioè il token è basato su un tempo specifico e quindi un hacker può "indovinare" il token testando con i token che la funzione genererebbe tra il tempo di accesso al server e il tempo in cui hai ricevuto una risposta, è certamente piuttosto limitato e quindi possibile ottenere il token.)

Tuttavia, il processo che stai descrivendo non funziona affatto in quel modo.

1. Crea un token casuale (ad esempio, utilizza OpenSSL RAND_bytes() o un equivalente, non usare mai un timestamp in alcun modo per fare quella parte).
2. Salva quel token e la data in cui viene generato nel tuo database.
3. Invia un'email al tuo utente con l'URL e il token.
4. Quando l'utente accede nuovamente al tuo server, verifica che il token esista nel database e quindi utilizzi la data lì e assicurati che now < date + 5min. .
5. Elimina il token, quindi non può essere riutilizzato più di una volta.

Questo significa che il tuo database verrà riempito con token che nessuno ha mai usato a meno che tu non aggiunga anche un processo CRON che lo analizza e cancella le vecchie voci. In SQL sarebbe qualcosa di simile (controlla i tuoi documenti SQL per assicurarti):

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

In quello che hai descritto, avresti messo il timestamp lungo il token, il che significa che quando tornerà, posso inserire qualsiasi timestamp che mi piacerebbe e ciò significa che posso far durare il token per tutto il tempo che voglio. Questo è chiamato dati contaminati. In sicurezza, devi pensare ai dati inviati al tuo dal cliente come sempre temperato con ...