it-swarm-eu.dev

Perché il furto dei cookie non è sufficiente per l'autenticazione?

Ho provato a esportare tutti i miei cookie tramite l'estensione "Modifica questo cookie" in una pagina di accesso che utilizza l'autenticazione con cookie. Durante la disconnessione ho provato a inserire quei cookie sperando di essere loggato, ma non è successo nulla.

Dopo la ricerca sono venuto a sapere che i cookie inviati sono in forma crittografata. Ma la pagina non utilizzava alcuna crittografia TLS. Mi sto perdendo qualcosa?

MODIFICA: ho provato a utilizzare gli stessi cookie mentre Accesso eseguito ovvero ho esportato tutti i cookie e importato in una finestra di navigazione in incognito ma non è successo nulla.
Inoltre, questo tipo di attacco non sembra funzionare sui siti più popolari come Google, Facebook, ecc. Quindi, come proteggono da tali attacchi?

45
Kartikey singh

Tecnicamente, anche se il contenuto del cookie dovesse essere crittografato, se i cookie fossero correttamente copiati nel nuovo browser e il nuovo browser invia le stesse intestazioni HTTP (stessa stringa agente utente, referrer è come previsto, il computer ha lo stesso indirizzo IP e tutti gli altri headers il server potrebbe aver precedentemente archiviato e confrontato), il server teoricamente non sarebbe in grado di differenziare tra il browser originale e il nuovo browser.

Suppongo che stai cercando di copiare i cookie da un sito che ti accede automaticamente ogni volta che apri il browser e non ti sei disconnesso.

Alcuni siti potrebbero utilizzare altri modi per rilevare se si tratta di un cookie/sessione rubato, ma è un perdendo battaglia perché tutti quelli possono ancora essere falsificati. Es .:

  • Controlla se l'indirizzo IP è cambiato
  • L'utente-agente è lo stesso
  • Controlla se il referrer ha senso
  • Qualsiasi altra intestazione HTTP inviata dal browser

Per rispondere alla tua domanda, dovresti essere in grado di farlo funzionare se hai a che fare con un sito di accesso automatico e non ti sei disconnesso. Assicurati che tutte le intestazioni HTTP inviate dal tuo nuovo browser siano le stesse , che l'indirizzo IP sia lo stesso, il referrer sia quello atteso, lo stesso agente utente.

Si noti che forse anche il servizio che stai utilizzando sta utilizzando un secondo cookie che hai dimenticato di copiare e quindi crea un'anomalia e ti butta fuori.

57
Wadih M.

I contenuti di un cookie sono definiti dall'applicazione e ci sono molti modi per usarli. Ecco un breve elenco di alcuni dei possibili motivi per cui i tuoi sforzi sono falliti.

  1. Il cookie è associato all'indirizzo IP, all'impronta digitale del dispositivo o ad altri dati non cookie non acquisiti.
  2. Il cookie originale contiene una scadenza ed è passato.
  3. Il cookie è monouso, ovvero il server ruota il valore con ogni richiesta/risposta e annulla qualsiasi valore di cookie già utilizzato.
  4. Il cookie era associato a una sessione che non esiste più sul server (potenzialmente perché ti sei disconnesso).
  5. Il cookie è associato a un elemento nascosto all'interno della pagina (ad esempio un token CSRF) e non è stato acquisito o ricreato quel valore.
  6. Il server è bilanciato dal carico, con stato della sessione in proc e un meccanismo di viscosità della sessione temporanea applicato dal bilanciamento del carico. Nella nuova sessione, al client è stato assegnato un nodo diverso all'interno della farm in cui la sessione non esiste.
  7. Il web server utilizza un motore di regole per rilevare attività sospette e il tuo cookie contraffatto è stato presentato fuori sequenza o in un momento imprevisto.
  8. I cookie andavano bene, ma hai incasinato altri dettagli, come l'intestazione del referrer.
32
John Wu
  1. I cookie stessi potrebbero essere stati firmati o crittografati, non la connessione che li ha forniti.
  2. Il server potrebbe aver rimosso la sessione dal suo database quando ti sei disconnesso.
30
user169249

Come accennato, quando ti sei disconnesso, il server ha invalidato il cookie che hai appena rubato, rendendolo inutile per aver cercato di fingere di essere te stesso.

Quindi, se vuoi veramente testare cercando di rubare i tuoi cookie per testare ciò che è necessario per rubare la tua sessione da questo particolare servizio web, dovrai esportare i tuoi cookie e importarli in un nuovo browser/modalità di navigazione in incognito senza disconnetterti dal tuo scheda del browser originale.

Ma, solo per notare, i cookie vengono spesso controllati rispetto a una serie di altri criteri. Possiamo verificare contro IP, user-agent, ecc. https://wingsdream.wordpress.com/tag/mitigating-http-session-hijacking/

Potremmo anche escogitare strategie ancora più intelligenti, come un sistema di aggiornamento continuo dei token o l'impronta digitale del browser, per verificare che la persona in possesso di questo cookie sia la persona a cui abbiamo dato quel cookie e che non sia stato rubato. Pertanto, anche se "rubi" i cookie di autenticazione, potresti non essere in grado di autenticarti con essi.

8
Kallmanation

La sessione è stata invalidata sul server. I siti Web sicuri lo fanno per prevenire esattamente il tipo di attacco che stai descrivendo. Quando ci si disconnette, il server elimina la sessione dal proprio database in modo che anche se gli stessi cookie di sessione sono stati utilizzati di nuovo, non saranno accettati dal server. Ecco perché è importante disconnettersi correttamente dal sito Web invece di chiudere semplicemente il browser, anche se il browser non conserva i cookie.

I siti Web non sicuri possono lasciare la sessione in giro sul server in modo tale che anche dopo aver effettuato il "logout" (ovvero la cancellazione dei cookie dal browser), gli stessi cookie di sessione possano essere riutilizzati in seguito.

Prova a ripetere l'esperimento, ma questa volta non esci prima. Accedi al sito Web e quindi elimina manualmente i cookie dal tuo browser. Se visiti di nuovo il sito Web senza i cookie, non verrai eseguito l'accesso. Ora ripristina i cookie e prova a visitare nuovamente il sito Web e dovresti accedere nuovamente.

4
Micheal Johnson

Per i siti semplici la copia dei cookie dovrebbe essere sufficiente. Un sito più "sicuro" blocca la sessione come altri hanno menzionato altri fattori come l'IP.

C'è anche la possibilità che esista un codice javascript che controlla altri valori persistenti come Local/Session Storage, IndexDB e così via. Prova a dare un'occhiata a loro. Sarebbe anche possibile che si tratti di un'applicazione a sito singolo in cui tutti i dati vengono caricati tramite ajax e oAuth insieme a una forma di archiviazione persistente. Nessun cookie necessario poiché il segreto è archiviato altrove.

1
Fritz

In molti casi rubare i cookie È abbastanza per autenticare, è probabile che tu abbia fatto qualcosa di sbagliato.

Nota, TLS/crittografia non sono rilevanti qui. Quando leggi il cookie dall'intestazione, il traffico è già stato decrittografato. Tutto chrome mostra che è già decrittografato, la crittografia è completamente trasparente.

Per rispondere alla domanda Gli schemi di autenticazione variano. A volte usano solo i cookie, nel qual caso basta rubarli. A volte non usano affatto i cookie. A volte usano un mix di cookie e altri dati.

Esistono infiniti schemi di cookie. Non esiste una risposta semplice per tutti loro.

0
Matviy Kotoniy