T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/common.py:48
- Finding
- API Token Exposed in URL Query Strings## Vulnerability Details **File Location**: `scripts/common.py:48-56` **Vulnerability Type**: Sensitive credential exposure through URL query parameters **Risk Level**: Medium ### Vulnerable Code ```python params["key"] = get_token() params["_t"] = int(time.time() * 1000) url = f"{BASE_URL}/{endpoint}?" + urllib.parse.urlencode(params) try: req = urllib.request.Request(url) req.add_header("User-Agent", "BaiduEcommerceSkill/1.0") with urllib.request.urlopen(req, timeout=timeout) as response: ``` ### Technical Analysis The shared API client inserts `BAIDU_EC_SEARCH_TOKEN` into the `key` query parameter of every request. Although HTTPS encrypts the URL while it is in transit, URLs may be retained in reverse-proxy access logs, application telemetry, monitoring platforms, debugging output, browser or gateway history, and infrastructure error reports. This request function is shared by all operations, including access to address and order information and state-changing operations such as `address_add` and `order_create`. Those state-changing calls are also sent using GET because no request body or explicit HTTP method is configured. Exploitation requires access to a component or record containing the complete request URL. There is no evidence that this project itself logs the URL; the risk arises from common URL handling by surrounding infrastructure. ### Attack Path 1. A user configures a valid `BAIDU_EC_SEARCH_TOKEN`. 2. The user invokes any Skill operation. 3. `request_api()` appends the token to the request URL as `key`. 4. A reverse proxy, gateway, telemetry service, diagnostic tool, or another authorized observer records the complete URL. 5. An attacker obtains access to that record and extracts the token. 6. The attacker replays the token against the Baidu ecommerce API. 7. Subject to the token's server-side permissions, the attacker accesses ecommerce data or invokes transaction-related op ...[truncated 745 chars]
- Remediation
- ## Remediation Suggestions 1. Transmit the token in an HTTP header, preferably `Authorization: Bearer <token>`, rather than in the URL. 2. If the server uses a custom authentication scheme, place the credential in a dedicated non-URL header and document that scheme. 3. Use POST or another semantically appropriate method with a request body for state-changing operations such as address creation and order creation. 4. Configure clients, gateways, proxies, monitoring systems, and exception handlers to redact authorization headers and sensitive parameters. 5. Never print or include the token in errors, telemetry, or diagnostic output. 6. Rotate credentials that may already have appeared in URL logs and apply short expiration periods where supported. 7. Restrict each token to the minimum required API capabilities and implement server-side authorization for every operation. 8. Add automated tests that verify generated URLs do not contain credentials and that state-changing endpoints do not use GET.