Un cookie di sessione "avviato dal client" può offrire maggiore privacy e sicurezza rispetto alle alternative di sessione esistenti?

1

Ci sono diversi usi per un cookie , e vorrei offrire qualche tipo di garanzia che un cookie viene utilizzato per uno scopo e uno scopo specifici, limitati. Nel mio caso, voglio dimostrare che un cookie è utilizzato solo per l'autenticazione.

Domanda

Esiste una ricerca precedente che descrive come un cookie o alternativa al cookie sarebbe utilizzata per fornire tale garanzia?

Esempio

Nell'esempio di un cookie di sessione, immagino che i normali parametri di sessione si applichino

  • L'ambito sarebbe limitato a uno o a un insieme molto limitato di URL
  • Imposta solo su HTTP

Alcuni requisiti di sicurezza aggiunti assomiglieranno a questo:

  • Il client genera il nome e il contenuto del cookie da una fonte crittograficamente casuale
  • Il client invia questo cookie preferito al server nello stesso momento in cui vengono inviate le credenziali
  • Se il cookie non è in conflitto con una sessione esistente, il server lo accetta e lo utilizza come token al portatore per il resto della sessione

Esiste una soluzione simile o migliore per le persone che sono preoccupate per i cookie, il monitoraggio e altri aspetti della privacy?

    
posta random65537 07.08.2015 - 17:39
fonte

2 risposte

1

Non penso che ciò fornirà alcun beneficio. Su un'applicazione web sicura, meno dipende dai dati del cliente, meglio è.

Riesco a vedere alcuni problemi:

  • Questo creerà sicuramente una vulnerabilità chiamata Session Fixation : un utente malintenzionato può creare una sessione, attirare il tuo cliente su una pagina speciale e avere i dati della sessione nelle sue mani.

  • Il server non ha modo di sapere se una sessione sess12345678 viene clonata o se il client ha cambiato indirizzo IP o se il client utilizza un proxy di bilanciamento del carico. Se si blocca la sessione su un IP, i client mobili possono avere problemi.

  • Se il tuo token dell'applicazione client non ha entropia sufficiente, è banale per un utente malintenzionato bruteforce molti possibili valori.

  • Tutti i cookie creati dalla tua applicazione possono essere letti da Javascript, quindi un XSS può inviarli tutti a un utente malintenzionato.

  • Stai aumentando notevolmente la complessità sul lato server, perché dovrai convalidare sia il nome e il valore del cookie.

  • La creazione di un cookie sicuro crittografico e il valore sul client possono essere difficili e la generazione può essere facilmente falsificata o ignorata da un utente malintenzionato.

Vorrei attenermi ai cookie di sicurezza per autenticare gli utenti.

    
risposta data 07.08.2015 - 20:26
fonte
1

Is there any prior research that describes how a cookie, or cookie alternative would be used to provide such a guarantee?

Non penso che tu possa fornire tale garanzia, tranne forse nel dirlo nella tua politica sulla privacy e poi seguire quella politica.

The scope would be restricted to a one, or a very limited set of URLs,

L'impostazione dell'ambito può essere effettuata dal flag di sicurezza e dagli attributi del dominio e del percorso quando viene impostato il cookie. Tuttavia, è molto difficile per l'utente finale tracciare questo usando un normale browser; Supponi di limitare il cookie al percorso /loggedIn . Se l'utente visita il tuo URL /information , a prima vista sembra che il tuo sito non riceverà il cookie per le richieste a questo URL. Tuttavia, la pagina potrebbe presentare richieste a /loggedIn utilizzando JavaScript o richieste di risorse, consentendo all'utente di essere rintracciato di nascosto.

Sì, un utente interessato alla privacy potrebbe verificarlo. Tuttavia, se fossero così preoccupati per la privacy, eliminerebbero comunque i loro cookie, rendendo inutile la complessa politica sui cookie e l'implementazione.

Il client che imposta il nome e il valore del cookie non risolve questo problema. Si potrebbe continuare a tracciare il lato utente del server utilizzando il nome del cookie e le informazioni sul valore. Non sono d'accordo con ThoriumBR su Session Fixation perché non penso che ciò accresca il rischio di un simile attacco. Se l'utente malintenzionato può impostare il cookie sul browser della vittima, è irrilevante che questo cookie sia un nome e un valore scelto dall'utente o un nome o valore scelto da sever. Inoltre, non modifica il livello di rischio di un'altra vulnerabilità simile: Login CSRF . Sì se la vulnerabilità esiste, l'utente malintenzionato può accedere all'utente nell'account dell'utente malintenzionato e impostare il nome e il valore del cookie, tuttavia l'impostazione del nome e del valore del cookie non aggiunge alcun valore in sé.

Se sei preoccupato che l'uso dei cookie dissuada gli utenti attenti alla privacy dall'utilizzo del sito, non è necessario utilizzarli affatto per mantenere lo stato lato client. Un modo è far funzionare il tuo sito solo tramite i postback. Cioè, ogni azione e navigazione del sito causa la creazione di una richiesta POST e i dati POST contengono token allo stato lato server.

per es.

<form method="post" action="/siteAction">

  <input type="hidden" name="token" value="aaaaaaaaaaaaaaaaaaaaaa" />
  <input type="hidden" name="action" value="navigateAccountPage" />
  <input type="hidden" name="params" value="{foo: 'bar'}" />

</form>

* params dovrebbe essere codificato in html, tuttavia escluso per semplicità

Ciò consentirà di memorizzare lo stato lato client senza la necessità di alcun cookie. L'utente sa di non essere monitorato in quanto può semplicemente controllare i cookie e lo spazio di archiviazione del browser (tecnicamente archiviazione HTML5, Flash e Silverlight per essere completi).

    
risposta data 10.08.2015 - 11:33
fonte