T09 · Insecure Skill Coding Practices
- Location
scripts/rss_monitor.py:59- Finding
Unrestricted RSS Feed URLs Enable Server-Side Request Forgery
- Content
View full analysis
Vulnerability Details
File Location:
scripts/rss_monitor.py, lines 59-81
Vulnerability Type: Server-Side Request Forgery through unrestricted feed retrieval
Risk Level: Mediumpython 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. Althoughurlparseis 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 scheduledcheck-allinvocation can repeat the request indefinitely.The exploitable capability is bounded by the network permissions of the process and by the content that
feedparsercan 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
- A ...[truncated 1116 chars]
- Remediation
View remediation
Remediation Suggestions
- Accept only explicitly supported schemes, preferably
httpsand, 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.
- Accept only explicitly supported schemes, preferably
