Ein WebSocket-Server spricht fast immer auch HTTP: Er liefert die Seite aus, die den Socket öffnet, beantwortet Health Checks, hostet eine API oder leitet auf Ihr Frontend um. Diese HTTP-Oberfläche hat ihre eigenen, wohlbekannten Angriffsklassen, und das aktuelle sgcWebSockets schließt die wichtigsten davon standardmäßig. Das gilt für beide HTTP-Server: den Indy-basierten TsgcWebSocketHTTPServer und den auf Windows http.sys basierenden TsgcWebSocketServer_HTTPAPI.
Path Traversal ist abgedichtet
Wenn Sie statische Dateien ausliefern, indem Sie DocumentRoot setzen, baute der Server den Dateipfad früher, indem er das Document-Root mit dem Request-Pfad verband. Eine Anfrage wie GET /../../../../windows/win.ini oder ihre URL-kodierte Form /..%2f..%2f... konnte aus dem Web-Root ausbrechen und beliebige Dateien lesen. Der Server kanonisiert nun den aufgelösten Pfad und liefert ihn nur dann aus, wenn er innerhalb von DocumentRoot bleibt; alles, was ausbricht, wird abgewiesen. Das ist immer aktiv, sowohl auf dem HTTP/1.x- als auch auf dem HTTP/2-Pfad, und erfordert keine Konfiguration.
Begrenzung des Request-Body
Ein HTTP-Request-Body hat keine eingebaute Größenbeschränkung, daher könnte ein Client eine riesige Content-Length deklarieren und Gigabytes streamen, um den Serverspeicher zu erschöpfen. Die neue Eigenschaft MaxRequestBodySize begrenzt ihn. Sie ist standardmäßig auf 64 MB eingestellt, und eine Anfrage, die mehr deklariert, wird mit 413 abgewiesen, bevor der Body gepuffert wird. Erhöhen Sie sie für große Uploads, oder setzen Sie sie auf 0, um die Begrenzung zu deaktivieren.
oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.Port := 80;
oServer.MaxRequestBodySize := 16 * 1024 * 1024; // 16 MB, reject larger with 413
oServer.Active := True;Strengeres Request-Parsing stoppt Smuggling
HTTP Request Smuggling missbraucht Server, die sich uneinig sind, wo eine Anfrage endet und die nächste beginnt, typischerweise durch das Senden sowohl eines Content-Length- als auch eines Transfer-Encoding: chunked-Headers. Die neue Eigenschaft StrictRequestParsing, standardmäßig aktiviert, weist solche mehrdeutigen Anfragen mit 400 ab und wendet eine strengere Validierung der Chunked-Kodierung an, sodass ein Front-End-Proxy und der Server nicht desynchronisiert werden können.
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-Verteidigung
Der HTTP/2-Rapid-Reset-Angriff (CVE-2023-44487) öffnet einen Stream und bricht ihn sofort mit RST_STREAM ab, in einer engen Schleife, und zwingt den Server zu unbegrenzter Anfragearbeit bei nahezu keinen Kosten für den Client. Der HTTP/2-Server begrenzt nun, wie viele Resets und Control-Frames eine einzelne Verbindung senden darf, liefert einen endlichen Standardwert von 100 gleichzeitigen Streams und schließt eine missbräuchliche Verbindung mit einem GOAWAY-Frame. HTTP/2 ist opt-in, das ist also nur relevant, wenn Sie es aktiviert haben; falls doch, ist die Verteidigung automatisch.
Saubere Response-Header
Wenn eine Anwendung einen Response-Header aus von der Anfrage beeinflussten Daten baut, etwa ein Redirect-Ziel oder ein Entity-Tag, könnte ein in diesen Wert eingeschmuggelter Carriage-Return oder Line-Feed die Antwort aufspalten und zusätzliche Header einschleusen. Der http.sys-Server entfernt nun CR und LF aus Response-Header-Werten wie Location, Server und ETag, sodass ein einzelner Wert nicht mehr zu zwei Headern werden kann.
Wo die Firewall hineinpasst
Diese Schutzmaßnahmen sitzen im eigenen HTTP-Parser und Dateiserver des Servers, also in der Schicht, die die Komponenten Firewall und RateLimiter nicht erreichen können. Nutzen Sie die Firewall weiterhin für IP-Filterung, Rate-Limits und Origin-Policy, und lassen Sie die eingebauten Abwehrmechanismen das Parsing und das Ausliefern statischer Dateien schützen. Für einen öffentlichen Server empfehlen wir außerdem, DocumentRoot nur dann zu setzen, wenn Sie tatsächlich Dateien ausliefern, MaxRequestBodySize auf Ihr reales Maximum abzustimmen und MaxConnections zu begrenzen.
Aktualisierung
Die neuen Schutzmaßnahmen sind aktiv, sobald Sie aktualisieren, mit sicheren Standardeinstellungen, sodass die meisten Server die Härtung ohne Code-Änderung erhalten. Wenn Ihre Anwendung Request-Bodys größer als 64 MB akzeptiert, erhöhen Sie MaxRequestBodySize entsprechend. Bestehende Clients sind nicht betroffen.
Aktualisieren Sie über die sgcWebSockets-Download-Seite, oder beziehen Sie es über GetIt oder Ihr registriertes Konto.
Fragen, Feedback oder Hilfe bei der Migration? Kontaktieren Sie uns, Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.