Sforzandosi di dimostrare / sfruttare un dirottamento di sessione di base

La copia del cookie di sessione è il modo comune per dirottare una sessione. Ci potrebbero essere diversi motivi per cui non funziona nel tuo caso:

• Il cookie di sessione che hai dirottato non è più valido. Un'applicazione Web protetta invalida una sessione non appena l'utente si disconnette: sei sicuro che la sessione di destinazione sia ancora attiva nel momento in cui l'hai dirottata?
• L'applicazione potrebbe associare una sessione ad attributi aggiuntivi come l'indirizzo IP o le caratteristiche del browser. Non è terribilmente comune ma complicherebbe il tuo attacco.
• Non stai applicando correttamente il cookie dirottato nel tuo browser. Può essere poco pratico impostare i cookie manualmente. Assicurati di aver chiuso tutte le schede quando cambi i cookie in modo che il sito non possa riaggiungerli immediatamente.

Per quanto riguarda l'ultimo punto, proverei a riprodurlo il più semplicemente possibile usando gli strumenti da riga di comando. Ciò esclude la possibilità di eventuali effetti collaterali del browser. Ad esempio, puoi utilizzare curl(1) per inviare una richiesta (utilizzando -b per impostare il cookie), simile a questo:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

Una risposta autenticata indicherebbe che l'impostazione del cookie è sufficiente per rilevare una sessione.

On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?

Il flag HttpOnly protegge i cookie, ma non contro XSS in generale. Impedisce solo i cookie di essere esposti al DOM. Ad esempio, su Github il cookie user_session è impostato nel tuo browser ma rimane invisibile tramite document.cookie . Ci sono molti altri modi per sfruttare un difetto XSS piuttosto che rubare i cookie che funzionerebbero come una buona prova di concetto.

Sembra che il cookie di sessione abbia l'opzione HttpOnly . Non puoi estrarlo utilizzando document.cookie , tuttavia il sito è ancora vulnerabile.

Il tuo payload XSS è JavaScript in esecuzione nel contesto del sito vulnerabile. Il JavaScript può richiedere pagine sul sito e il browser allegherà automaticamente i cookie, inclusi quelli di HttpSolo. Poiché sei nel contesto del sito, il tuo JavaScript può leggere le risposte. È possibile utilizzarlo come una specie di proxy in modo che tu, come utente malintenzionato, possa navigare nel sito come se avessi effettuato il login come vittima.

Questo è un po 'complicato da fare, ma ci sono un paio di strumenti per aiutarti:

• BeEF - The Browser Exploitation Framework - questo è un complesso framework di attacco con molte caratteristiche. Sfortunatamente, ho trovato un po 'inaffidabile.
• HttpPwnly - questo è uno strumento più semplice scritto da un mio amico. Prova solo a fare l'attacco proxy, non le altre cose che fa BeEF, e lo fa in modo più affidabile.

Se il tuo server di destinazione ha attivato il metodo TRACE HTTP, puoi bypassare il flag HTTPOnly. L'attacco è chiamato Cross-Site Tracing (XST).

L'attacco Traccia tra siti ha il payload XSS che invia una richiesta TRACE HTTP al server web (proxy, inoltro o inverso), che restituirà al client la richiesta completa inclusi i cookie, httpOnly o no. Il payload XSS può quindi analizzare le informazioni restituite e ottenere i cookie.

Altre informazioni qui:

Bello strumento per XST

Spiegazione OWASP XST

XST Research paper

Se il server ha il metodo HTTP Trace disabilitato puoi ancora attaccare l'applicazione e sfruttare client / utenti con molti altri vettori di attacco come:

Il dirottamento del browser.
Reindirizzamento.
Iniezione keylogger.
strumento di sfruttamento XSS Framework - BeEF
Raccomando anche di seguire questo blog su XSS - Brutelogic

Una volta dovevo fare qualcosa di simile

Prima di tutto devi identificare i cookie di sessione, puoi farlo semplicemente accedendo all'applicazione e rimuovendo i cookie uno a uno fino a quando non ti disconnetti

Dopodiché è sufficiente acquisire i cookie dal passaggio precedente. L'ho fatto usando bettercap + sslstrip per catturare il cookie, ho avuto qualche problema con il parser dei cookie di bettercap a questo punto quindi ho dovuto usarlo in modalità debug, registrare tutto e fare il grep del log per cercare i cookie corrispondenti

Potresti riscontrare una moderna webapp. Le webapp moderne trasmetteranno i dati dei client al frontend sotto forma di cookie o dati LocalStorage e mantengono gli ID di sessione solo HTTP. Lavoro con Django e questo è quello che fa fuori dagli schemi.