T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/analyze.py:17
- Finding
- Hard-Coded Enterprise API Credential<![CDATA[ ## Vulnerability Details **File Location**: `scripts/analyze.py`, lines 17–44 **Vulnerability Type**: Hard-coded service credential **Risk Level**: High ### Vulnerable Code ```python BASE_URL = "https://www.ipipei.com/prod-api" ENTERPRISE_KEY = "26b22ed9a21c42ec89b07b6299cdceb5" ``` The credential is subsequently used to request an authorization token: ```python def get_token(): payload = {"enterpriseKey": ENTERPRISE_KEY, "dateTime": now_text()} data = post("enterpriseApi/getToken", payload) if str(data.get("code")) != "200": print(f"[错误] 获取 Token 失败: {json.dumps(data, ensure_ascii=False)}", file=sys.stderr) sys.exit(1) return data["data"] ``` ### Technical Analysis A reusable enterprise key is embedded directly in the distributed source code. Anyone who can download or inspect the Skill can recover the key without authentication. The key is sent to the provider's `enterpriseApi/getToken` endpoint to obtain an authorization token, making it an active credential rather than a non-sensitive identifier. Embedding credentials in source prevents effective access separation between Skill users and exposes the credential through source repositories, package archives, backups, and local installations. Although the precise provider-side permissions cannot be determined from the reviewed code, an attacker can exercise any API capabilities granted to this enterprise key. ### Attack Path 1. An attacker obtains the Skill package or reads `scripts/analyze.py`. 2. The attacker extracts the hard-coded `ENTERPRISE_KEY`. 3. The attacker submits the key and a current timestamp to `https://www.ipipei.com/prod-api/enterpriseApi/getToken`. 4. If the credential remains valid, the attacker receives an authorization token. 5. The attacker invokes provider API operations permitted by that token independently of the Skill. 6. Unauthorized requests may consume the account's quota, incur costs, or process attacker-controlled documents und ...[truncated 598 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Revoke and rotate the exposed enterprise key immediately. 2. Remove the credential from the source code and repository history. 3. Load a per-deployment or per-user credential from an environment variable or managed secret store. 4. Fail securely when the secret is missing rather than providing a shared fallback value. 5. Assign the credential only the minimum API scopes required for token acquisition, file submission, and result polling. 6. Configure provider-side rate limits, spending limits, expiration, source restrictions, and anomaly alerts where supported. 7. Use separate credentials for development, testing, and production. 8. Add secret scanning to the development and release pipeline to prevent future credential commits. ]]>