Fissazione sessione HTTP

Mallory non vuole l'ID della sessione di Alice. Mallory vuole che Alice compia azioni come se stessa, ma mentre il sito web pensa di essere Mallory. Come usare la sua carta di credito per comprare qualcosa che pensa di avere, ma che verrà effettivamente accreditata a Mallory.

Ci sono diversi vettori per questo attacco. Quello che hai menzionato, le sessioni senza cookie con l'ID di sessione nell'URL è uno. Mallory ha il controllo di un sottodominio e la possibilità di scrivere cookie per un dominio padre è un altro.

Nell'ambito di questo articolo, il punto è che ci sono 2 metodi diversi con cui Mallory ottiene il controllo sulla sessione di Alice. Dove i metodi differiscono è quando si considera il mondo più ampio in cui tale attacco può verificarsi.

• se Mallory può far sì che Alice faccia clic su un link e il sistema di destinazione consenta di impostare gli ID di sessione da un URL, Mallory può fissare l'ID di sessione.

Qui non è richiesto MITM.

• un ID di sessione fornito al client su un canale sicuro non può essere MITM senza interrompere il canale sicuro. Esistono estensioni al protocollo http che consentono a un cookie di essere contrassegnato solo restituito su connessioni HTTPS. Ma i cookie impostati tramite HTTP vengono restituiti sia su HTTP che su HTTPS. Quindi, se Mallory può interferire con le comunicazioni HTTP di Alice, può fissare il valore della sessione che verrà successivamente utilizzato su un canale sicuro.

Qui c'è solo un MITM del canale non protetto.

• Se Mallory può iniettare il suo javascript in qualsiasi pagina pubblicata dal sito di destinazione, tramite XSS, quindi può impostare la correzione dell'ID di sessione. Anche se ciò consentirebbe anche a lei di leggere un cookie con il flag sicuro e quindi dirottare la sessione, HTTP ha un'ulteriore opzione HTTPonly, che nasconde i cookie da javascript. Ciò sconfigge il dirottamento della sessione in-the-browser, ma non la fissazione della sessione.

Qui la mitigazione dell'utilizzo di HTTPS, anche se applicata con HSTS, è inefficace.

Solo il nome del cookie e il suo valore sono rinviati al server, non alle opzioni con cui è stato creato, al suo percorso, all'host, allo schema o alla scadenza, né a qualsiasi altra cosa sulla provenienza dei dati.

Ci sono anche scenari in cui il dirottamento è un attacco più efficace della fissazione.