T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/server.js:52
- Finding
- Unbounded Request-Body Buffering Enables Denial of Service## Vulnerability Details **File Location**: `scripts/server.js`, lines 52–55 **Vulnerability Type**: Unbounded memory allocation during HTTP request processing **Risk Level**: Medium ```javascript let body = ''; req.on('data', chunk => { body += chunk; }); req.on('end', () => { ``` ### Technical Analysis The proxy accumulates every incoming request-body chunk in the `body` string without enforcing a maximum byte count. It also does not establish a request timeout or reject oversized requests based on `Content-Length`. Consequently, a connected client can cause the Node.js process to retain an arbitrarily large body in memory before the request is forwarded to Azure. Repeated string concatenation may also increase allocation and copying overhead. Although the default listener is restricted to `127.0.0.1`, the `AZURE_PROXY_BIND` configuration allows operators to expose the service to other hosts, increasing exploitability. ### Attack Path 1. The attacker obtains network access to the configured proxy listener. This may be local access under the default configuration or remote access if `AZURE_PROXY_BIND` exposes the service. 2. The attacker opens one or more connections and sends a `POST` request whose URL contains `/chat/completions`. 3. The attacker transmits a very large body, or transmits body data slowly while keeping the connection open. 4. The `data` handler continuously appends received chunks to `body` without applying a size limit. 5. Process memory consumption and allocation overhead increase until the event loop becomes degraded or the Node.js process is terminated due to memory exhaustion. ### Impact Assessment Successful exploitation does not grant additional operating-system privileges or access to Azure credentials. Its primary effect is loss of availability within the proxy process and its service scope. Potential consequences include excessive memory and CPU consumption, delayed legitimate model re ...[truncated 105 chars]
- Remediation
- ## Remediation Suggestions - Track received bytes and enforce a conservative request-body limit appropriate for expected OpenAI requests. - Return HTTP `413 Payload Too Large` and destroy the request as soon as the limit is exceeded. - Validate `Content-Length` when present, while retaining streaming byte-count enforcement because that header may be absent or dishonest. - Configure request, header, keep-alive, and socket timeouts to reduce slow-request attacks. - Limit concurrent connections and apply rate limiting when the listener is accessible beyond a trusted local host. - Keep the default loopback binding and require an authenticated, access-controlled reverse proxy if remote exposure is necessary. - Where practical, forward requests using bounded streaming rather than retaining the entire body in memory.