T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:52- Finding
Webhook Delivery Guidance Omits Server-Side Request Forgery Protections
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 52–80
Vulnerability Type: Inadequate SSRF prevention guidance and sensitive delivery logging
Risk Level: MediumRelevant snippet:
markdown ## Sending: Timeouts - 5-10 second timeout—don't wait forever for slow receivers - Treat timeout as failure—retry later - Don't follow redirects—or limit to 1-2; prevents redirect loops - Validate HTTPS certificate—don't skip verification ## Event Design - Include event type: `{"type": "order.created", ...}`—receivers filter by type - Include timestamp: ISO 8601 with timezone—for ordering and freshness - Include full resource or ID—prefer full data; saves receiver a lookup - Version events: `api_version` field—allows breaking changes ## Delivery Tracking - Log every attempt: URL, status code, response time, response body - Dashboard for retry queue—let users see pending/failed deliveries - Manual retry button—for stuck webhooks after receiver fix - Webhook logs retention: 7-30 days—balance debugging vs storage ## Security Checklist - HTTPS only—never send webhooks to HTTP endpoints - Rotate secrets periodically—support multiple active secrets during rotation - IP allowlisting optional—document your IP ranges if offered - Don't include secrets in payload—webhook URL should be secret enough - Rate limit per endpoint—one slow receiver shouldn't affect othersTechnical Analysis
The Skill instructs implementations to send server-side HTTP requests to webhook destinations but does not require validation that destination URLs resolve only to permitted public network addresses. Missing controls include:
- Blocking loopback, private, link-local, multicast, reserved, and cloud metadata addresses.
- Rejecting credentials embedded in URLs.
- Restricting destination ports and URL schemes.
- Preventing DNS rebinding or time-of-check/time-of-use resolution changes.
- Revalidatin ...[truncated 2218 chars]
- Remediation
View remediation
Remediation Suggestions
- Permit only the
httpsscheme and reject malformed URLs, URL fragments, embedded credentials, and unexpected ports. - Resolve destinations before connecting and reject every address in loopback, private, link-local, multicast, reserved, unspecified, and cloud metadata ranges for both IPv4 and IPv6.
- Validate every resolved address, not only the first returned address.
- Pin the validated address during connection or use a transport that prevents DNS rebinding between validation and connection.
- Disable redirects by default. If redirects are necessary, independently parse, resolve, and validate every redirect target and enforce a small hop limit.
- Use explicit destination allowlists for high-risk deployments.
- Apply outbound firewall or proxy rules so application-layer validation is not the only defense.
- Do not attach internal credentials, cookies, or authorization headers to arbitrary webhook destinations.
- Limit response size, response time, and connection concurrency.
- Redact credentials, tokens, query parameters, and sensitive path components before logging destination URLs.
- Avoid storing full response bodies by default. Store only bounded, redacted diagnostic data and apply strict access controls and retention limits.
- Ensure manual retries repeat all destination validation rather than trusting previously stored URLs.
- Permit only the