Suggerimenti per evitare il dirottamento dei cookie in un'applicazione web

Dovresti proteggere la trasmissione GUID (considera la possibilità che un server si proponga come un altro server o man-in-the-middle); Sospetto strongmente che questo si evolva rapidamente in qualcosa che richiede la crittografia asimmetrica e, infine, una versione ridotta di HTTPS. Poiché l'HTTPS completo è già disponibile, sembra una duplicazione dello sforzo.

D'altro canto, l'utilizzo di un GUID (che agisce, quando tutto è detto e fatto, come una chiave condivisa [temporanea]) non si difende dal compromettere il client (malware, analisi forense, forse anche ingegneria sociale a seconda di come è stata progettata l'interfaccia). Per questo, è necessario un sistema di escrow affidabile locale - una sorta di smart card sicura, in modo che non sia possibile leggere e duplicare ciò che è effettivamente all'interno, pur essendo in grado di provare a una terza parte (il server) che i dati sono là .

Ma a quel punto avremmo davvero bisogno di cookie ? Avremmo una smart card con i dati di accesso dell'utente conservati in modo sicuro; sarebbe quindi molto più semplice collegare la sessione non al browser, ma al username . La funzione "ricordami" verrebbe eseguita collegando la smart card.

Un'altra possibilità più semplice sarebbe, come suggerisce l'utente lesto, di archiviare il segreto concordato privatamente in un'area protetta da password - un "portachiavi", "portafoglio" o "portafoglio" - proprio come le password dei moduli. L'utente sblocca il portachiavi con una password principale, quindi il browser può autenticarsi.

Ma l'intero schema può essere implementato in modo più diretto costringendo i cookie sicuri ad essere archiviati nell'area protetta insieme alle password memorizzate nella cache . Alla ricezione di un cookie tramite una connessione protetta, il browser chiede all'utente di sbloccare l'area protetta, trovare un cookie con lo stesso nome per lo stesso dominio già esistente e quindi ripetere la richiesta, inviando questa volta il cookie previsto. Dal punto di vista dell'utente, entra in un sito sicuro con l'opzione "Ricordami" abilitata, appare un popup del browser che richiede la password principale e in seguito sa che ha effettuato l'accesso.

Un utente malintenzionato non avrebbe alcun modo (weeeellll ...) di accedere allo scambio HTTPS e, se dovesse impossessarsi del computer, troverà cookie e password in un blocco crittografato AES-256 per il quale gli manca l'accesso principale chiave.

Ciò che stai suggerendo ha diverse implicazioni sulla privacy e sulla sicurezza e non funzionerebbe in generale, poiché non puoi garantire l'autenticità dei tuoi GUID menzionati:

1. Può essere catturato facilmente, devi solo reindirizzare l'utente a qualsiasi server web a cui hai accesso.
2. Non c'è nulla che impedisca a qualcuno di scrivere un browser personalizzato (o modificare il codice sorgente di uno esistente) per falsificare il GUID, quindi i tuoi punti "che non dovevano essere modificati (in nessuna circostanza)" non funzionerebbero davvero.
3. Ci sono varie altre implicazioni sulla privacy con questa soluzione, come essere in grado di tracciare qualcuno in modo univoco (se non si guardano i punti precedenti).

Wouldn't this solve the issue of session-hijacking/cookie-hijacking completely, as a cookie from one browser would then be totally useless for another browser ?

Non completamente. Cosa succede se qualcuno dirotta il tuo cookie sullo stesso computer? (Computer pubblico). E, chi invia il GUID? Il browser stesso, quindi lascia una grande vulnerabilità, in quanto potresti anche copiare il GUID. Non fidarti mai dell'input dell'utente!

Ti suggerisco di dare un'occhiata a HttpOnly: link

Cambia "GUID" con una chiave privata, generata al primo avvio del browser / fornita dall'utente (o magari basata sul dominio) e un modo per firmare e identificare la risposta del cliente.

Questo è esattamente il modo in cui funziona l'auto-autenticazione basata su shell sicura (SSH). Ma per rendere reale devi modificare il browser per utilizzare una chiave privata fissa o basata sul dominio, aggiungi una pagina di accesso in cui un login riuscito carica la chiave pubblica del client e dovrà essere memorizzato e mod il server HTTPS per controllare l'identità del cliente rispetto a quella memorizzata.

Tieni presente che questo è molto simile al HTTPS effettivo, devi "solo" aggiungere la chiave del client persistente e la chiave del lato server < - > la ricerca della sessione.

In realtà si chiama "handshake TLS autenticato dal client", ma lo scambio di chiavi con l'accesso classico è fuori standard.

Quindi la tua sessione è protetta fintanto che la chiave privata è protetta, ma poiché già molti browser danno il modo di archiviare la password, non dovrebbe essere considerata una grande preoccupazione