Passa al contenuto principale

10. Security Considerations (Considerazioni sulla sicurezza)

Il design del protocollo WebSocket considera molteplici minacce alla sicurezza. Questo capitolo descrive le principali considerazioni sulla sicurezza e le misure di mitigazione raccomandate.

10.1 Non-Browser Clients (Client non-browser)​

Il protocollo WebSocket può essere utilizzato da qualsiasi client, non limitato ai browser web. I client non-browser non hanno la protezione della politica di stessa origine del browser.

Rischi:

  • Possono falsificare gli header Origin
  • Possono aggirare le restrizioni CORS
  • Possono avviare numerose connessioni

Mitigazione:

  • I server devono implementare autenticazione aggiuntiva
  • Utilizzare la validazione tramite token (ad es., JWT)
  • Implementare la limitazione della frequenza
  • Validare tutti i dati in ingresso

10.2 Origin Considerations (Considerazioni sull'origine)​

L'header Origin è un meccanismo di sicurezza critico.

Pratiche raccomandate:

  1. Validare Origin: I server dovrebbero validare l'header Origin
  2. Approccio whitelist: Utilizzare whitelist invece di blacklist
  3. Origini dinamiche: Utilizzare la configurazione del database se necessario

Nota: I client non-browser possono falsificare Origin, quindi non fare affidamento solo sulla validazione Origin.

10.3 Attacks On Infrastructure (Attacchi all'infrastruttura)​

Attacchi di cache poisoning​

WebSocket utilizza il meccanismo di mascheramento per prevenire il cache poisoning:

  • Tutti i frame client-server DEVONO essere mascherati
  • I frame server-client NON DEVONO essere mascherati
  • Utilizzare chiavi di mascheramento casuali

Attacchi man-in-the-middle​

Mitigazione:

  • Utilizzare wss:// (crittografia TLS)
  • Verificare i certificati del server
  • Implementare il certificate pinning

10.4 Implementation-Specific Limits (Limiti specifici dell'implementazione)​

Le implementazioni dovrebbero impostare limiti ragionevoli per prevenire attacchi di esaurimento delle risorse.

Limiti raccomandati​

1. Limite dimensione messaggio 2. Limite numero di connessioni 3. Limitazione della frequenza dei messaggi

10.5 WebSocket Client Authentication (Autenticazione client WebSocket)​

Metodi di autenticazione​

  1. Autenticazione tramite cookie durante l'handshake
  2. Token nei parametri URL
  3. Autenticazione del primo messaggio
  4. Header di handshake personalizzati

10.6 Connection Confidentiality and Integrity (Riservatezza e integrità della connessione)​

Requisiti TLS/SSL​

Gli ambienti di produzione devono utilizzare wss://:

✅ Vantaggi di TLS:

  • Crittografa tutti i dati trasmessi
  • Previene l'intercettazione
  • Previene la manomissione dei dati
  • Autenticazione del server

❌ Rischi di ws://:

  • Trasmissione in chiaro
  • Facile da intercettare
  • Non può verificare l'identità del server

10.7 Handling of Invalid Data (Gestione dei dati non validi)​

Le implementazioni devono gestire correttamente i dati non validi per prevenire vulnerabilità di sicurezza.

Testo UTF-8 non valido​

Violazioni del protocollo​

Quando vengono rilevate violazioni del protocollo, la connessione DEVE essere chiusa.

10.8 Use of SHA-1 by the WebSocket Handshake (Uso di SHA-1 nell'handshake WebSocket)​

L'handshake utilizza l'algoritmo hash SHA-1. Sebbene SHA-1 abbia attacchi di collisione noti, è sicuro nel contesto dell'handshake.

Checklist di sicurezza​

Quando si implementano servizi WebSocket, verificare:

  • Utilizzare wss:// (TLS) invece di ws://
  • Validare l'header Origin
  • Implementare autenticazione e autorizzazione
  • Impostare limiti di dimensione del messaggio
  • Impostare limiti del numero di connessioni
  • Implementare la limitazione della frequenza
  • Validare tutti i dati in ingresso
  • Gestire correttamente le violazioni del protocollo
  • Registrare eventi di sicurezza
  • Aggiornare regolarmente la configurazione TLS
  • Monitorare modelli di connessione anomali
  • Implementare meccanismi di timeout
Ultimo aggiornamento il