Problemi di autenticazione e archiviazione / websocket con token

Question

Problemi di autenticazione e archiviazione / websocket con token

#1 da (1 voti)

2

La mia applicazione sta eseguendo un'autenticazione API che utilizza token anziché cookie.

Questo mi porta a porre alcune domande:

Qual è il modo più sicuro per archiviare il token?

Usando token casuali si elimina il problema degli attacchi CSRF ma dall'altra parte non ci sono Secure e HTTPOnly flags.

Ho pensato di usare un qualche tipo di trucco usando le nuove funzioni ECMAScript Harmony Object.freeze() e Object.seal() , ma questo sembra essere più un trucco che qualcosa che sarebbe sicuro.

Come devo autenticare WebSocket client come Socket.io su HTTPS?

La maggior parte delle librerie come Socket.io , ws , Sockjs e Faye non consentono di impostare intestazioni HTTP personalizzate o non è compatibile con i vari protocolli di fallback come i socket Flash.

Una possibilità sarebbe quella di inviare il token come parte dell'handshake negli argomenti della query dell'URL ma non mi piace molto perché significa che:

1) - I token verranno mostrati nei file di log che registrano solo l'URL

2) - Dovrei autenticarmi prima durante l'handshake e poi ogni volta che invio dati che significhino due sistemi separati.

Questo mi viene in mente pensando un po 'a questo. Potrebbero esserci altri problemi di fondo.

Sono solo troppo paranoico e questa opzione è effettivamente sicura?

Potrei anche implementare un qualche tipo di schema asimmetrico usando un sistema di chiavi pubblico / privato, ma questo sembra solo un errore / complicato per essere una soluzione affidabile.

La mia ultima domanda è più una conseguenza delle domande precedenti:

Il valore di avere gettoni casuali piuttosto che i cookie vale la pena?

Da un lato non hai vulnerabilità di attacco CSRF, ma dall'altra parte ci sono molti altri casi in cui le risposte (almeno per me) non sembrano così chiare.

Grazie in anticipo!

authentication encryption web-application appsec websocket

posta Awake Zoldiek 18.12.2013 - 00:10

fonte

1 risposta

Leggi altre domande sui tag authentication encryption web-application appsec websocket

Script cross-site nel metodo HTTP? La crittografia degli array RAID6 di SSD sarebbe sicura?

score 1 · Answer 1

Per memorizzare il token:

Per un'app web tradizionale (non Ajax) di solito si archivia il token in un campo modulo nascosto.
Per un'app a una sola pagina di solito il token viene archiviato in una variabile JavaScript e lo si include nei dati JSON a ogni richiesta.

Questo approccio evita che il token sia nell'URL e funziona con WebSockets.

La maggior parte delle applicazioni usa un cookie come ID di sessione principale e ha un secondo token che serve esclusivamente a prevenire CSRF. Puoi abbandonare il cookie e utilizzare il token, come suggerisci, ma farlo non è una pratica standard, quindi dovresti farlo solo se sei sicuro di sapere cosa stai facendo.

Come accennato, i cookie hanno un'opzione HttpOnly che non è possibile con i token. Sebbene i token non abbiano un contrassegno sicuro in quanto tale, ciò è meno importante in quanto è possibile modificare il codice in modo che il token venga inviato sempre su SSL.

Un'altra cosa a cui prestare attenzione è che ora puoi prevenire CSRF senza usare token, principalmente usando intestazione di origine . Tuttavia, la maggior parte dei siti utilizza ancora token.

È possibile eseguire l'autenticazione cookie normale con WebSockets. Questa domanda contiene alcune informazioni. Non so quali siano le implicazioni CSRF di questo.