WebSocket: differenze tra le versioni

Versione delle 13:24, 12 feb 2023

Versione delle 14:07, 26 gen 2024

Riga 117:

[[Apache HTTP Server]] supporta WebSocket da luglio 2013, implementato nella versione 2.4.5<ref>{{Cita web|url=http://httpd.apache.org/docs/trunk/new_features_2_4.html|titolo=Overview of new features in Apache HTTP Server 2.4|sito=Apache}}</ref><ref>{{Cita web|url=https://www.apachelounge.com/Changelog-2.4.html|titolo=Changelog Apache 2.4|sito=Apache Lounge}}</ref>.

[[Internet Information Services]] ha aggiunto il supporto per WebSocket nella versione 8 che è stata rilasciata con [[Windows Server]] 2012<ref>{{Cita web|url=https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support|titolo=IIS 8.0 WebSocket Protocol Support|data=28 novembre 2012|opera=Microsoft Docs|accesso=18 febbraio 2020}}</ref>.

[[Lighttpd]] supporta WebSocket dal 2017, implementato nella versione 1.4.46.<ref>[https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_46]</ref> lighttpd mod_proxy può fungere da proxy inverso e bilanciatore del carico delle applicazioni WebSocket. lighttpd mod_wstunnel può facilitare un tunnel WebSocket, consentendo a un client di utilizzare WebSocket per eseguire il tunneling di un protocollo più semplice, come [[JavaScript Object Notation|JSON,]] a un'applicazione di backend.

== Considerazioni sulla sicurezza ==

A differenza delle normali richieste HTTP tra domini, le richieste WebSocket non sono limitate dalla politica della stessa origine. Pertanto i server WebSocket devono convalidare l'intestazione "Origin" rispetto alle origini previste durante la creazione della connessione, per evitare attacchi di dirottamento WebSocket tra siti (simili alla contraffazione di richieste tra siti), che potrebbero essere possibili quando la connessione è autenticata con cookie o autenticazione [[Hypertext Transfer Protocol|HTTP]]. È preferibile utilizzare token o meccanismi di protezione simili per autenticare la connessione WebSocket quando vengono trasferiti [[dati sensibili]] (privati) su WebSocket<ref>{{Cita web|url=https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html#main|titolo=Cross-Site WebSocket Hijacking (CSWSH)|autore=Christian Schneider|opera=Web Application Security Blog|data=31 agosto 2013}}</ref>. Un esempio dal vivo di vulnerabilità è stato visto nel 2020 sotto forma di Cable Haunt.

== Attraversamento proxy ==

Riga 131:

Se il traffico WebSocket non crittografato passa attraverso un server proxy esplicito o trasparente senza il supporto di WebSocket, è probabile che la connessione non riesca<ref>{{Cita web|url=http://www.infoq.com/articles/Web-Sockets-Proxy-Servers|titolo=How HTML5 Web Sockets Interact With Proxy Servers|sito=Infoq.com|data=16 marzo 2010|editore=C4Media Inc.|autore=Peter Lubbers|accesso=10 dicembre 2011}}</ref>.

Se viene utilizzata una connessione WebSocket crittografata, l'utilizzo di [[Transport Layer Security]] (TLS) nella connessione WebSocket Secure garantisce che un comando HTTP CONNECT venga emesso quando il browser è configurato per utilizzare un server proxy esplicito. Questo imposta un tunnel, che fornisce comunicazioni TCP end-to-end di basso livello attraverso il proxy HTTP, tra il client WebSocket Secure e il server WebSocket. Nel caso di server proxy trasparenti, il browser non è a conoscenza del server proxy, quindi non viene inviato alcun CONNECT HTTP. Tuttavia, poiché il traffico cablato è crittografato, i server proxy trasparenti intermedi possono semplicemente consentire il passaggio del traffico crittografato, quindi è molto più probabile che la connessione WebSocket riesca se viene utilizzato WebSocket Secure. L'utilizzo della crittografia non è privo di costi in termini di risorse, ma spesso fornisce la più alta percentuale di successo poiché viaggerebbe attraverso un tunnel sicuro.

Una bozza di metà 2010 (versione hixie-76) ha rotto la compatibilità con proxy inversi e gateway includendo otto byte di dati chiave dopo le intestazioni, ma non pubblicizzando tali dati in un'intestazione<code>Content-Length: 8</code><ref>{{Cita web|url=https://www.ietf.org/mail-archive/web/hybi/current/msg02149.html|titolo=WebSocket -76 is incompatible with HTTP reverse proxies|sito=ietf.org|editore=Internet Engineering Task Force|data=6 luglio 2010|accesso=10 dicembre 2011|autore=Willy Tarreau|tipo=email}}</ref>. Questi dati non sono stati inoltrati da tutti gli intermedi, il che potrebbe portare al fallimento del protocollo. Le bozze più recenti (ad esempio, hybi-09<ref>{{cite IETF|url=https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.4|title=The WebSocket protocol, draft hybi-09|sectionname=Sec-WebSocket-Key|section=11.4|date=June 13, 2011|access-date=June 15, 2011|author=Ian Fette}}</ref>) inseriscono i dati chiave in <code>Sec-WebSocket-Key</code>un'intestazione, risolvendo questo problema.