T09 · Insecure Skill Coding Practices
Warning
- Location
- references/claude-mcp-config.md:12
- Finding
- Plaintext DDF Credentials in MCP Configuration<![CDATA[ ## Vulnerability Details **File Location**: `references/claude-mcp-config.md`, lines 12–17 **Vulnerability Type**: Plaintext sensitive credential storage **Risk Level**: Medium ### Vulnerable Code ```json "env": { "DDF_BASE_URL": "https://your-ddf-api-base/", "DDF_AUTH_URL": "https://your-ddf-auth-url/", "DDF_TOKEN_GRANT": "client_credentials", "DDF_CLIENT_ID": "...", "DDF_CLIENT_SECRET": "..." } ``` ### Technical Analysis The configuration template instructs users to place DDF authentication credentials directly in the Claude Desktop MCP configuration. When the placeholders are replaced with operational values, the client identifier and client secret—or corresponding username and password for the password grant—are persistently stored as plaintext in a local configuration file. This guidance conflicts with the warning in `SKILL.md` not to store credentials in plaintext files committed to Git. Even when the configuration is not committed, plaintext secrets may be exposed to other local users or processes, endpoint-management tooling, backups, synchronization services, diagnostic bundles, or accidental source-control commits. The artifact contains only documentation and does not include the referenced MCP server implementation. Consequently, server-side controls such as token scoping, field allowlisting, authorization enforcement, logging redaction, and credential handling could not be verified. ### Attack Path 1. A user follows the documented configuration and replaces the placeholder values with a valid DDF client identifier and secret. 2. The populated MCP configuration is persisted as plaintext on the workstation. 3. An attacker, unauthorized local process, backup operator, synchronization service, or unintended repository recipient obtains read access to that file. 4. The attacker extracts the authentication endpoint, grant type, client identifier, and client secret. 5. The attacker submits the stolen credentials to the configur ...[truncated 937 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not instruct users to place operational secrets directly in the persistent MCP configuration. 2. Integrate an operating-system keychain, enterprise secret manager, or runtime credential broker and place only secret references in the configuration. 3. If the MCP runtime cannot resolve secret references, use a restricted launcher that obtains secrets at startup and injects them into the child process environment without writing them to disk. 4. Apply least-privilege scopes to the DDF OAuth client and use separate credentials for each user, environment, and deployment. 5. Restrict access to any unavoidable configuration file using owner-only filesystem permissions and exclude it from source control, cloud synchronization, backups, logs, and diagnostic archives where practical. 6. Add an example configuration containing placeholders only, accompanied by explicit warnings that populated copies must never be committed or shared. 7. Prefer short-lived access tokens and automated secret rotation. Revoke and rotate any credential suspected of exposure. 8. Where supported, add source-IP restrictions, audience validation, usage monitoring, rate limits, and alerts for anomalous authentication or query activity. 9. Ensure the MCP server redacts credentials, authorization headers, and tokens from logs and error messages. ]]>