T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/datayes_web_search.py:60- Finding
Bearer Token May Be Disclosed Through Unvalidated HTTP Redirects
- Content
View full analysis
Any: body = None headers = { "Authorization": f"Bearer {get_token()}", "Accept": "application/json", "User-Agent": "datayes-web-search-skill/1.0", } if payload is not None: body = json.dumps(payload, ensure_ascii=False).encode("utf-8") headers["Content-Type"] = "application/json" req = Request(url=url, data=body, headers=headers, method=method) try: with urlopen(req, timeout=DEFAULT_TIMEOUT) as resp: return json.load(resp) ``` ### Technical Analysis The implementation validates the original API URL against an HTTPS host allowlist before calling `request_json`. However, `urllib.request.urlopen` follows supported HTTP redirects automatically, and the code does not validate each redirect destination. The original request contains the sensitive `DATAYES_TOKEN` in an `Authorization: Bearer` header. A redirect request may retain request headers, including authorization data, while some redirect status codes can also preserve the HTTP method and request body. Consequently, validation of only the initial URL does not guarantee that the token and user query remain confined to an approved Datayes host. Exploitation requires a trusted Datayes endpoint, or infrastructure controlling its response path, to issue a redirect to an attacker-controlled destination. There is no evidence in the audited project that it can independently cause such a redirect, so this is a defensive coding weakness rather than evidence of intentional exfiltration. ### Attack Path 1. A user invokes the Skill with a valid `DATAYES_TOKEN` and a search query. 2. The script validate ...[truncated 1213 chars]- Remediation
View remediation