T09 · Insecure Skill Coding Practices
- Location
SKILL.md:60- Finding
Bypassable MCP Endpoint Domain Allowlist
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:60
Vulnerability Type: Confirmation-based bypass of a security boundary
Risk Level: HighComplete Vulnerable Snippet — translated faithfully into English from the source:
text ① URL domain allowlist: Only accept official DingTalk domains— aihub.dingtalk.com, alidocs.dingtalk.com, and other *.dingtalk.com subdomains. If the URL domain is not in the allowlist, stop registration and tell the user that the URL may be incorrect or risky. Continue only after the user confirms.Technical Analysis
The instructions describe the domain check as an allowlist intended to prevent MCP traffic, including a personal API key, from being sent to an incorrect or malicious endpoint. However, the same instruction permits registration to continue after user confirmation.
This converts a mandatory trust boundary into a warning prompt. A user can be socially engineered into approving an attacker-controlled endpoint, so the check does not reliably enforce the stated restriction. The instructions also do not specify strict URL parsing, HTTPS enforcement, rejection of embedded credentials, or hostname canonicalization. An implementation using textual suffix matching could consequently be exposed to deceptive hostnames or URL parsing ambiguity.
Attack Path
- An attacker supplies or recommends a StreamableHttp URL hosted outside an official DingTalk domain.
- The Skill detects that the hostname is not allowlisted and displays a warning.
- The attacker persuades the user to confirm registration despite the warning.
- The Skill registers the untrusted endpoint under the trusted service name
dingtalk-doc. - Subsequent MCP calls transmit request metadata and potentially sensitive document operations to that endpoint.
- If the URL contains authentication material, that material is also disclosed to the endpoint or retained in its logs.
- Later uploads or d ...[truncated 890 chars]
- Remediation
View remediation
Remediation Suggestions
- Make the allowlist mandatory. Never permit user confirmation to override a failed endpoint validation.
- Parse the URL with a standards-compliant URL parser and validate the normalized hostname, rather than searching the raw URL string.
- Require HTTPS and reject URLs containing unexpected schemes, fragments, user-information fields, or malformed ports.
- Accept only exact approved hosts or normalized hostnames ending in
.dingtalk.com, while separately allowing the apex domain if required. - Reject deceptive names such as
dingtalk.com.attacker.example, trailing-dot ambiguities, encoded hostnames, and invalid internationalized domain names. - If an organization must use a nonstandard endpoint, require a separate advanced configuration process with explicit administrator-controlled policy rather than a conversational warning bypass.
- Display only a redacted endpoint during confirmation so query parameters containing credentials are not repeated.