T09 · Insecure Skill Coding Practices
- Location
SKILL.md:40- Finding
Unrestricted User-Controlled Endpoint Checks Enable SSRF and Internal Network Reconnaissance
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:40-45
Vulnerability Type: Server-Side Request Forgery through unrestricted endpoint monitoring
Risk Level: MediumVulnerable Code Snippet
markdown 2. **Gather the data** — collect or parse the infrastructure data: - Parse user-provided system command output (top, df, free, uptime, etc.) - Execute HTTP/HTTPS checks against provided endpoints - Parse provided log snippets or monitoring data exports - Detect the data type and validate completeness - If data is insufficient for a meaningful assessment, ask for specifics before proceedingThe intended behavior is confirmed by
references/test-prompts.md:27-38:markdown ### HP-2: Endpoint uptime check with SSLCheck these endpoints for me:
- https://api.myapp.com/health — should return 200
- https://myapp.com — main website, should return 200
- https://admin.myapp.com — admin panel, should return 200
Also check the SSL certs. We use Let's Encrypt.
text **Expected:** Runs HTTP checks against all three endpoints. Reports status code, response time, and SSL certificate expiry for each.Technical Analysis
The Skill directs the Agent to issue HTTP and HTTPS requests to user-provided endpoints without defining destination-validation controls. It does not prohibit requests to:
- Loopback addresses such as
127.0.0.1and::1 - RFC1918 private networks
- Link-local addresses
- Cloud instance metadata services
- Reserved, multicast, or otherwise non-public address ranges
- Hostnames that resolve to prohibited addresses
- Public URLs that redirect to prohibited destinations
The requirement in
SKILL.md:190that users explicitly provide connection details does not establish that the requester owns or is authorized to test the target. It also does not prevent access to resources that are reachable only from the Agent's network environment.This is an SSRF-style weakness because an untrusted user can influence ...[truncated 1830 chars]
- Remediation
View remediation
Remediation Suggestions
-
Restrict supported protocols
- Permit only
httpandhttps. - Reject URLs containing embedded credentials.
- Reject unsupported schemes and ambiguous URL syntax.
- Permit only
-
Validate resolved destinations
- Resolve the hostname before connecting.
- Reject IPv4 and IPv6 loopback, private, link-local, multicast, reserved, documentation, and unspecified ranges.
- Explicitly block known cloud metadata addresses and hostnames.
- Validate every resolved address rather than only the first result.
-
Prevent DNS rebinding and redirect bypasses
- Pin the validated address for the connection where feasible.
- Revalidate DNS results on every request.
- Disable redirects by default or validate every redirect destination before following it.
- Apply the same controls to SSL and TCP connectivity checks.
-
Require authorization for non-public targets
- Refuse private or internal targets by default.
- If internal monitoring is a required feature, require explicit target allowlisting by an administrator rather than accepting arbitrary targets from conversational input.
- Document that supplying a hostname alone does not prove authorization.
-
Limit request behavior
- Restrict destination ports to an approved set.
- Apply short connection and response timeouts.
- Limit response sizes and avoid downloading response bodies when only uptime is being checked.
- Do not forward user-supplied authentication headers, cookies, or ambient credentials.
- Limit the number and rate of checks to reduce scanning potential.
-
Minimize returned information
- Return only the minimum status information needed for monitoring.
- Do not include internal response bodies, sensitive headers, or user data.
- Redact internal addresses and certificate details when disclosure is unnecessary.
-
Add explicit Skill-level safeguards
- Update
SKILL.mdto forbid checks against unauthori ...[truncated 230 chars]
- Update
-
