T09 · Insecure Skill Coding Practices
- Location
scripts/monitor.py:19- Finding
Arbitrary URL Fetching Enables Server-Side Request Forgery
- Content
View full analysis
Vulnerability Details
File Location:
scripts/monitor.py:19-31, 130-140
Vulnerability Type: Server-Side Request Forgery (SSRF)
Risk Level: HighVulnerable Code
python def fetch_url_content(url): """获取网页内容""" headers = { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36' } try: # 启用 SSL 验证确保安全 response = requests.get(url, headers=headers, timeout=30, verify=True) response.raise_for_status() return response.text except requests.exceptions.SSLError as e: return f"ERROR: SSL verification failed - {str(e)}" except Exception as e: return f"ERROR: {str(e)}"python def main(): """主函数""" # 解析命令行参数 if len(sys.argv) < 2: print("使用方法：monitor.py <url> [rule]") sys.exit(1) url = sys.argv[1] rule = sys.argv[2] if len(sys.argv) > 2 else "content" # 获取页面内容 content = fetch_url_content(url)Technical Analysis
The monitoring URL is taken directly from a command-line argument and passed to
requests.get()without validating its scheme, hostname, resolved IP address, or destination network. Python Requests also follows redirects by default, and the code does not validate redirect targets.Consequently, a user who can create or influence a monitoring task may cause the machine running the Skill to send HTTP requests to destinations accessible from that machine. Potential targets include loopback interfaces, RFC 1918 private networks, link-local services, and cloud instance metadata endpoints.
The use of
verify=Trueonly validates HTTPS certificates. It does not prevent SSRF, requests to plain HTTP endpoints, access to internal addresses, or redirection to protected networks.Although the complete response body is not directly included in notifications, it is parsed, hashed, and compared with previously stored state. Price-like values and change information can be emitted thr ...[truncated 1859 chars]
- Remediation
View remediation
Remediation Suggestions
- Permit only explicitly supported schemes, normally
httpsand, only if required,http. Reject URLs containing unsupported schemes, embedded credentials, malformed hosts, or ambiguous address representations. - Resolve the hostname before making a request and reject every address classified as loopback, private, link-local, multicast, reserved, unspecified, or otherwise non-global.
- Explicitly block cloud metadata destinations, including link-local metadata addresses and provider-specific metadata hostnames.
- Disable automatic redirects or validate every redirect destination with the same scheme, hostname, DNS, and IP-address checks before following it.
- Mitigate DNS rebinding and time-of-check/time-of-use issues by ensuring that the validated address is the address used for the connection.
- Prefer an administrator-managed allowlist of approved domains where the deployment does not require unrestricted Internet monitoring.
- Apply outbound firewall or proxy rules so the Skill cannot reach loopback, private networks, link-local ranges, metadata services, or sensitive management networks.
- Restrict monitoring-task creation to authorized users and validate URLs again when scheduled tasks execute.
- Avoid returning raw network errors to untrusted users, and ensure logs and notifications do not disclose internal addresses or response-derived secrets.
- Add tests covering direct private addresses, alternative IP encodings, IPv6 loopback and private ranges, DNS rebinding scenarios, and public-to-private redirects.
- Permit only explicitly supported schemes, normally