Le app Web basate su WebSocket (ad esempio le app "comet") devono preoccuparsi di CSRF?

Should web applications using websockets (...) include nonces verified by the server on each transmission to prevent CSRF?

TL; DR: Questo è auspicabile, sebbene non necessariamente su ciascuna trasnissione (una volta per connessione dovrebbe essere sufficiente) e non per prevenire CSRF, ma XSS. Questa è più una salvaguardia che una stretta necessità. Dettagli sotto.

Per sapere se i WebSockets sono vulnerabili a CSRF dobbiamo prima capire le condizioni che consentono tali attacchi avere luogo:

1. L'utente è autenticato su un dominio, solitamente tramite un cookie di sessione;
2. Esistono uno o più tipi di richieste HTTP che, se eseguite da un utente autenticato, avranno una sorta di effetto collaterale;
3. A causa di eccezioni alla stessa politica di origine , un sito che in genere non dovrebbe essere permesso di fare una determinata richiesta è in grado di farlo, e l'agente utente include i cookie di autenticazione / autenticazione in quella richiesta.

Ad esempio, quando il sito A include un tag img con src che punta al dominio B, l'agente utente onora la richiesta, passando lungo qualsiasi cookie impostato per il dominio B. Che uso di un token CSRF segreto realizza che parte dei dati di autenticazione è inclusa nell'URL stesso , quindi un utente malintenzionato che non conosce il token non può falsificare un URL che verrà accettato dal server (poiché questa parte dell'autenticazione fallirà).

AFAIK WebSockets può aprire connessioni a qualsiasi server e port (disclaimer: il riferimento utilizzato nel post collegato potrebbe essere obsoleto ). Possono avere i loro cookie (anche se non sono gli stessi usati dalle pagine HTTP - poiché lo schema è diverso) e - se la mia interpretazione di RFC6455 è corretto - questi cookie saranno inviati insieme alla richiesta di connessione indipendentemente da quale sito ha avviato la richiesta (sebbene il server possa rifiutare richieste provenienti da un'origine diversa ). Se questi cookie forniscono tutti l'autenticazione richiesta per onorare la richiesta, il server rispetterà la richiesta.

Quindi, per determinare se un attacco CSRF basato su WebSocket può essere fatto o meno, queste domande devono essere considerate (anche se temo di non poter fornire una risposta definitiva su di esse):

• Il tuo server è configurato correttamente per accettare solo richieste provenienti da origini fidate? L'origine può essere falsificata (in questo contesto)?
• Una connessione WebSocket può avvenire al di fuori del contesto di una chiamata JavaScript, ad esempio creando un URL con ws o wss come schema e utilizzandolo come src o href di un elemento di markup? Avrebbe qualche effetto collaterale indesiderabile? So che è sciocco, ma dal momento che non ho una risposta a questa domanda, devo comunque sollevare la possibilità ...
• Come vengono eseguiti l'autenticazione e l'autorizzazione? Secondo questo post (che evidenzia anche altri potenziali problemi, non direttamente correlato a CSRF) non c'è nulla di built-in, quindi è necessario implementarlo da soli. A seconda di come lo si fa e di quali presupposti si fanno sul comportamento dell'utente, questo potrebbe aprirti agli attacchi XSS (che, pur essendo diversi da CSRF in senso stretto, sono correlati nel senso che il browser disattivate la sua autorizzazione per impostare i cookie di autenticazione in contesti diversi da quelli che vi aspettavate - in modo giusto o sbagliato)

Do the same considerations apply for websocket connections?

No, i websocket non hanno cookie in quanto tali, hanno solo i dati che sono esplicitamente inviati attraverso la connessione websocket.

Should web applications using websockets (or fallback transports like JSON polling, as employed by Socket.IO or SockJS) include nonces verified by the server on each transmission to prevent CSRF?

Sì, questo è specifico per l'implementazione. Ad esempio, la Socket.IO documentazione sull'autorizzazione afferma:

When the server receives a connection it will start gathering data from the request that might be needed later. This is done for two reasons:

1. Users might want to authorize the clients based on information from the headers or IP address.
2. Not all transports sends headers when they attempt to establish a real time connection with the server, so we store the handshake data internally so we are sure users can re-use this data again for when the client is connected. For example you might want to read out the session id from the cookie headers and initialize the Express session for the connected socket.

Pertanto, a meno che non si utilizzi una sessione nonce per utente, è possibile che i trasporti di fallback siano vulnerabili a CSRF se si accettano automaticamente i valori dei cookie sul lato server del meccanismo fallback.

Or is there a preferred mitigation strategy for websockets?

Websockets non sono vulnerabili a CSRF , a condizione che l'intestazione Origin sia convalidata durante l'handshake HTTP iniziale. Pertanto, la strategia di mitigazione consiste nel convalidare l'intestazione Origin inviata dal client.