it-swarm.dev

Perché il passaggio dell'ID sessione come parametro url non è sicuro?

Di recente ho seguito una discussione, in cui una persona ha affermato che il passaggio dell'ID sessione come parametro url non è sicuro e che i cookie devono essere utilizzati al suo posto. L'altra persona ha affermato il contrario e ha sostenuto che Paypal, ad esempio, sta trasmettendo l'id di sessione come parametro url per motivi di sicurezza.

Il passaggio dell'ID sessione come parametro url è davvero insicuro? Perché i cookie sono più sicuri? Quali possibilità ha un utente malintenzionato per entrambe le opzioni (cookie e parametro url)?

59
Jonathan Egerton

Il passaggio dell'ID sessione come parametro url è davvero insicuro?

Sebbene non sia intrinsecamente insicuro, può essere un problema a meno che il codice non sia ben progettato.

Diciamo che visito il mio forum preferito. Mi accede e aggiunge il mio ID di sessione all'URL in ogni richiesta. Trovo un argomento particolarmente interessante e copia e incolla l'URL in un messaggio istantaneo per il mio amico.

A meno che l'applicazione non abbia adottato delle misure per garantire che esista alcuni forma di convalida sull'ID sessione, l'amico che ha fatto clic su quel link maggio eredita la mia sessione, quindi sarei in grado di fare qualsiasi cosa io possa fare, come me.

Memorizzando gli identificativi di sessione nei cookie, si elimina completamente il problema di condivisione dei collegamenti.

Esiste una variazione su questo tema chiamata fissazione della sessione , che comporta una condivisione intenzionale di un identificatore di sessione per scopi dannosi. L'articolo di Wikipedia collegato approfondisce come funziona questo attacco e in che cosa differisce dalla condivisione involontaria dell'identificatore di sessione.

Perché i cookie sono più sicuri?

I cookie possono essere più sicuri qui, perché non sono qualcosa che gli utenti normali possono copiare e incollare, o persino visualizzare e modificare. Sono un default molto più sicuro.

Quali possibilità ha un attaccante per entrambe le opzioni?

Neanche di questi metodi è protetto da attacchi man-in-the-middle su comunicazioni non crittografate. I componenti aggiuntivi del browser, spyware e altri elementi dannosi sul lato client possono anche spiare entrambi i metodi di memorizzazione degli identificativi di sessione.

In entrambi i casi, è consigliabile convalidare sul lato server che il client che afferma di possedere un ID di sessione. Di cosa è composta questa validazione è in discussione. Tieni presente che gli utenti dietro i proxy aziendali possono spostarsi tra gli indirizzi IP tra le richieste, quindi bloccare una sessione a un indirizzo IP può alienare accidentalmente le persone. L'articolo fissazione della sessione menziona alcune altre utili alternative.

76
Charles

La maggior parte dei siti Web memorizza lo stato di accesso del proprio utente nella sessione e, se un utente malintenzionato ha l'id di sessione, ha anche i privilegi dell'utente che ha effettuato l'accesso. In altre parole, le due preoccupazioni relative al mantenimento della sessione e all'autenticazione sono spesso associate.

Un problema è che è facile effettuare attacchi fissazione della sessione . In questo caso, un utente malintenzionato invierebbe all'utente un URL preparato con un ID sessione noto. Se l'utente fa clic su questo URL e fa un login, l'attaccante avrebbe una sessione con privilegi. Se il sito Web richiede un cookie, un URL preparato in un'email non sarà sufficiente.

Se un sito utilizza HTTP mischiato con HTTPS, l'id verrà trasmesso in chiaro nell'URL per tutte le richieste HTTP (anche per una richiesta di immagine). Quindi, se l'attaccante può leggere una singola richiesta HTTP dopo che l'utente ha effettuato l'accesso, conosce l'id della sessione.

Una soluzione al problema sarebbe quella di separare le due preoccupazioni, mantenendo la sessione e l'autenticazione. È quindi possibile lasciare l'ID sessione non protetto, solo per mantenere la sessione e utilizzare un cookie separato per verificare lo stato di accesso. Questo cookie deve essere configurato per essere inviato solo alle pagine HTTPS.

23
martinstoeckli

Oltre a quanto affermato da Charles e Martin, l'inserimento di qualsiasi cosa nell'URL rende più probabile la perdita. Ciò può avvenire tramite un'intestazione Referer in una risorsa collegata, dall'accesso all'endpoint con i record della cronologia del browser, dallo sniffing della cronologia della forza bruta, dai registri Web inappropriati e così via. Quindi è generalmente sconsigliabile mettere tutto ciò che si desidera mantenere segreto in una stringa URL/query.

Non ho visto Paypal usando gli ID sessione server negli URL. Non c'è modo che sia davvero più sicuro dei cookie; la ragione per cui in genere veniva eseguita in passato era supportare i browser senza i cookie abilitati. Questo è sempre meno un problema in questi giorni, e i problemi di usabilità di non condividere i collegamenti, oltre agli attacchi di fissazione della sessione, significano che la sessione nell'URL di solito è evitata oggi.

15
bobince

Qualcosa che ho visto qualche anno fa è stato che qualcuno ha copiato un URL (CON sessionid) su Twitter. Tutti i follower hanno quindi avuto pieno accesso all'account di quelle persone su quel sito.

Quindi sì, inserire un sessionID nell'URL è una cattiva idea.

7
Niels Basjes