Skip to content

Latest commit

 

History

History
34 lines (24 loc) · 4.6 KB

File metadata and controls

34 lines (24 loc) · 4.6 KB

2025-05-18 - [SSRF Protection Bypasses]

Vulnerability: The isSafeUrl function failed to handle IPv6 addresses correctly (square brackets were not stripped before IP check) and missed IPv4-mapped IPv6 addresses (e.g., ::ffff:169.254.x.x), allowing potential access to cloud metadata services. Learning: Standard URL parsing in Node.js retains brackets for IPv6 hostnames, which net.isIP does not handle, causing the code to fall back to dns.lookup. Additionally, deny-lists for IPs must account for all representations (IPv4, IPv6, Mapped). Prevention: Always normalize hostnames (strip brackets) before IP validation. Use comprehensive IP checks that cover IPv4-mapped addresses when implementing blocklists.

2025-05-24 - [Unverified Outgoing Requests (SSRF)]

Vulnerability: Endpoints accepting external URLs (like /api/indexers/prowlarr/sync and /api/indexers/test) were missing calls to the existing isSafeUrl validator, allowing potential Server-Side Request Forgery against cloud metadata or internal network services. Learning: The application relies on manual invocation of isSafeUrl in route handlers. Developers must explicitly add this check for any user-supplied URL intended for outgoing requests. Prevention: Audit all endpoints accepting URLs. Consider using a centralized validation middleware or Zod schema refinement that automatically enforces isSafeUrl validation on URL fields.

2025-05-24 - [SSRF in RSS Feeds]

Vulnerability: The RSS feed creation and update endpoints (POST /api/rss/feeds and PUT /api/rss/feeds/:id) lacked isSafeUrl validation, allowing attackers to force the server to fetch arbitrary URLs, including cloud metadata services (169.254.169.254). Learning: Even if isSafeUrl exists, it must be applied to all inputs that trigger server-side requests. RSS feeds are a common vector for SSRF because they inherently involve fetching remote content. Prevention: Apply isSafeUrl validation to all URL inputs in API routes. Implement defense-in-depth by also validating the URL at the point of use (in rssService.refreshFeed).

2024-05-24 - SSRF Bypass via URL Userinfo

Vulnerability: The /api/stats/discord-share endpoint was vulnerable to Server-Side Request Forgery (SSRF) because it validated webhook URLs using startsWith("https://discord.com/api/webhooks/") and then fetched them using the standard fetch API. Learning: Checking for string prefixes on URLs is insufficient for security because the userinfo component (e.g. https://discord.com/api/webhooks/@127.0.0.1) can be used to bypass the check. The fetch API and URL parsers will interpret 127.0.0.1 as the hostname and discord.com as the credentials. Prevention: Never rely on string prefix matching for URL validation. Always use the project's safeFetch utility which properly resolves and validates the target IP address to prevent SSRF and DNS rebinding attacks.

2025-05-24 - Prevent SSRF by validating parsed URL components instead of prefix matching

Vulnerability: The application validated Discord webhook URLs (and potentially other external URLs) by matching the string prefix (url.startsWith("https://discord.com")). This is vulnerable to SSRF bypasses via the userinfo component (e.g., https://discord.com@127.0.0.1/api/webhooks/). Learning: Checking string prefixes for URL validation is fundamentally insecure because parts of the prefix might be interpreted as the username/password in a URL with a different domain. Attackers can leverage this to bypass domain allowlists. Prevention: Always use the URL object (e.g., new URL()) to parse URLs and explicitly validate the hostname and pathname properties instead of checking raw string prefixes.

2025-05-24 - SSRF Prevention in Internal Downstream Requests

Vulnerability: Downloader API communication (e.g. qBittorrent, Transmission, NZBGet, Deluge, rTorrent) was using the native fetch() to call external URLs (e.g. downloaders running locally or remotely), making the application vulnerable to Server-Side Request Forgery (SSRF) and DNS Rebinding via metadata or local networks. Learning: Even internal API connections must be shielded from interacting with sensitive hostnames or local/cloud metadata networks (169.254.169.254, etc.) via DNS rebinding. Replacing native fetch with a secure wrapper ensures strict host-level validation of all connections. Prevention: Always use the local safeFetch implementation from server/ssrf.ts instead of the global fetch() when making external network requests to any user-provided URL or API configuration to prevent SSRF vulnerabilities.