Prevenzione degli attacchi CSRF contro le comunicazioni WebSocket

Question

Prevenzione degli attacchi CSRF contro le comunicazioni WebSocket

#1 da (4 voti)
#2 da (2 voti)

7

Ho letto il thread sugli attacchi CSRF in websockets ( Le app Web basate su WebSocket (ad esempio le app" comet ") devono preoccuparsi di CSRF? ) e anche altro materiale riguardante la sicurezza websocket, ma nessuno di loro sembra indirizzare il seguente problema -

È possibile che un utente malintenzionato causi (attirando la vittima a premere un collegamento) un utente legittimo ad aprire un WebSocket verso il servizio legittimo e / o induca la vittima a inviare messaggi creati da un utente malintenzionato all'interno del WebSocket esistente della vittima ? (simile a un attacco CSRF standard nel contesto di HTTP).

Se possibile, cosa si può fare per impedirlo? L'invio di un token nell'URL WebSocket durante l'apertura di WebSocket è sufficiente o il token deve essere inviato all'interno di ognuna delle richieste inviate all'interno del WebSocket?

Intendiamo utilizzare WebSockets per implementare una chat nell'area non autenticata del nostro sito e vogliamo essere sicuri che stiamo facendo tutto il possibile per impedire a utenti malintenzionati di eseguire attacchi simili a quelli descritti sopra. Qualche raccomandazione speciale riguardante il modo più sicuro per implementarlo?

web-application csrf html-5 websocket

posta user3074662 25.12.2014 - 00:02

fonte

2 risposte

Leggi altre domande sui tag web-application csrf html-5 websocket

Outlook memorizza le password in testo semplice? Quale sarebbe un buon modo per inviare informazioni sensibili agli utenti che non sono molto esperti di tecnologia?

score 4 · Answer 1

È possibile un attacco CSRF su WebSocket se si fa affidamento sui cookie di autenticazione. Da RFC 6455 §1.3:

The |Origin| header field [RFC6454] is used to protect against unauthorized cross-origin use of a WebSocket server by scripts using the WebSocket API in a web browser. The server is informed of the script origin generating the WebSocket connection request. If the server does not wish to accept connections from this origin, it can choose to reject the connection by sending an appropriate HTTP error code. This header field is sent by browser clients; for non-browser clients, this header field may be sent if it makes sense in the context of those clients.

Ho evidenziato alcune parti. La prima parola magica è can e la seconda è may. I server WebSocket possono controllare l'origine, ma questo è facoltativo. I client non browser potrebbero inviare l'intestazione di origine, ma ciò non è obbligatorio.

Un attore malintenzionato potrebbe utilizzare un attacco CSRF per aprire una connessione WebSocket a un server WebSocket e i cookie verranno aggiunti dal browser alla richiesta. Se il server non controlla l'origine, o se controlla l'origine ma l'origine è contraffatta, l'attacco acquisisce un tunnel di lettura / scrittura sul server WebSocket con le autorizzazioni della vittima.

Il controllo dell'origine probabilmente copre la maggior parte degli attacchi poiché gli esseri umani utilizzano tradizionalmente i principali browser che inviano l'intestazione di origine corretta. Tuttavia, di fronte ai client non-browser, che possono " inviare falsi | Origin | campi header, fuorviando il server " [RFC 6455 §10.1], dovrebbero essere applicati altri meccanismi. Questo post del blog suggerisce sia di verificare l'origine sia di utilizzare token casuali individuali della sessione come contromisure. Suppongo che si possa anche eseguire un qualche tipo di autenticazione tramite la connessione WebSocket, dopo che è stata stabilita, anche se questo può danneggiare l'usabilità.

score 2 · Answer 2

Nota, la mia risposta di seguito presuppone che l'intestazione di origine venga controllata correttamente e risponda in modo specifico alla tua domanda.

Il socket hijacking è possibile se non ci sono controlli di origine o altri controlli di autenticazione validi fatti nel tuo codice quando si apre una nuova websocket.

La risposta originale segue ...

Is it possible for an attacker to cause (by luring the victim to press a link) a legitimate user to open a websocket towards the legitimate service and/or cause the victim to send messages crafted by an attacker within the victim's existing websocket? (similar to a standard CSRF attack in the context of HTTP).

No, un utente malintenzionato non può eseguire CSRF con websocket aprendo una nuova websocket o riutilizzando il websocket esistente della vittima.

Aprendo un nuovo websocket: un utente malintenzionato potrebbe eseguire questa operazione, ma non avrebbe alcun meccanismo per fornire le credenziali di autenticazione al listener di socket. Durante una richiesta HTTP iniziale di handshake, l'intestazione Origin può essere utilizzata sul lato server per verificare che provenga da un'origine valida. Per il socket stesso, a differenza di una normale richiesta HTTP, non ci sono intestazioni inviate dal browser per identificare o autenticare l'utente per impostazione predefinita.

Riutilizzo del websocket esistente della vittima: Supponiamo che il websocket sia dichiarato come tale nella home page di www.example.com :

var exampleSocket = new WebSocket("ws://www.example.com/socketserver", "protocolOne");

Un utente malintenzionato non sarà in grado di ottenere un riferimento a exampleSocket poiché l'accesso al dominio www.example.com è protetto da Stessa politica di origine .