Il modo migliore per impostare in modo sicuro un cookie di sessione su un altro dominio

8

Al momento abbiamo 2 siti http://www.foo.co.uk e https://secure.foo.com .

Il sito www non ha un certificato SSL e si trova su un dominio diverso.

Abbiamo un pulsante di accesso su http://www.foo.co.uk che quando si fa clic apre un iframe di https://secure.foo.com con un modulo, quando l'utente effettua il login crea un cookie di sessione su quel dominio ( foo.com ).

Il cookie di sessione deve quindi essere copiato in foo.co.uk , quindi ciò che fa è il reindirizzamento a http://www.foo.co.uk/setcookie.php?session=abcd1234 che ci consente di impostare lo stesso cookie sul dominio di origine.

Questa non è una soluzione molto sicura, quindi ho cercato di renderlo migliore - l'idea migliore che ho trovato è di inviare un hash usando qualcosa come HMAC insieme ai parametri dello script setcookie.php e quindi verificalo sull'altra estremità prima di creare il cookie.

Mentre è meglio non previene gli attacchi dell'uomo nel mezzo. Tenendo presente che www non è protetto da SSL, non penso che sia possibile impedirlo completamente, quindi la prossima cosa migliore sarebbe includere un timestamp nell'hash per renderlo valido per 5 minuti.

Qualcuno ha qualche idea su come posso renderlo migliore, o evidenziare eventuali insidie con questo approccio? Sarei molto grato.

    
posta fire 25.10.2012 - 10:21
fonte

2 risposte

2

login button on http://www.foo.co.uk that when clicked opens up an iframe

Raccomando caldamente che questo sia modificato in modo tale che la pagina corrente reindirizzi al sito SSL o apra una nuova finestra - come utente voglio vedere "https" nella barra degli indirizzi prima di inserire qualsiasi token di autenticazione!

Sì, usare lo stesso ID di sessione su entrambi i sistemi non è sicuro e ti espone al dirottamento di sessione. Idealmente, si vorrebbe generare un valore diverso che faccia riferimento agli stessi dati di sessione. Dato che stai usando PHP, l'aggiunta del tuo gestore di sessione è banale: devi prendere delle decisioni su quale parte possa leggere / scrivere sull'altro lato. L'utilizzo di HMAC o di qualsiasi altra associazione funzionale tra i due ID di sessione non è sicuro quanto la creazione di un nuovo identificatore casuale e il collegamento delle due sessioni all'interno dei dati.

    
risposta data 25.10.2012 - 17:35
fonte
4

Come hai già notato, la creazione di questo token sul sito www non crittografato rimuoverà sostanzialmente il vantaggio dell'esecuzione su SSL per il sito sicuro in quanto un utente malintenzionato può semplicemente annusare il token quando viene trasferito al sito non crittografato e quindi utilizzarlo su il sito criptato per mascherarsi come utente.

Avendo anche un collegamento dal sito non crittografato a quello crittografato in cui si effettua il login, si apre un attacco MITM attivo in cui l'utente malintenzionato reindirizza la richiesta al proprio sito per prendere le credenziali.

Se non ci sono particolari ragioni per non farlo, potresti semplicemente mettere SSL su entrambi i siti, il che aiuterebbe a rimuovere il rischio di cui sopra. Il vecchio motivo principale per non utilizzare SSL ovunque (prestazioni) potrebbe non essere applicabile a te, a seconda di quanto sia occupato il tuo sito quanto pesantemente è.

Al di fuori di queste risposte dipenderebbe dalla tua architettura. Ad esempio, i due siti condividono un database? In tal caso, potresti avere due valori di sessione diversi per un utente (uno per www e uno per il sito sicuro) e metterli in correlazione lì?

    
risposta data 25.10.2012 - 17:18
fonte