T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:31
- Finding
- Bearer Token Exposure Through Process Arguments and Plaintext HTTP## Vulnerability Details **File Location**: `SKILL.md:31-35`; duplicated in `README.md:27-30` **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: Medium ### Vulnerable Code `SKILL.md:31-35`: ```markdown **Request format**: ```bash curl -H "Authorization: Bearer ${API_TEST_KEY}" http://localhost:8080/gettool ``` ``` `README.md:27-30`: ```markdown ```bash curl -H "Authorization: Bearer ${API_TEST_KEY}" http://localhost:8080/gettool ``` ``` ### Technical Analysis The documented command expands `API_TEST_KEY` directly into the `curl` command-line arguments. Depending on the operating system, process-monitoring permissions, execution wrapper, shell tracing, and audit configuration, the expanded Authorization header may become visible through process inspection, diagnostic output, execution logs, or command auditing. The token is also transmitted over unencrypted HTTP. Although the destination is the loopback interface, HTTP provides no server authentication or transport confidentiality. A malicious or compromised local process that binds to port `8080`, intercepts local traffic, or impersonates the expected service could receive the Bearer token. The associated credential configuration at `SKILL.md:14-17` declares the credential as read-write even though the documented operation is a read-only GET request: ```yaml credentials: primary: API_TEST_KEY scope: read-write description: "用于访问 localhost:8080/gettool 接口的认证密钥" ``` This unnecessarily increases the potential consequences of credential disclosure. ### Attack Path 1. A user request triggers the skill's automatic authenticated request. 2. The shell expands `${API_TEST_KEY}` and places the resulting secret in the `curl` argument containing the Authorization header. 3. A local process with suitable process-inspection, tracing, logging, or audit access observes the expanded argument. Alternatively, an attacker-controlled service listening on `localhost:8080` receives the tok ...[truncated 989 chars]
- Remediation
- ## Remediation Suggestions 1. Avoid placing secrets in process arguments. Use an HTTP client integration that accepts sensitive headers through an in-memory API rather than a shell command. 2. If `curl` must be used, provide sensitive configuration through a protected file descriptor or a temporary configuration file with owner-only permissions, and securely delete the file immediately afterward. Verify that the chosen approach does not expose the token in process listings. 3. Disable shell tracing and ensure execution frameworks, diagnostics, and audit logs redact the `Authorization` header and `API_TEST_KEY`. 4. Use HTTPS with certificate validation for the local API where operationally possible. If HTTP loopback communication is unavoidable, authenticate the local server through a protected IPC mechanism such as a Unix-domain socket with restrictive filesystem permissions. 5. Change the credential from read-write to read-only scope because the documented operation only performs `GET /gettool`. 6. Use a dedicated, short-lived token restricted to the specific endpoint and operation. Rotate the existing token if it may already have appeared in logs or process-monitoring records. 7. Validate that the expected service owns the local endpoint before transmitting credentials, and fail safely if the destination cannot be authenticated. 8. Consider requiring user confirmation before automatically sending an authenticated request, particularly when broad trigger patterns are matched.