L'esposizione di un ID di sessione crea rischi per la sicurezza?

Does exposing a session ID create a security risk?

Non necessariamente. Esponi gli ID di sessione al browser ogni volta che memorizzi un ID di sessione in un cookie. Ecco come funzionano le sessioni: il browser deve conoscere l'ID della sessione per poterlo inviare al server. La domanda è come esponi il tuo ID di sessione. Se lo mandi nei cookie, va bene - lo fanno tutti. È un rischio maggiore se invii l'ID sessione come parametro URL in una richiesta GET (come fai quando utilizzi la soluzione immagine), perché l'ID sessione può finire in varie posizioni che non ti aspetti (proxy registri, log del server, cronologia del browser, ecc.)

I'm looking to make a cross-domain + single app login, since you can't store cookies on other domains from one website, I'm using img tags with a href link to each website (eg: example.com/setsessionid?id=XXXX)

C'è un altro modo per farlo (guarda come funziona il protocollo OAuth) che comporta alcuni intelligenti reindirizzamenti HTTP e funziona fondamentalmente in questo modo:

1. Crea la tua pagina di accesso che esegue l'autenticazione. Accettano un identificatore del client e un nonce casuale sufficientemente lungo
2. Ciascuno degli altri domini reindirizza a quella pagina di accesso quando un utente vuole accedere, usando il proprio ID client e un nonce casuale, che devono memorizzare.
3. Il servizio di accesso consente all'utente di effettuare l'accesso e, quando nome utente e password sono corretti, reindirizza a "accesso eseguito con successo" -url sul dominio client. Il servizio di login sa dove reindirizzare perché il dominio client ha passato l'id del client, che è possibile utilizzare per cercare dove reindirizzare. Il servizio di login invia alcuni parametri, come l'id utente dell'utente che ha effettuato l'accesso e il nonce casuale (invariato).
4. Il "login effettuato con successo" -url sul dominio client deve accettare e controllare il nonce casuale originariamente inviato. Se i nonces non corrispondono, non deve accettare la richiesta. In caso contrario, può presupporre che il servizio di accesso abbia autenticato correttamente l'utente e possa creare un cookie di sessione autenticato per il proprio dominio.

A seconda che si desideri fornire o meno il single sign on, il servizio di login può impostare il proprio cookie di autenticazione in modo che quando il secondo dominio reindirizza alla pagina di accesso, il cookie viene inviato e il servizio di accesso può reindirizzare al URL di successo immediatamente senza richiesta di nome utente e password.

Questo è estensibile, ad es. funziona anche quando si disaccoppia il servizio di accesso dal resto del sistema e lo si sposta in un servizio cloud a Honolulu. E una volta creato, puoi utilizzarlo per consentire a qualsiasi applicazione Web di autenticarsi utilizzando il tuo database utente, indipendentemente da dove è ospitato - basta aggiungere un nuovo ID client e reindirizzare l'url al tuo servizio di accesso.

Puoi renderlo più sicuro facendo in modo che il servizio di login comunichi direttamente con il dominio del cliente, ad esempio per fare in modo che il dominio del client si autentichi al servizio di accesso (ad esempio non tramite il browser dell'utente, ma da server a server) oltre a passare il nonce casuale - nel tuo caso, questo è veramente facile poiché il servizio di login e tutti gli altri servizi sono ospitati sullo stesso computer, quindi puoi semplicemente impostare alcuni flag nel back-end del database o creare un file nel filesystem .

Si noti inoltre che il sistema che ho descritto è sicuro solo se il servizio di accesso è raggiungibile tramite https, perché altrimenti un MITM può semplicemente rubare il nonce casuale e usarlo per autenticarsi. Ma ovviamente questa è una cosa intelligente da fare comunque, perché se non si cripta la pagina di accesso, un MITM può anche solo leggere il nome utente e la password che l'utente invia in chiaro.

Sì, è un rischio per la sicurezza. in pratica stai dando all'utente una chiave di accesso temporaneo da utilizzare sull'altro dominio. Quella chiave può essere rubata e utilizzata da terzi malintenzionati.

Non ti puoi fidare di nulla che è andato al browser del cliente e viceversa. Se ti fidi dell'ID di sessione "nascosto" nell'URL dell'immagine per sapere che si tratta di Alice e non di Bob o Claire, sei condannato.

Quello che devi fare è far dialogare entrambi i server dietro le quinte. Dal momento che entrambe le macchine sono sotto il tuo controllo, puoi dire loro di fidarsi l'un l'altra.

Quindi, quando Alice accede al server Omicron, Omicron visualizza me stesso che Alice ha effettuato l'accesso da IP 0.0.0.0 e il suo ID di sessione è xx: xx: xx: xx: xx

Puoi anche utilizzare un dominio di aggregazione per emulare un cookie cross domain .

Dato che hai menzionato che entrambi i domini si trovano nello stesso computer, hai molte opzioni per condividere le informazioni di accesso:

• Un file con l'ID della sessione utente
• Una voce del database.