Un server WebSocket quasi sempre parla anche HTTP: serve la pagina che apre il socket, risponde agli health check, ospita un'API o reindirizza al tuo front end. Quella superficie HTTP ha le proprie ben note classi di attacco, e l'ultima versione di sgcWebSockets chiude per impostazione predefinita le più importanti. Questo vale per entrambi i server HTTP: il TsgcWebSocketHTTPServer basato su Indy e il TsgcWebSocketServer_HTTPAPI basato su http.sys di Windows.
Il path traversal è sigillato
Se servi file statici impostando DocumentRoot, il server costruiva il percorso del file unendo la document root al percorso della richiesta. Una richiesta come GET /../../../../windows/win.ini, o la sua forma URL-encoded /..%2f..%2f..., poteva uscire dalla web root e leggere file arbitrari. Il server ora canonicalizza il percorso risolto e lo serve solo se rimane all'interno di DocumentRoot; tutto ciò che esce viene rifiutato. Questo è sempre attivo, sia sul percorso HTTP/1.x che HTTP/2, e non richiede alcuna configurazione.
Limitare il body della richiesta
Il body di una richiesta HTTP non ha un limite di dimensione integrato, quindi un client potrebbe dichiarare un Content-Length enorme e trasmettere gigabyte per esaurire la memoria del server. La nuova proprietà MaxRequestBodySize lo limita. Per impostazione predefinita vale 64 MB e una richiesta che ne dichiara di più viene rifiutata con 413 prima che il body venga bufferizzato. Aumentala per upload di grandi dimensioni, oppure impostala a 0 per disabilitare il limite.
oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.Port := 80;
oServer.MaxRequestBodySize := 16 * 1024 * 1024; // 16 MB, reject larger with 413
oServer.Active := True;Un parsing delle richieste più rigoroso blocca lo smuggling
Il request smuggling HTTP sfrutta server che non concordano su dove finisce una richiesta e ne inizia la successiva, tipicamente inviando sia un header Content-Length sia un Transfer-Encoding: chunked. La nuova proprietà StrictRequestParsing, abilitata per impostazione predefinita, rifiuta tali richieste ambigue con 400 e applica una validazione più rigorosa della codifica chunked, in modo che un proxy front-end e il server non possano desincronizzarsi.
oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.StrictRequestParsing := True; // default: reject Content-Length + Transfer-Encoding
oServer.MaxRequestBodySize := 64 * 1024 * 1024;
oServer.Active := True;Difesa contro HTTP/2 Rapid Reset
L'attacco HTTP/2 Rapid Reset (CVE-2023-44487) apre uno stream e lo annulla immediatamente con RST_STREAM, in un ciclo serrato, costringendo il server a svolgere lavoro di richiesta illimitato a un costo quasi nullo per il client. Il server HTTP/2 ora limita quanti reset e frame di controllo una singola connessione può inviare, definisce un valore predefinito finito di 100 stream concorrenti e chiude una connessione abusiva con un frame GOAWAY. HTTP/2 è opt-in, quindi questo conta solo se lo hai abilitato, ma se lo hai fatto, la difesa è automatica.
Header di risposta più puliti
Quando un'applicazione costruisce un header di risposta a partire da dati influenzati dalla richiesta, ad esempio una destinazione di redirect o un entity tag, un carriage-return o un line-feed inserito di nascosto in quel valore potrebbe spezzare la risposta e iniettare header aggiuntivi. Il server http.sys ora rimuove CR e LF dai valori degli header di risposta come Location, Server ed ETag, in modo che un singolo valore non possa più diventare due header.
Dove si colloca il firewall
Queste protezioni risiedono nel parser HTTP e nel file server del server stesso, che è il livello che i componenti Firewall e RateLimiter non possono raggiungere. Continua a usare il firewall per il filtraggio degli IP, i limiti di frequenza e la policy di origine, e lascia che le difese integrate proteggano il parsing e la distribuzione statica. Per un server pubblico raccomandiamo inoltre di impostare DocumentRoot solo quando servi davvero dei file, di regolare MaxRequestBodySize sul tuo massimo reale e di limitare MaxConnections.
Aggiornamento
Le nuove protezioni sono attive non appena aggiorni, con impostazioni predefinite sicure, quindi la maggior parte dei server ottiene il rafforzamento senza alcuna modifica al codice. Se la tua applicazione accetta body di richiesta più grandi di 64 MB, aumenta MaxRequestBodySize di conseguenza. I client esistenti non sono interessati.
Aggiorna dalla pagina di download di sgcWebSockets, oppure scaricalo tramite GetIt o il tuo account registrato.
Domande, feedback o aiuto per la migrazione? Contattaci, riceverai una risposta dalle persone che hanno scritto il codice.