T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:42
- Finding
- Bearer Token Exposure Through Complete Request Display and Plaintext HTTP Configuration## Vulnerability Details **File Location**: `SKILL.md:42-59`, `SKILL.md:99-105`, and `SKILL.md:126` **Vulnerability Type**: Credential exposure and insecure transport configuration **Risk Level**: Medium ### Vulnerable Code `SKILL.md:42-54`: ```text ### Step 4：构建 HTTP 请求 ``` Method: [GET / POST / PUT / DELETE] URL: {BASE_URL}{endpoint} Headers: Content-Type: application/json Authorization: Bearer {API_KEY} ← 如功能清单中有鉴权要求 Body (JSON): { "task_id": "唯一任务ID（可用时间戳）", "params": { // 根据功能清单填入具体参数 } } ``` `SKILL.md:57-59`: ```text ### Step 5：展示请求并确认 在执行前，以结构化方式展示完整的请求内容，请用户确认后再发送。 ``` `SKILL.md:99-105`: ```text ## 全局配置（首次使用时设置） 使用本 Skill 前，需要确认以下配置信息： ``` BASE_URL: http://your-rpa-server:8088 ← RPA 服务地址 API_KEY: your-api-key-here ← 鉴权 Token（如有） ``` 如果用户没有提供，主动询问这两个值，并在对话中记住它们。 ``` `SKILL.md:126`: ```text 1. **安全**：不要在对话中明文显示完整的密码或高权限 Token ``` ### Technical Analysis The skill constructs requests containing a bearer credential in the `Authorization` header and subsequently instructs the agent to display the complete request for confirmation. A complete request display would normally include the authorization header, causing the API key to be exposed in conversation history, model context, telemetry, screenshots, or audit logs. Although line 126 advises against displaying complete passwords or high-privilege tokens, no concrete masking procedure is defined. This conflicts with the earlier instruction to display the complete request. The skill does not require replacement of the header value with a marker such as `Bearer ****`, so execution behavior may depend on how the agent resolves these inconsistent instructions. The example `BASE_URL` also uses plaintext HTTP. Bearer tokens provide no independent protection against interception: any party capable of observing plaintext network traffic can recover and replay the token. The skill addi ...[truncated 2068 chars]
- Remediation
- ## Remediation Suggestions 1. Require `https://` for every non-loopback RPA endpoint and reject plaintext HTTP configuration by default. 2. Validate `BASE_URL` against an administrator-controlled allowlist of approved schemes, hosts, ports, and path prefixes. 3. Replace the instruction to display the complete request with an explicit sanitized preview requirement. Always render the header as `Authorization: Bearer [REDACTED]`. 4. Never place the raw API key in generated request previews, ordinary assistant messages, error messages, logs, screenshots, or task identifiers. 5. Obtain credentials from a protected runtime secret store or environment-backed credential provider at execution time rather than asking the user to enter them into conversational context. 6. If interactive credential entry is unavoidable, use a dedicated secret-input mechanism and prevent the value from being retained in conversation history or long-term memory. 7. Define a single unambiguous credential-handling policy and remove the conflict between displaying a complete request and prohibiting plaintext token disclosure. 8. Apply least privilege to RPA tokens, use short expiration periods, support rotation and revocation, and separate tokens by environment and workflow. 9. Do not forward authorization headers across redirects or to hosts other than the validated RPA origin. 10. Add automated tests that fail if a request preview, error response, or log output contains the original bearer token.