T09 · Insecure Skill Coding Practices
- Location
SKILL.md:48- Finding
Privileged credentials are collected through conversation and stored in plaintext configuration
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 48-54 and line 391
Vulnerability Type: Plaintext collection and storage of sensitive credentials
Risk Level: HighRelevant instructions, translated into English:
text 3. Collect MySQL information - Ask: "Please provide your MySQL root password. I will write it into the configuration file." 4. Ask about optional components - AI conversation: "Do you need to integrate AI conversation functionality using Alibaba Cloud Qwen qwen-plus?" - If yes, continue asking: "Please provide the DashScope API Key you obtained from the Alibaba Cloud Bailian platform."text 1. Do not hardcode API keys: Put sensitive information such as the Alibaba Cloud DashScope API Key and MySQL password in application.yml, and add it to .gitignore.Technical Analysis
The skill explicitly instructs the agent to request a MySQL
rootpassword and a DashScope API key through the conversation. It then directs the generated project to place these credentials inapplication.yml.This creates two related security weaknesses:
- Sensitive credentials are disclosed to the agent and conversation infrastructure. Credentials submitted in chat may be retained in conversation history, application telemetry, model-provider logs, exports, or backups.
- Credentials are stored as plaintext project files. Adding a file to
.gitignoreonly prevents ordinary Git tracking. It does not encrypt the file or prevent disclosure through archives, backups, logs, misconfigured repositories, local filesystem access, IDE synchronization, or accidental sharing. - The requested database privilege is excessive. A Spring Boot application ordinarily needs access only to its own schema and required operations. A MySQL
rootaccount grants substantially broader administrative control than the application requires.
Although the skill says not to hardcode secrets, ...[truncated 2416 chars]
- Remediation
View remediation
Remediation Suggestions
-
Do not request secrets through conversation
- Ask users only for non-sensitive identifiers such as a database host, port, schema name, and environment-variable names.
- Instruct users to inject secret values locally without sending them to the agent.
- Explicitly warn users not to paste passwords, private keys, access tokens, or API keys into chat.
-
Replace the MySQL
rootaccount with a dedicated application account- Create a separate user for the generated application.
- Restrict the account to the application's schema.
- Grant only required operations, such as
SELECT,INSERT,UPDATE, andDELETE. - Grant migration privileges separately and only when migrations are being performed.
- Apply source-host restrictions and require encrypted database connections where supported.
-
Use environment-variable placeholders
-
Configuration committed to the project should contain references rather than real secrets:
yaml spring: datasource: username: ${DB_USERNAME} password: ${DB_PASSWORD} dashscope: api-key: ${DASHSCOPE_API_KEY}
-
-
Use a supported secret manager in deployed environments
- Store production credentials in a platform secret store such as Kubernetes Secrets with appropriate encryption controls, Docker secrets, a cloud secret manager, or a dedicated vault.
- Limit access to the runtime service identity that requires each secret.
- Enable audit logging, expiration, and automated rotation where available.
-
Harden local-development handling
- Supply a redacted
.env.examplecontaining placeholder names only. - Exclude actual
.envfiles and local secret-bearing configuration from version control and generated archives. - Restrict filesystem permissions on local secret files.
- Ensure startup and error logs do not print resolved confi ...[truncated 634 chars]
- Supply a redacted
-