T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/enterprise_executed.py:286
- Finding
- API Credential Exposure Through Command-Line Arguments and URL Examples## Vulnerability Details **File Location**: `scripts/enterprise_executed.py:70-71`, `scripts/enterprise_executed.py:286-288`; related insecure usage guidance at `SKILL.md:25-34` and `SKILL.md:76-78` **Vulnerability Type**: API credential exposure **Risk Level**: Medium ### Vulnerable Code and Documentation The script accepts the API key directly from a command-line argument: ```python def load_api_key(cli_key: str = None) -> str: if cli_key: return cli_key ``` The command-line parser obtains the credential from the process argument list: ```python if args[i] == "--key" and i + 1 < len(args): cli_key = args[i + 1] i += 2 ``` The documentation explicitly recommends this usage: ```bash python scripts/enterprise_executed.py --key 你的 AppKey --name 河北展发房地产开发有限公司 ``` It also demonstrates placing the API key in a URL query string: ```text GET https://apis.juhe.cn/api_credit/query842?key=YOUR_KEY&name=河北展发房地产开发有限公司&nametype=1&pageIndex=1&pageSize=20&isNeedHisData=true ``` ### Technical Analysis Secrets supplied through command-line arguments can be retained in shell history and may be visible through process-inspection facilities, diagnostic tooling, audit systems, or telemetry collectors. This unnecessarily broadens credential exposure beyond the querying process. Embedding an API key in a URL is also unsafe because query strings may be recorded in browser history, proxy logs, reverse-proxy access logs, monitoring platforms, and other HTTP infrastructure. Although the script itself sends the key to the declared Juhe endpoint using HTTPS and a POST form body, the documented GET example creates a separate credential-disclosure risk. Network transmission to `https://apis.juhe.cn/api_credit/query842` is necessary for the Skill's declared third-party enterprise-record lookup. No undeclared exfiltration endpoint was identified. The weakness is therefore in credentia ...[truncated 1428 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the `--key` command-line option so credentials cannot be supplied through the process argument list. 2. Remove all examples that place API keys in URLs or command-line arguments. 3. Prefer the existing `JUHE_ENTERPRISE_EXECUTED_KEY` environment variable mechanism, while documenting that secrets should be injected by a trusted secret manager rather than committed to shell startup files. 4. If `.env` support remains available: - Require restrictive file permissions such as `0600`. - Add `scripts/.env` and general `.env` patterns to `.gitignore`. - Refuse to load files that are group- or world-readable where supported. - Warn users never to commit the file to source control. 5. For interactive use, optionally accept the key with a hidden prompt such as Python's `getpass.getpass()` when no secure environment-based credential is available. 6. Continue transmitting the key only to the fixed HTTPS endpoint using the POST request body. 7. Avoid including credentials in exceptions, debugging output, request logs, or formatted results. 8. Rotate any API key that has previously been used in command-line or URL examples and review Juhe usage records for unauthorized requests.