T09 · Insecure Skill Coding Practices
- Location
SKILL.md:42- Finding
Bearer Token Exposure Through Complete Request Display and Plaintext HTTP Configuration
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:42-59,SKILL.md:99-105, andSKILL.md:126
Vulnerability Type: Credential exposure and insecure transport configuration
Risk Level: MediumVulnerable 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": { // 根据功能清单填入具体参数 } }
text `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（如有）
text 如果用户没有提供，主动询问这两个值，并在对话中记住它们。SKILL.md:126:text 1. **安全**：不要在对话中明文显示完整的密码或高权限 TokenTechnical Analysis
The skill constructs requests containing a bearer credential in the
Authorizationheader 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_URLalso 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
View remediation
Remediation Suggestions
- Require
https://for every non-loopback RPA endpoint and reject plaintext HTTP configuration by default. - Validate
BASE_URLagainst an administrator-controlled allowlist of approved schemes, hosts, ports, and path prefixes. - Replace the instruction to display the complete request with an explicit sanitized preview requirement. Always render the header as
Authorization: Bearer [REDACTED]. - Never place the raw API key in generated request previews, ordinary assistant messages, error messages, logs, screenshots, or task identifiers.
- 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.
- 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.
- Define a single unambiguous credential-handling policy and remove the conflict between displaying a complete request and prohibiting plaintext token disclosure.
- Apply least privilege to RPA tokens, use short expiration periods, support rotation and revocation, and separate tokens by environment and workflow.
- Do not forward authorization headers across redirects or to hosts other than the validated RPA origin.
- Add automated tests that fail if a request preview, error response, or log output contains the original bearer token.
- Require