T09 · Insecure Skill Coding Practices
- Location
scripts/datayes_macro.py:54- Finding
Bearer Token Disclosure Through Unvalidated Cross-Origin Redirects
- Content
View full analysis
Vulnerability Details
File Location:
scripts/datayes_macro.py, lines 54–66
Vulnerability Type: Authorization credential exposure through unsafe HTTP redirect handling
Risk Level: Highpython req = Request( url, headers={ "Authorization": f"Bearer {get_token()}", "Accept": "application/json", "User-Agent": "datayes-macro-skill/1.0", }, ) try: with urlopen(req, timeout=DEFAULT_TIMEOUT) as resp: return json.load(resp)Technical Analysis
The request includes the sensitive
DATAYES_TOKENvalue in anAuthorization: Bearerheader and is issued usingurllib.request.urlopen(). Its default opener automatically processes HTTP redirects.The implementation validates dynamically resolved API URLs before the initial request, but it does not validate each redirect destination. Consequently, the trusted-host restriction can be bypassed after the first request. A redirect-generated request may retain the
Authorizationheader, causing the token to be transmitted to a destination that was never checked againstALLOWED_HTTP_HOSTS.The fixed API metadata endpoint is also passed directly to
request_json()and therefore has the same redirect-handling exposure. The existing tests only verify initial URL validation and do not cover cross-origin redirects.Sending the bearer token to authenticated Datayes endpoints is necessary for the Skill's declared functionality. Allowing the credential to follow redirects to arbitrary origins is not necessary and exceeds the intended trusted-domain boundary.
Attack Path
- An allowed Datayes endpoint is compromised, maliciously configured, or otherwise made to return an HTTP redirect.
- The redirect points to an attacker-controlled HTTPS origin.
urlopen()automatically follows the redirect without invokingvalidate_http_url()for the new destination.- The redirected request retains the bear ...[truncated 677 chars]
- Remediation
View remediation
Remediation Suggestions
- Install a custom
HTTPRedirectHandlerthat rejects redirects for authenticated requests, or manually process redirect responses. - If redirects are operationally required, resolve each
Locationvalue against the current URL and pass every resulting destination throughvalidate_http_url()before following it. - Strip
Authorizationon every origin change. Compare the normalized scheme, hostname, and effective port rather than only the hostname. - Prefer allowing authenticated redirects only when both the original and destination origins are identical. If cross-host Datayes redirects are required, define an explicit, narrowly scoped policy for each permitted transition.
- Apply the redirect policy to both API metadata requests and business-data requests.
- Add regression tests covering:
- rejection of redirects to an untrusted HTTPS host;
- rejection of redirects from HTTPS to HTTP;
- removal of authorization credentials on origin changes;
- permitted same-origin redirects, if they are required;
- redirect chains in which a later hop leaves the trusted origin.
- Ensure error messages and debug output never include the bearer token, and document immediate token revocation as the incident-response action if disclosure is suspected.
- Install a custom
