attacco anti-replay per i cookie sicuri?

Una strategia più sicura consiste nel creare un'applicazione in cui è molto difficile ottenere l'ID di sessione in primo luogo. Imposta i flag Secure e HTTPOnly sul valore del cookie. Elimina le vulnerabilità XSS, CSRF e Clickjacking nell'applicazione.

Ho utilizzato mod_auth_tkt , che utilizza uno schema molto simile.

Suggerirei una considerazione molto attenta prima dell'uso della chiave di sessione SSL : la sessione utente (applicazione), le connessioni TCP / HTTPS e l'ID sessione SSL e la chiave sono tutte cose distinte. Non hanno necessariamente la stessa durata.

Inoltre, riutilizzare o riutilizzare il materiale crittografico è solitamente disapprovato (anche se non posso dire che ci sia sicuramente qualcosa di sbagliato con il suo uso in un HMAC, il problema è determinare l'opposto).

Nel caso di un browser / app web convenzionale, questo tipo di schema può avere problemi immediatamente evidenti, ad es. quando le schede del browser don condividere lo stato .

Quello che hai autenticato è uno "stato" del browser, legandolo a qualsiasi altra cosa (stato SSL o indirizzo IP) è irto. Il collegamento con l'ID sessione SSL è più comune (sebbene abbia una cronologia dei problemi MSIE). Uno dei modi migliori per ottenere questo è attraverso l'uso di certificati client, non banali da implementare e gestire, naturalmente.

Vedi questo per molte altre considerazioni: link e (ora completa) RFC 6896 Sessione cookie protetta (bozza collegata alla risposta accettata a la domanda a cui ti colleghi) ha una sezione dedicata ai problemi di riproduzione.