Autenticazione basata su token sotto http

Naviga le tue risposte
2

Sto facendo un'autenticazione basata su token ma ho riscontrato alcuni problemi di sicurezza. Nel sistema, un utente accederà come segue:

  1. Digitare nome utente e password per accedere in una pagina di accesso https
  2. Se l'accesso è riuscito, il server verrà impostato un "cookie di autenticazione". Altrimenti, vai di nuovo alla pagina di accesso
  3. Il "cookie di autenticazione" in ogni richiesta verrà utilizzato per identificare l'utente.

Penso che questo sia sicuro se la richiesta è sotto https perché il "cookie di autenticazione" non può essere rubato facilmente a causa della crittografia di SSL. Non voglio che tutte le pagine del mio sito Web siano accessibili solo da https. Tuttavia, se la pagina è accessibile sotto http, la connessione potrebbe essere soggetta a un attacco "man-in-the-middle". Se i dati nei cookie vengono copiati, allora è game over.

Che cosa è una buona pratica di autenticazione basata su token cookie sotto http? Potresti darmi l'implementazione dettagliata delle buone pratiche?

    
posta Timespace7 03.12.2013 - 07:34
fonte

2 risposte

1

Un principio centrale di OWASP - La sicurezza del livello di trasporto insufficiente è che l'ID di sessione non è mai trapelato su HTTP. Anche se i siti di contenuti misti sono una cattiva idea dal punto di vista della sicurezza, un modo in cui può essere fatto è utilizzare la Bandiera cookie protetta che indica al browser di non includere l'ID sessione nelle richieste non HTTPS.

Se si ospita una pagina HTTP, un utente malintenzionato potrebbe introdurre JavaScript in un MITM per compromettere una sessione autenticata. I cookie HTTPOnly impedirebbero al carico utile JavaScript malintenzionato di leggere il valore del cookie, tuttavia il payload potrebbe comunque leggere pagine autenticate utilizzando una XmlHttpRequest, ottenere token di sincronizzazione CSRF ed eseguire azioni non autorizzate. La soluzione è quella di utilizzare HTTP-Strict Transport Scrutiny , che risolve anche problem di SSLStrip .

HTTPS è estremamente leggero e vedrai circa l'1% -2% di aumento dell'utilizzo della CPU quando si utilizza HTTPS su HTTP. Non usare HTTPS a causa di alcune illusioni di efficienza è un errore. HTTP / 2.0 potrebbe essere solo HTTPS .

    
risposta data 04.12.2013 - 19:26
fonte
1

Rook fa alcuni buoni punti, solo per espandere un po '...

cannot be stolen easily due to encryption of SSL

Solo se si imposta il flag di sicurezza sul cookie - altrimenti un MITM potrebbe iniettare (ad esempio) un iframe in una pagina Web apparentemente innoccata che punta al server usando http e sniff il cookie restituito.

Un ulteriore problema è quello della fissazione della sessione - di nuovo se il tuo browser pensa che stia visitando il tuo server via HTTP e riceva qualcosa che assomiglia a un cookie di sessione, l'autenticazione con protocollo SSL può essere utilizzata per riutilizzare quel valore per il token di autenticazione ( fissazione della sessione). Devi assicurarti che il tuo codice generi un nuovo token quando l'utente prova ad autenticare.

Poi c'è la possibilità di un attacco XSS (cross-site scripting) dove un po 'di javascript può leggere il cookie e inoltrarlo altrove, ad es. tramite un tag img - l'impostazione del flag HTTPonly sul cookie lo impedisce.

    
risposta data 05.12.2013 - 00:09
fonte

Leggi altre domande sui tag

Quali dettagli rivela il mio iPhone sull'utente (se presente) quando mi collego a una rete wifi? Come bloccare l'AP wireless?