T09 · Insecure Skill Coding Practices
Warning
- Location
- references/30-capability/client-ui.md:68
- Finding
- Unauthenticated Host Data Exposure Through Persistent HTTP Routes<![CDATA[ ## Vulnerability Details **File Location**: `references/30-capability/client-ui.md:68-104` **Vulnerability Type**: Unauthenticated data exposure and missing access control **Risk Level**: Medium ### Vulnerable Code ```ts // Host side const webServer = ctx.get('webServer') if (webServer) { ctx.effect(() => webServer.register({ kind: 'exact', path: '/api/my-plugin/stats', handler(_req, res) { res.writeHead(200, { 'Content-Type': 'application/json; charset=utf-8' }) res.end(JSON.stringify({ count: 42 })) }, })) } // Client side const response = await fetch('/api/my-plugin/stats') const data = await response.json() ``` The accompanying guidance states: ```md - Client uses fetch() with same-origin access - trustedHosts restrictions only apply to WebSocket upgrade paths and do not affect HTTP fetch ``` ### Technical Analysis The recommended persistent communication pattern registers an HTTP endpoint without authentication, authorization, session ownership validation, origin validation, or CSRF protection. The handler ignores the request and returns Host-side data to any caller able to reach the web server. The relative `fetch()` URL is same-origin, so this is not evidence of deliberate external exfiltration. However, same-origin routing does not establish that the requester is authorized to access the returned data. If DSH is exposed beyond loopback, reverse-proxied, or shared by multiple users or sessions, an unauthenticated caller may invoke the endpoint directly. The guidance explicitly notes that `trustedHosts` does not protect HTTP routes, but does not prescribe an equivalent HTTP access-control mechanism. ### Attack Path 1. A plugin developer follows the documented `webServer.register()` pattern for statistics, session data, topics, logs, or other Host information. 2. The developer deploys DSH on an interface reachable by another local user, LAN client, reverse-proxy user, or browser context. 3. The attacker ...[truncated 818 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require authentication for every HTTP endpoint. 2. Derive the caller identity and session authorization from trusted server-side request context; do not trust a client-supplied session ID. 3. Verify that the authenticated principal owns or is permitted to access the requested session or resource. 4. Bind the server to loopback by default unless remote access is explicitly required. 5. Apply CSRF protection to state-changing routes, including origin checks and anti-CSRF tokens. 6. Reject unsupported methods and content types, and define strict request and response schemas. 7. Return only the minimum necessary fields; never return credentials, environment variables, raw session logs, or unrestricted service objects. 8. Add rate limits, response-size limits, security logging, and tests for unauthenticated and cross-session requests. 9. Update the documentation so authentication and authorization are mandatory parts of the template rather than optional additions. ]]>