T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:13
- Finding
- Unrestricted ESP32 Endpoint Configuration Enables Server-Side Request Forgery<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 13-55 **Vulnerability Type**: Server-Side Request Forgery through an unrestricted user-configurable endpoint **Risk Level**: High ### Vulnerable Code ```markdown The ESP32 sensor is available at: `https://calculated-inquiry-graduates-wool.trycloudflare.com` (user should update this IP) If the user hasn't told you the IP yet, ask them: "What's your ESP32's IP address? Check Arduino Serial Monitor." ``` ```markdown ### "What's the weather?" / "Get sensor data" / "Current temperature" 1. Make HTTP request to ESP32: ``` GET http://{ESP32_IP}/reading ``` ``` ```markdown ### "Test ESP32" / "Check sensor" 1. Call the health endpoint: ``` GET http://{ESP32_IP}/health ``` ``` ```markdown ### "Set ESP32 IP to X.X.X.X" Save the IP for future requests. Confirm: "Got it! I'll use {IP} for sensor readings." ``` ### Technical Analysis The Skill permits a user to set the destination used for subsequent HTTP requests and does not specify any validation of the supplied address, resolved IP address, scheme, port, or redirects. Although the setting is described as an IP address, the default configuration is a hostname, indicating that hostnames may also be accepted. The configured value is interpolated directly into requests to `/reading` and `/health`. Consequently, a user can potentially direct an Agent with network access toward arbitrary destinations, including: - Loopback services such as `127.0.0.1` - Link-local services and cloud metadata endpoints such as `169.254.169.254` - Private network systems reachable from the Agent - Attacker-controlled hosts - Hostnames that resolve or rebind to restricted addresses Appending fixed paths does not prevent exploitation because an internal or attacker-controlled service can expose matching `/reading` or `/health` routes. Redirects could also move the request to another destination unless explicitly disabled or revalidated. The ins ...[truncated 2210 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Parse endpoint input with a strict URL or IP-address parser rather than interpolating raw user input. 2. Require explicit user confirmation before saving or contacting a new device address. 3. Prefer an allowlist of known ESP32 device addresses or user-approved local subnets. 4. Reject loopback, unspecified, link-local, multicast, reserved, and cloud-metadata addresses, including their IPv4 and IPv6 forms. 5. Resolve hostnames before connecting and validate every resolved address. Repeat validation immediately before each request to mitigate DNS rebinding. 6. Restrict connections to an explicit scheme and approved ports. Prefer authenticated HTTPS rather than plaintext HTTP. 7. Disable HTTP redirects, or validate the scheme, host, port, and resolved destination again at every redirect. 8. Keep the allowed routes fixed to `/reading` and `/health`, and prevent user input from affecting paths, query strings, headers, or credentials. 9. Apply short timeouts, response-size limits, JSON content-type checks, and a strict response schema for temperature, pressure, altitude, uptime, and reading counts. 10. Remove the bundled public Cloudflare Tunnel endpoint. Require the user to configure and verify an endpoint belonging to their own device. 11. Avoid persisting endpoint configuration beyond the required scope unless the user explicitly opts in, and provide a way to inspect and clear the saved setting. 12. Where possible, enforce outbound network restrictions at the HTTP-tool or sandbox layer so the Skill cannot access sensitive internal or metadata networks. ]]>