T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/fetch_douyin_no_watermark.sh:39
- Finding
- Douyin domain validation can be bypassed through substring matching<![CDATA[ ## Vulnerability Details **File Location**: `scripts/fetch_douyin_no_watermark.sh`, lines 39-42 **Additional Locations**: `references/shortcut-build-guide.md`, lines 44-47; `assets/shortcut-logic.json`, line 14 **Vulnerability Type**: Improper URL hostname validation **Risk Level**: Medium ### Vulnerable Code ```bash is_valid_douyin_url() { local value="$1" [[ "$value" =~ https?://[^[:space:]]+ ]] && [[ "$value" =~ (douyin\.com|iesdouyin\.com) ]] } ``` The corresponding Shortcut architecture also specifies substring-based validation: ```json {"step": "validate_domain", "action": "must_contain:douyin.com|iesdouyin.com"} ``` ### Technical Analysis The validation checks whether the complete URL string contains `douyin.com` or `iesdouyin.com`. It does not parse the URL and verify its hostname. Consequently, attacker-controlled URLs such as the following satisfy the check even though their actual host is not operated by Douyin: ```text https://attacker.example/path?target=douyin.com https://douyin.com.attacker.example/video https://attacker.example/douyin.com/video ``` The same validation pattern is prescribed by the Shortcut build guide and represented in the Shortcut architecture, so the weakness affects both the shell resolver and implementations created from the documentation. ### Attack Path 1. An attacker supplies or places an attacker-controlled URL in Share Sheet input, text input, or the clipboard. 2. The URL contains the text `douyin.com` or `iesdouyin.com` somewhere outside the legitimate hostname boundary. 3. The substring-based validation accepts the URL. 4. The skill sends the attacker-controlled URL to TikWM or the configured fallback parser. 5. The external parser processes a URL that should have been rejected by the skill's stated domain restriction. ### Impact Assessment This bypass defeats the skill's input-domain security boundary and discloses the supplied URL to an external parser service. Depending on how that exte ...[truncated 354 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions Parse the URL and validate the normalized hostname rather than searching the entire string. 1. Require an HTTPS URL unless HTTP support is explicitly necessary. 2. Extract the hostname using a well-tested URL parser. 3. Normalize the hostname to lowercase and remove a trailing dot. 4. Accept only exact approved hosts or subdomains with a dot boundary: - `douyin.com` - `*.douyin.com` - `iesdouyin.com` - `*.iesdouyin.com` 5. Reject malformed URLs, embedded credentials, missing hosts, and ambiguous representations. 6. Apply the same validation logic in the shell script, Shortcut instructions, and architecture asset. 7. Add negative tests for: - `douyin.com.attacker.example` - `attacker.example/?url=douyin.com` - `attacker.example/douyin.com` - encoded or malformed hostnames For shell implementations, hostname extraction should use a proper URL-parsing utility or a small trusted language runtime rather than another permissive regular expression. ]]>