T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/dify_ops.py:126
- Finding
- Dify API Key Exposed Through Command-Line Arguments## Vulnerability Details **File Location**: `scripts/dify_ops.py:126`; insecure invocation examples also appear in `SKILL.md:30` and `SKILL.md:60` **Vulnerability Type**: API credential exposure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```python parser.add_argument("--api-key", required=True) ``` The Skill documentation instructs users to invoke the script as follows: ```bash python3 scripts/dify_ops.py --dataset-id $DATASET_ID --api-key $API_KEY --proxy $PROXY list ``` ```bash python3 scripts/dify_ops.py --dataset-id $DATASET_ID --api-key $API_KEY --proxy $PROXY batch --json-file /tmp/new_memes.json ``` ### Technical Analysis The script requires a reusable Dify API credential to be supplied as a command-line argument. After shell expansion, the credential becomes part of the process argument vector. It may consequently be exposed through: - Process inspection interfaces and system-monitoring tools while the command is running. - Shell history if users enter or expand the credential directly in a recorded command. - Process accounting, diagnostic collection, audit logs, or automation logs that capture command lines. The script sends the credential only to the fixed HTTPS endpoint `https://api.dify.ai/v1`, and TLS verification is not disabled. Sending an authorization token to Dify is necessary for the declared knowledge-base functionality. The vulnerability is therefore not the intended Dify network transmission, but the insecure local credential-delivery mechanism. ### Attack Path 1. A user follows `SKILL.md` and runs the script with `--api-key $API_KEY`. 2. The shell expands the environment variable into the command's process arguments. 3. A local user, monitoring agent, process-accounting system, or exposed automation log captures the command line. 4. The observer extracts the bearer token. 5. The attacker submits the recovered token to the Dify API. 6. Subject to the token's assigned permissions, the ...[truncated 760 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the `--api-key` command-line option and obtain the credential from a protected secret source, such as: - A secret manager. - A restricted-permission configuration file. - A dedicated environment variable, while ensuring it is not printed or inherited unnecessarily. - Standard input through `getpass.getpass()` for interactive execution. 2. For example, replace the argument with protected environment-variable retrieval: ```python import os api_key = os.environ.get("DIFY_API_KEY") if not api_key: parser.error("DIFY_API_KEY must be configured securely") ``` 3. Update `SKILL.md` so documented commands do not contain `--api-key` or interpolate credentials into the command line. 4. Ensure logs, exceptions, diagnostics, and status output never include the bearer token. 5. Use a dataset-scoped, least-privilege token where Dify supports it. Avoid broader administrative credentials. 6. Rotate any token previously passed through command lines if process metadata, shell history, or automation logs may have been accessible. 7. Restrict access to runtime environments and CI/CD logs, and configure secret masking as defense in depth.