Ad esempio, questo codice (pseudo) funziona?
let t = timeRightNow()
let message = stuffWhoseTimingCantBeLeaked()
waitUntilTime(t+1 second)
send message
O simili? In questo modo il tempo di invio del messaggio non dipende dal tempo di stuffWhoseTimingCantBeLeaked() .
Un utente malintenzionato sarebbe ancora in grado di determinare per quanto tempo è occorso un% di co_de per eseguire?
Fintanto che t + s è sufficiente per coprire eventuali ritardi nelle risposte introdotte da un attacco di stile DDoS, dove s è il numero di secondi.
Cioè, colpire un listener di servizio che chiama quanto sopra per incoraggiare stuffWhoseTimingCantBeLeaked() a impiegare più tempo di s potrebbe rivelare all'avversario quanto tempo, in media, richiede stuffWhoseTimingCantBeLeaked() da eseguire, una volta che la t + s barriera è rotta.
Per mitigarlo, puoi mascherare questo tempo extra rilevando quando la tua funzione impiega più tempo:
let t = timeRightNow()
let s = 1
let waitTime = t + s
let message = stuffWhoseTimingCantBeLeaked()
let executeTime = timeRightNow() - t
if timeRightNow() > waitTime
waitUntilTime(timeRightNow() + executeTime * csprng(2,1)) # Random wait of between 1 and 2 times the original execution time (integer)
else
waitUntilTime(waitTime)
send message
Nota però, con abbastanza richieste potrebbe essere possibile ottenere una media che si uniformi, colando il tempo necessario per eseguire stuffWhoseTimingCantBeLeaked() .
Con valori più alti di s , il rischio può essere ulteriormente ridotto, a scapito delle prestazioni. È inoltre possibile introdurre il rilevamento se il servizio Web viene richiesto ripetutamente da un determinato utente o da un indirizzo IP e quindi limitare la connessione.
Leggi altre domande sui tag web-service timing-attack