Un servidor WebSocket casi siempre habla también HTTP: sirve la página que abre el socket, responde a las comprobaciones de estado, aloja una API o redirige a tu front end. Esa superficie HTTP tiene sus propias clases de ataque bien conocidas, y la última versión de sgcWebSockets cierra las más importantes por defecto. Esto se aplica a ambos servidores HTTP: el TsgcWebSocketHTTPServer basado en Indy y el TsgcWebSocketServer_HTTPAPI basado en http.sys de Windows.
El path traversal queda sellado
Si sirves archivos estáticos configurando DocumentRoot, el servidor solía construir la ruta del archivo uniendo la raíz de documentos a la ruta de la petición. Una petición como GET /../../../../windows/win.ini, o su forma codificada en URL /..%2f..%2f..., podía salir de la raíz web y leer archivos arbitrarios. El servidor ahora canonicaliza la ruta resuelta y solo la sirve cuando permanece dentro de DocumentRoot; cualquier cosa que se escape se rechaza. Esto está siempre activado, tanto en las rutas HTTP/1.x como HTTP/2, y no necesita configuración.
Limitando el cuerpo de la petición
El cuerpo de una petición HTTP no tiene un límite de tamaño integrado, así que un cliente podía declarar un Content-Length enorme y transmitir gigabytes para agotar la memoria del servidor. La nueva propiedad MaxRequestBodySize lo limita. Su valor por defecto es 64 MB y una petición que declare más se rechaza con 413 antes de almacenar el cuerpo en búfer. Súbelo para subidas grandes, o ponlo a 0 para desactivar el límite.
oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.Port := 80;
oServer.MaxRequestBodySize := 16 * 1024 * 1024; // 16 MB, reject larger with 413
oServer.Active := True;Un análisis de peticiones más estricto detiene el smuggling
El request smuggling de HTTP abusa de servidores que no se ponen de acuerdo sobre dónde termina una petición y empieza la siguiente, normalmente enviando a la vez una cabecera Content-Length y una Transfer-Encoding: chunked. La nueva propiedad StrictRequestParsing, activada por defecto, rechaza esas peticiones ambiguas con 400 y aplica una validación más estricta de la codificación chunked, de modo que un proxy front-end y el servidor no puedan desincronizarse.
oServer := TsgcWebSocketHTTPServer.Create(nil);
oServer.StrictRequestParsing := True; // default: reject Content-Length + Transfer-Encoding
oServer.MaxRequestBodySize := 64 * 1024 * 1024;
oServer.Active := True;Defensa frente a HTTP/2 Rapid Reset
El ataque HTTP/2 Rapid Reset (CVE-2023-44487) abre un stream y lo cancela inmediatamente con RST_STREAM, en un bucle cerrado, forzando al servidor a realizar trabajo de peticiones ilimitado a un coste casi nulo para el cliente. El servidor HTTP/2 ahora limita cuántos resets y tramas de control puede enviar una única conexión, incluye un valor por defecto finito de 100 streams concurrentes y cierra una conexión abusiva con una trama GOAWAY. HTTP/2 es opcional, así que esto solo importa si lo habilitaste, pero si lo hiciste, la defensa es automática.
Cabeceras de respuesta más limpias
Cuando una aplicación construye una cabecera de respuesta a partir de datos influidos por la petición, por ejemplo un destino de redirección o una etiqueta de entidad, un retorno de carro o un salto de línea introducido en ese valor podía dividir la respuesta e inyectar cabeceras adicionales. El servidor http.sys ahora elimina los CR y LF de los valores de las cabeceras de respuesta como Location, Server y ETag, de modo que un único valor ya no puede convertirse en dos cabeceras.
Dónde encaja el firewall
Estas protecciones residen en el propio analizador HTTP del servidor y en el servidor de archivos, que es la capa que los componentes Firewall y RateLimiter no pueden alcanzar. Sigue usando el firewall para el filtrado de IP, los límites de tasa y la política de origen, y deja que las defensas integradas protejan el análisis y el servido de archivos estáticos. Para un servidor público también recomendamos configurar DocumentRoot solo cuando realmente sirvas archivos, ajustar MaxRequestBodySize a tu máximo real y limitar MaxConnections.
Actualización
Las nuevas protecciones están activas en cuanto actualizas, con valores por defecto seguros, así que la mayoría de los servidores obtienen el refuerzo sin cambios de código. Si tu aplicación acepta cuerpos de petición mayores de 64 MB, sube MaxRequestBodySize en consecuencia. Los clientes existentes no se ven afectados.
Actualiza desde la página de descarga de sgcWebSockets, u obtenlo a través de GetIt o de tu cuenta registrada.
¿Preguntas, comentarios o ayuda con la migración? Ponte en contacto, recibirás una respuesta de las personas que escribieron el código.