Aggiornato per spiegare meglio cosa sta succedendo dopo aver fatto riferimento a il documento originale.
Poiché è la crittografia a blocchi e l'attaccante sta ingannando l'utente nell'inviare richieste, l'attaccante può forzare le richieste a 1) avere un blocco completo di padding e 2) avere un blocco in cui un determinato byte del cookie segreto è al fine. Poiché la decifratura del codice a blocchi è la stessa per blocco su un singolo flusso, l'utente malintenzionato prende l'intero blocco di padding e lo sostituisce con l'intero blocco che termina con il byte del cookie specifico, quindi lo invia al server. Se viene accettato, l'utente malintenzionato sa che l'ultimo byte del blocco cookie è decrittografato su 00000111 , che (tramite alcuni calcoli sui valori crittografati) consente all'utente malintenzionato di calcolare il byte non crittografato del cookie. Se non funziona (che non sarà 255 volte su 256), l'utente malintenzionato deve forzare l'utente a inviare una richiesta completamente nuova (il che significa un ciclo di crittografia completamente diverso, quindi avrà completamente diverso valori crittografati anche se sono gli stessi dati non criptati). Solo dopo che è stato accettato, l'attaccante cambia i valori, e ciò che lui / lei cambierà sarà solo la parte del cookie che si trova nell'ultimo byte del blocco che sta scambiando.
Vecchio post:
Dato che ci sono 2 8 = 256 valori diversi può essere un byte, e poiché l'attaccante non può predire quale sarà l'output, lui / lei deve indovinare fino a che l'ultimo byte non ha quello valore che è valido, vale a dire un valore di 7.
Per la natura dell'operazione XOR, se un input è statico, esiste esattamente un valore per l'altro input che produrrà un output desiderato. Quindi se c 7 è 01010101 , solo un e 7 di 01010010 risulterà in 00000111 . L'autore dell'attacco non può sapere c 7 , ma può cambiare e 7 (poiché è solo il valore del byte nella richiesta) finché il server non lo fa restituisce un errore.