T09 · Insecure Skill Coding Practices
Error
- Location
SKILL.md:180- Finding
Bearer Token Disclosure Through Chat and Plaintext Configuration
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 180–203
Vulnerability Type: Credential exposure through insecure secret collection and storage
Risk Level: HighThe mandatory setup workflow instructs the user to paste an AnyShare MCP access token directly into the conversation. It then directs the agent to place that token in
~/.mcporter/mcporter.jsonas a plaintext bearer credential.Vulnerable code segment:
markdown ### Step 4: 获取 Token 并写入配置 **4.1 向用户获取 Token（固定话术）** > 请在 AnyShare Web端 **登录后**，点击右上角头像进入 **「MCP授权凭证」**；在此可**管理、赋值**凭证。复制令牌后，**在本对话中粘贴**。 **4.2 写入 headers.Authorization** 用户粘贴 token 后，Agent 将 `~/.mcporter/mcporter.json` 中 `asmcp.headers.Authorization` 更新为： ```json "Authorization": "Bearer <用户粘贴的token>"4.3 重启 daemon 并验证
bash mcporter daemon restart mcporter call asmcp.doc_lib_owned返回文档库列表即表示认证成功。若返回 401 / 未授权，提示用户重新获取 token 并重复 4.1 → 4.2 → 4.3。
Token 过期时：重复 4.1 → 4.2 → 4.3（更新配置文件中的 token 值后重启 daemon）。
text ### Technical Analysis Bearer tokens are possession-based credentials: any party that obtains the token can generally exercise its granted permissions without additional proof of identity. Requesting the token in a conversation exposes it to chat retention, telemetry, transcripts, administrative review, backups, and any integrations that process conversation content. The workflow then persists the token in a regular JSON file. Although storing authentication headers in an MCP client configuration may be operationally necessary, the instructions do not require restrictive permissions such as mode `0600`, a credential manager, or a secret reference. Consequently, the token may also be exposed to other local users, backup systems, diagnostics, or processes capable of reading the configuration. This behavior directly contradicts `SECURITY.md`, lines 7 and 14–16, which state that real bearer tokens must not be pasted into chat logs ...[truncated 2176 chars]- Remediation
View remediation
Remediation Suggestions
- Remove the instruction to paste tokens into the conversation. The agent must never request, repeat, quote, or process the raw credential through chat.
- Require users to enter the token directly on the machine running
mcporter, using a local interactive prompt that suppresses terminal echo. - Prefer an operating-system credential manager, managed secret store, or supported environment/credential reference instead of embedding the token directly in JSON.
- If plaintext configuration is unavoidable, create
~/.mcporterwith mode0700and~/.mcporter/mcporter.jsonwith mode0600. Verify ownership before reading or modifying the file. - Update configuration atomically using a temporary file with equally restrictive permissions, then replace the destination. Never print the resulting authorization header.
- Prevent the token from appearing in shell arguments, shell history, command output, debug logs, exception messages, or daemon diagnostics.
- Validate the MCP endpoint before credential use. Require HTTPS and explicit user confirmation for private deployment URLs.
- Revise
SKILL.md,SECURITY.md, and troubleshooting guidance so they consistently prescribe the same non-chat secret-entry workflow. - Advise users who followed the current workflow to revoke or rotate exposed tokens and delete affected conversation histories where supported.
- Use narrowly scoped, short-lived tokens when the AnyShare platform supports them, and document immediate revocation procedures.