T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/smart_travel.py:14
- Finding
- Hard-Coded Shared Proxy Authentication Token## Vulnerability Details **File Location**: `scripts/smart_travel.py:14-18`, with credential use at `scripts/smart_travel.py:34-40`, `54-60`, `77-83`, and `97-103` **Vulnerability Type**: Hard-coded authentication credential **Risk Level**: Medium ### Vulnerable Code ```python FLIGGY_PROXY = "https://1439498936-6sysdjjt99.ap-guangzhou.tencentscf.com" GAODE_PROXY = "https://1439498936-bl10af74fl.ap-guangzhou.tencentscf.com" TONGCHENG_PROXY = "https://1439498936-7vqpkiipef.ap-guangzhou.tencentscf.com" TUNIU_PROXY = "https://1439498936-0junm3maxj.ap-guangzhou.tencentscf.com" PROXY_TOKEN = "tp_8k2mX9vQ4z" ``` The same embedded credential is supplied to all four proxy services: ```python headers={"Content-Type": "application/json", "X-Proxy-Token": PROXY_TOKEN}, ``` ### Technical Analysis The package exposes a reusable authentication token directly in source code alongside all corresponding service endpoints. Any party able to download or inspect the Skill can recover the token without executing the code. Because the token is shared across the Fliggy, Gaode, Tongcheng, and Tuniu proxy clients, it cannot provide meaningful caller isolation. If the backends accept it as sufficient authorization, an attacker can reproduce the requests outside the Skill and submit arbitrary supported request bodies directly to the disclosed Tencent Cloud Function endpoints. The outbound network access itself is consistent with the declared travel-search functionality. The security defect is the distribution of a long-lived shared credential to every Skill recipient rather than the minimum necessary network privilege. ### Attack Path 1. Download or otherwise inspect the publicly distributed Skill package. 2. Read `scripts/smart_travel.py` and extract the four proxy URLs and `PROXY_TOKEN`. 3. Construct an HTTPS POST request to one of the disclosed endpoints. 4. Set `X-Proxy-Token: tp_8k2mX9vQ4z` and submit a crafted JSON request mat ...[truncated 1009 chars]
- Remediation
- ## Remediation Suggestions 1. Revoke and rotate the exposed token immediately, treating it as compromised. 2. Remove all authentication secrets from the source package and repository history. 3. Obtain credentials at runtime from a trusted secret-management or authorization service rather than distributing them with the Skill. 4. Prefer short-lived, per-user or per-installation credentials with narrow scopes and explicit expiration. 5. Use separate credentials for each backend so compromise of one integration does not authorize access to every proxy. 6. Enforce server-side route allowlists and strict JSON schema validation; never rely on the client to restrict request types or parameters. 7. Add per-identity rate limits, quotas, replay resistance, anomaly detection, and auditable request attribution. 8. Limit upstream permissions to read-only travel-search operations and prevent access to administrative or unrelated proxy routes. 9. Provide a revocation and rotation mechanism that does not require publishing another shared secret in source code. 10. Document what user data is transmitted, the proxy operator, retention behavior, and applicable privacy controls. The package states that proxy services do not retain user data, but this cannot be verified from the audited client code.