T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/rss_monitor.py:59
- Finding
- Unrestricted RSS Feed URLs Enable Server-Side Request Forgery## Vulnerability Details **File Location**: `scripts/rss_monitor.py`, lines 59-81 **Vulnerability Type**: Server-Side Request Forgery through unrestricted feed retrieval **Risk Level**: Medium ```python def parse_feed(url): """Parse RSS/Atom feed and return entries""" if not HAS_DEPS: print("错误: 缺少依赖") print("请安装: pip install requests feedparser") return None try: feed = feedparser.parse(url) if feed.bozo: print(f"警告: 解析 feed 时出现问题: {feed.bozo_exception}") entries = [] for entry in feed.entries[:10]: # Get last 10 entries entry_data = { "title": entry.get("title", "无标题"), "link": entry.get("link", ""), "published": entry.get("published", entry.get("updated", "未知时间")), "summary": entry.get("summary", entry.get("description", ""))[:200], "feed_title": feed.feed.get("title", "未知源") } ``` ### Technical Analysis User-supplied feed URLs are passed directly to `feedparser.parse()` without validating the URL scheme, destination hostname, resolved IP address, or redirect chain. Although `urlparse` is imported elsewhere in the script, it is not used to enforce any restrictions. Consequently, a caller can configure a feed URL that targets loopback, private, link-local, or otherwise sensitive network resources accessible from the machine running the Skill. The URL is persisted in `~/.rss_monitor/feeds.json`, so an optional scheduled `check-all` invocation can repeat the request indefinitely. The exploitable capability is bounded by the network permissions of the process and by the content that `feedparser` can parse. Nevertheless, internal services returning RSS-, Atom-, or XML-like content could have their data processed, stored in history, and partially included in Feishu notifications. ### Attack Path 1. A ...[truncated 1116 chars]
- Remediation
- ## Remediation Suggestions - Accept only explicitly supported schemes, preferably `https` and, only when required, `http`. - Reject URLs containing embedded credentials. - Resolve the destination hostname before connecting and reject loopback, private, link-local, multicast, unspecified, and reserved IPv4 and IPv6 ranges. - Validate every redirect destination rather than checking only the initial URL. - Consider requiring an explicit trusted-host allowlist for scheduled feeds. - Apply connection and response-size limits to reduce denial-of-service exposure. - Revalidate saved URLs during every scheduled check because DNS resolution can change after initial registration. - Clearly notify users that configured feeds will be contacted repeatedly when cron scheduling is enabled.
