Een WebSocket-server spreekt bijna altijd ook HTTP: hij serveert de pagina die de socket opent, beantwoordt health checks, host een API of stuurt door naar je front-end. Dat HTTP-oppervlak heeft zijn eigen bekende aanvalsklassen, en de nieuwste sgcWebSockets sluit de belangrijkste daarvan standaard af. Dit geldt voor beide HTTP-servers: de op Indy gebaseerde TsgcWebSocketHTTPServer en de op Windows http.sys gebaseerde TsgcWebSocketServer_HTTPAPI.
Path traversal is dichtgetimmerd
Als je statische bestanden serveert door DocumentRoot in te stellen, bouwde de server vroeger het bestandspad door de document root samen te voegen met het requestpad. Een request als GET /../../../../windows/win.ini, of de URL-gecodeerde vorm /..%2f..%2f..., kon buiten de web root treden en willekeurige bestanden lezen. De server canonicaliseert nu het opgeloste pad en serveert het alleen wanneer het binnen DocumentRoot blijft; alles wat ontsnapt wordt geweigerd. Dit staat altijd aan, op zowel het HTTP/1.x- als het HTTP/2-pad, en vereist geen configuratie.
De request-body begrenzen
Een HTTP-request-body heeft geen ingebouwde groottelimiet, dus een client zou een enorme Content-Length kunnen opgeven en gigabytes kunnen streamen om het servergeheugen uit te putten. De nieuwe eigenschap MaxRequestBodySize begrenst dit. De standaardwaarde is 64 MB en een request dat meer opgeeft wordt geweigerd met 413 voordat de body wordt gebufferd. Verhoog de waarde voor grote uploads, of zet hem op 0 om de limiet uit te schakelen.
oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.Port := 80;
oServer.MaxRequestBodySize := 16 * 1024 * 1024; // 16 MB, reject larger with 413
oServer.Active := True;Striktere request-parsing stopt smuggling
HTTP request smuggling misbruikt servers die het oneens zijn over waar het ene request eindigt en het volgende begint, doorgaans door zowel een Content-Length als een Transfer-Encoding: chunked header te sturen. De nieuwe eigenschap StrictRequestParsing, standaard ingeschakeld, weigert zulke dubbelzinnige requests met 400 en past striktere validatie van chunked-encoding toe, zodat een front-end proxy en de server niet kunnen desynchroniseren.
oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.StrictRequestParsing := True; // default: reject Content-Length + Transfer-Encoding
oServer.MaxRequestBodySize := 64 * 1024 * 1024;
oServer.Active := True;HTTP/2 Rapid Reset-verdediging
De HTTP/2 Rapid Reset-aanval (CVE-2023-44487) opent een stream en annuleert deze direct met RST_STREAM, in een strakke lus, waardoor de server onbegrensd requestwerk moet doen tegen vrijwel geen kosten voor de client. De HTTP/2-server begrenst nu hoeveel resets en controleframes een enkele verbinding mag versturen, levert een eindige standaard van 100 gelijktijdige streams, en sluit een misbruikende verbinding met een GOAWAY-frame. HTTP/2 is opt-in, dus dit speelt alleen als je het hebt ingeschakeld, maar als je dat deed, is de verdediging automatisch.
Schonere responseheaders
Wanneer een applicatie een responseheader bouwt uit door het request beïnvloede data, bijvoorbeeld een redirect-doel of een entity tag, kan een carriage-return of line-feed die in die waarde wordt gesmokkeld de response splitsen en extra headers injecteren. De http.sys-server verwijdert nu CR en LF uit responseheaderwaarden zoals Location, Server en ETag, zodat één waarde niet langer twee headers kan worden.
Waar de firewall past
Deze bescherming zit in de eigen HTTP-parser en bestandsserver van de server, de laag die de Firewall- en RateLimiter-componenten niet kunnen bereiken. Blijf de firewall gebruiken voor IP-filtering, rate limits en origin-beleid, en laat de ingebouwde verdedigingen de parsing en het serveren van statische bestanden bewaken. Voor een publieke server raden we ook aan om DocumentRoot alleen in te stellen wanneer je daadwerkelijk bestanden serveert, MaxRequestBodySize af te stemmen op je werkelijke maximum, en MaxConnections te begrenzen.
Upgraden
De nieuwe bescherming is actief zodra je bijwerkt, met veilige standaardinstellingen, zodat de meeste servers de versterking krijgen zonder codewijziging. Als je applicatie request-bodies groter dan 64 MB accepteert, verhoog dan MaxRequestBodySize overeenkomstig. Bestaande clients worden niet beïnvloed.
Werk bij via de sgcWebSockets-downloadpagina, of haal het op via GetIt of je geregistreerde account.
Vragen, feedback of hulp bij migratie? Neem contact op, je krijgt antwoord van de mensen die de code hebben geschreven.