Un utente non può cambiare le informazioni sulla sua sessione per impersonare gli altri?

Sì, se riesci a indovinare la chiave di sessione di un altro utente, puoi diventarli. Questo è il motivo per cui è necessario disporre di una chiave di sessione imprevedibile che può essere revocata.

Ci sono stati casi in cui le migliori pratiche non sono state seguite, ad esempio Moonpig ha prodotto un'API che utilizzava una chiave di sessione che era l'ID dell'utente che viene impostata sulla creazione dell'account come numero consecutivo. Questo significa che potresti essere qualsiasi utente. Se quell'utente volesse fermarti, non potrebbe, poiché è la chiave per tutte le sessioni in cui sono impegnati e non può essere modificato poiché è l'ID univoco per loro all'interno del database di Moonpig.

Questo è un ottimo esempio di come farlo male. Le chiavi di sessione dovrebbero essere imprevedibili e in grado di essere gettate via (probabilmente un utente può avere molte chiavi di sessione).

Come @Mindwin menzionato nei commenti, la chiave di sessione dovrebbe essere nel payload HTTP (cookie o dati del modulo [best practice è nei cookie]) e non nell'URL. Questo perché avere i dati di sessione nell'URL lo rende così devi metterlo nell'URL di ogni link, ti impedisce di perseguire una sessione se l'utente esce e ritorna, copiando l'URL e inviandolo a qualcuno dà loro la tua sessione dati e c'è un limite di caratteri che può essere un URL.

Dovresti inoltre utilizzare HTTPS laddove possibile, in modo che un utente malintenzionato non possa eseguire lo snoop sul payload HTTP e ottenere una copia della chiave di sessione in questo modo (questo è il modo in cui ha funzionato Firesheep).

Sì. Può.

Le informazioni sulla sessione sono memorizzate sul lato server (tranne il token di sessione) mentre i cookie nell'altra modalità sono memorizzati nel lato client (browser). Quindi l'attaccante potrebbe cambiare il token di sessione per dirottare una sessione.

L'attacco è comunemente noto come dirottamento di sessione attraverso la manipolazione di cookie. Ma l'autore dell'attacco deve utilizzare un token di sessione valido che può essere trovato facilmente se un sito è configurato male. Un sito configurato male potrebbe archiviare un token nell'url o non generarne uno casuale ecc.

Ecco quattro metodi principali usati per dirottare una sessione:

• Fissazione della sessione - Quando l'ID di sessione viene accettato dall'URL.
• Sideplay della sessione - Quando l'utente malintenzionato può rubare il cookie della sessione tramite lo sniffing dei pacchetti
• Cross-site scripting - Quando l'utente malintenzionato incide il computer degli utenti nell'esecuzione di un codice che è considerato attendibile perché appare appartenere al server, consentendo all'aggressore di ottenere una copia del cookie o eseguire altre operazioni.
• Malware - Può dirottare un browser per rubare i suoi file cookie senza che l'utente ne sia a conoscenza.

La migliore pratica da proteggere sarebbe quella di memorizzare il token di sessione all'interno di un cookie. Tuttavia, se il token di sessione non corrisponde a criteri forti come casualità, unicità, resistenza alle analisi statistiche e crittografiche, potrebbe essere possibile che un utente malintenzionato manipoli la sessione.

Sembra che ci sia un po 'di confusione tra cookeis e informazioni sulla sessione qui, quindi lascia che inizi a ordinarlo:

• I cookie sono archiviati sul client. L'utente può quindi cambiarli se lo desidera.

• Informazioni sulla sessione sono memorizzate sul server. Ciò significa che l'utente non può cambiarlo.

"Non fidarti mai del cliente" è una vecchia regola in sicurezza. Ciò significa che non puoi mai fidarti delle informazioni contenute nei cookie - solo perché il cookie username ha il valore "Alice" non significa che "Mallory" non è stato quello che ha effettuato l'accesso.

Per questo motivo, le informazioni essenziali non vengono generalmente memorizzate nei cookie sul client ma nella sessione sul server. Quindi si utilizza un cookie con un ID di sessione per connettere i due. L'ID di sessione è un numero casuale lungo. Se l'ID sessione di Alice è 20349023490324 , il server avrà tutte le sue informazioni di sessione (come il suo nome utente) archiviate con quel numero.

L'utente può cambiare l'ID di sessione, ma dal momento che ci sono tanti ID di sessione possibili è estremamente improbabile che indovini un ID effettivamente connesso a un utente.

In alcuni casi potresti voler comunque memorizzare i dati nei cookie. Per impedire all'utente di giocherellare con loro è possibile firmarli con una chiave che si ha sul server. Poiché l'utente non ha la chiave, il server sarà in grado di rilevare eventuali modifiche ai cookie poiché la firma non corrisponderà più.

Tante risposte sembrano dire che se l'ID di sessione coinvolge casualità, unicità, resistenza alle analisi statistiche e crittografiche o alcune di esse, allora è ok. Questo non è proprio vero (come nel non completo). Un cookie (che contiene quell'id) non deve essere indovinato perché può essere letteralmente intercettato e riutilizzato da un utente malintenzionato. Ci sono anche rare ma possibili istanze di un proxy o di un sistema pass-through dmz che mescola i cookie (l'ho visto). Per questo motivo, oltre a quanto detto sopra, probabilmente vuoi che la tua applicazione faccia qualcosa del tipo:

Al momento dell'accesso, il sistema memorizza l'agente utente e l'indirizzo IP della richiesta nella sessione lato server. Controllare tutte le richieste successive e verificare che i valori in entrata per ip e user-agent corrispondano a quelli memorizzati nella sessione. In caso contrario, invalidare la sessione lato server e reindirizzare alla schermata di accesso. Ciò impedirà al dirottatore di entrare. Come effetto collaterale accettabile, anche l'utente legittimo verrà espulso (solo quando si verifica un tentativo di dirottamento), ma possono semplicemente accedere nuovamente.

Sì, i siti che non utilizzano i cookie con il flag di sicurezza, possono subire il dirottamento dei cookie (sulla stessa rete) e pertanto possono essere impersonati da altri utenti. Un'altra misura di sicurezza che il sito può utilizzare è tenere traccia delle sessioni degli utenti e verificare quante sessioni è aperta allo stesso tempo. Spero che questa risposta:)