Questo approccio per proteggere i cookie è sicuro?

La risposta breve. Il tuo meccanismo è troppo complicato. Esiste una soluzione più semplice, migliore, più sicura: usa SSL a livello di sito e imposta il secure bit su tutti i tuoi cookie in modo che vengano inviati solo tramite connessioni crittografate (SSL).

Nitidezza tecnica. Se vuoi davvero discutere del tuo meccanismo proposto, possiamo parlarne, ma penso che le carenze tecniche specifiche in esso contenute siano secondarie al punto più generale che c'è un modo più semplice e migliore per farlo. Ecco alcune specifiche:

• La tua proposta presuppone che l'indirizzo IP del client non cambierà mai. Questa non è una buona ipotesi. Interromperà il web per alcuni utenti, in particolare per gli utenti mobili.

• La proposta crittografa il cookie ma non fornisce alcuna protezione di integrità o autenticazione dei messaggi. Questo è un errore. È quasi sempre un errore utilizzare la crittografia senza l'autenticazione dei messaggi.

• Stai inventando il tuo protocollo crittografico in miniatura. Questo è soggetto a errori e, se possibile, è meglio evitato.

• Il tuo schema non impedisce a un utente malintenzionato di riprodurre un vecchio cookie. A seconda di come la tua applicazione web utilizza i cookie, questo potrebbe essere un errore di sicurezza benigno o lieve.

Se risolvi questi difetti, la tua proposta non è del tutto irragionevole. Ad esempio, ASP.NET supporta la crittografia e l'autenticazione dei cookie utilizzando un MachineKey.

Tuttavia, non ti consiglio di seguire questa strada. Mentre probabilmente potresti correggere questi difetti dati gli sforzi di engouh, sospetto che la complessità di inventare come farlo correttamente sia probabilmente più di quanto tu sia qualificato per. Sono cose complicate e sarebbe facile sbagliare qualcosa. (Ad esempio, testimonia i vizi devastanti nella crittografia di ASP.NET, che ha permesso agli attacchi padding-oracle di decrittografare tutto e sconfiggere la sicurezza di tutta la crittografia.)

Consigli generali. Invece di provare a fare qualcosa di funky con la crittografia della tua cucina, ti suggerisco il seguente consiglio:

• In generale, essere riluttanti a memorizzare lo stato nei cookie. Invece, memorizzarlo nella sessione o nel database. In questo modo, tutto ciò di cui hai bisogno è un cookie di sessione.

• Utilizza il supporto integrato per la gestione delle sessioni del framework di programmazione web; non provare a tirare il tuo. (Se provi a lanciare il tuo, puoi facilmente ritrovare vulnerabilità come la fissazione della sessione.)

• Usa SSL in tutto il sito. Imposta il flag secure su tutti i cookie.

• Usa la difesa CSRF per tutte le richieste POST. Assicurati che tutte le richieste GET non abbiano effetti collaterali (le richieste con effetto collaterale devono essere inviate come POST).

• Leggi i materiali di OWASP sulla sicurezza delle applicazioni Web.

Perché mai vuoi memorizzare credenziali (anche cifrate) sul lato client? L'idea migliore è quella di tenere tutto in sessioni.

Inoltre, se vuoi pensare alla sicurezza dei cookie, non puoi dimenticarti di flag come: Secure e HttpOnly .

Http Only : questo ci protegge da ogni tipo di vulnerabilità XSS. Ciò significa che non è possibile accedere ai cookie con questo flag tramite lo script lato client (ovviamente funziona solo per i browser che supportano questo flag - al giorno d'oggi, quasi tutti).

Sicuro : questo flag "forza" il browser a utilizzare i cookie solo quando è impostata la connessione protetta / crittografata.

La soluzione generale che utilizzo per proteggere i cookie e le pagine sono

• Utilizza HTTPS per gli accessi e le pagine private come PM (o l'intero sito https)
• Invia di nuovo un cookie sicuro e solo HTTP con un token di 'login' o 'auth' (controlliamo che corrisponda all'utente). Questo token è utilizzato per pagine private come PM.
• Invia di nuovo un altro token di accesso / autenticazione che è solo http ma non sicuro, quindi può essere utilizzato per pagine non https (questo è opzionale.) Ma se vuoi visualizzare il nome utente, i messaggi o consentire a un utente di pubblicare commenti pubblici essere un modo per autorizzarli, quindi potrebbe essere necessario se lo desideri su pagine non https)
• Utilizza un cookie WantHttp, quindi se un utente fa clic su un link a una versione non http del sito verrà automaticamente reindirizzato alla versione https
• Avere un token CSRF che utilizza ogni forma in ogni pagina. Scelto a caso ma non uguale su tutti gli utenti (non costante)
• Avere lo stesso token CSRF come cookie solo HTTP. Ogni volta che si verifica una richiesta POST, controlla il modulo e il cookie per vedere se corrispondono. Nessuna ricerca nel DB richiesto (basta guardare i valori dei cookie e dei moduli). Se non corrispondono, un utente malintenzionato sta tentando di inviare automaticamente una richiesta per conto degli utenti. Gli attaccanti non possono sapere che cosa è il token dell'utente in quanto non possono richiedere pagine e leggerle. Non possono vedere il cookie httponly con js. Possono richiedere un http pagina mentre si sniffano i pacchetti e si leggono i cookie. In tal caso, usa sempre https su ogni pagina con un modulo e contrassegna il token cookie come sicuro.