T09 · Insecure Skill Coding Practices
- Location
ENDPOINTS.md:81- Finding
Unvalidated Response-Controlled URL May Enable SSRF and Credential Forwarding
- Content
View full analysis
Vulnerability Details
File Location:
ENDPOINTS.md, lines 81-86
Vulnerability Type: Server-Side Request Forgery and unsafe credential forwarding
Risk Level: Medium
Category: T09: Insecure Skill Coding PracticesThe documented export workflow extracts a download URL directly from an HTTP response and subsequently requests that URL without validating its scheme, host, port, or resolved network address.
yaml - expression: response.json.download_url output: state.data_url # Main request uses URL from setup request: url: "{state.data_url}" method: "GET"Technical Analysis
response.json.download_urlis remote input controlled by the API that provides the export-status response. It is copied intostate.data_urland used as the complete destination of a subsequent HTTP request.No documented control requires the destination to:
- Use HTTPS.
- Match the original API origin.
- Belong to an explicit host allowlist.
- Resolve to a public, non-loopback address.
- Avoid private, link-local, or cloud metadata networks.
- Exclude embedded user information or unusual ports.
ENDPOINTS.mdalso states that endpoints inherit their settings from defaults and may inherit connection-level authentication. Therefore, if Sling preserves authentication or default headers when requestingstate.data_url, an origin change could forward bearer tokens, API keys, cookies, or other sensitive headers to an attacker-controlled server. Whether credentials are forwarded depends on the underlying Sling runtime, but the documentation does not require them to be removed.This behavior is unnecessary for the minimum privilege needed by a GET-only extraction workflow unless response-provided download destinations are constrained to trusted export hosts.
Attack Path
- A threat actor compromises, impersonates, or manipulates the API that returns the export-s ...[truncated 1462 chars]
- Remediation
View remediation
Remediation Suggestions
-
Validate the download URL before making the request:
- Permit only
https. - Require an explicit allowlist of trusted export hosts.
- Reject URLs containing user information.
- Restrict ports to approved values.
- Normalize and parse the URL with a standards-compliant parser before comparison.
- Permit only
-
Apply network-level SSRF defenses:
- Resolve the hostname and reject loopback, private, link-local, multicast, and reserved addresses.
- Revalidate every redirect destination and DNS resolution result.
- Block cloud metadata ranges, including link-local metadata services.
- Use an egress proxy or firewall allowlist for export downloads.
-
Prevent credential forwarding:
- Explicitly disable inherited endpoint authentication for cross-origin downloads.
- Remove
Authorization,Cookie, proxy authorization, and API-key headers. - Attach credentials only when the validated destination matches the expected trusted origin.
- Do not automatically restore sensitive headers after redirects.
-
Prefer a fixed trusted origin:
- Accept only a relative download path or opaque export identifier from the API.
- Construct the final URL using a statically configured, trusted base URL.
- Reject absolute URLs when cross-origin downloads are not required.
-
Update the documentation with a secure example and a warning that response-derived URLs are untrusted input.
A safer conceptual pattern is:
yaml # Treat the response as an identifier or relative path, not a complete URL. - expression: response.json.download_path output: state.download_path request: url: "{state.trusted_export_base_url}/{state.download_path}" method: "GET" authentication: nullThe runtime must still normalize and validate
state.download_pathto prevent traversal, scheme-relative URLs, and authority replacement.-
