T09 · Insecure Skill Coding Practices
- Location
scripts/extract_product.py:31- Finding
Server-Side Request Forgery Through Unrestricted Product URL Fetching
- Content
View full analysis
Vulnerability Details
File Location:
scripts/extract_product.py:31-44andscripts/extract_product.py:262-264
Vulnerability Type: Server-Side Request Forgery (SSRF)
Risk Level: HighVulnerable Code
python def __init__(self, url: str): self.url = url self.domain = urlparse(url).netloc.lower() self.product_data = {} def extract(self) -> Dict: """Main extraction method - routes to domain-specific extractor.""" if not REQUESTS_AVAILABLE: return self._get_manual_extraction_prompt() try: headers = { 'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36' } response = requests.get(self.url, headers=headers, timeout=15)The URL originates directly from a command-line argument:
python url = sys.argv[1] extractor = ProductExtractor(url) result = extractor.extract()Technical Analysis
The script accepts an arbitrary URL and passes it directly to
requests.get()without validating its scheme, hostname, resolved IP address, port, or redirect destinations.No controls prevent requests to loopback, private, link-local, reserved, or cloud metadata addresses. Because
requestsfollows redirects by default, an initially public URL can also redirect to an internal destination. Hostname-only checks would be insufficient because DNS rebinding or a hostname resolving to a prohibited address could bypass them.The response is loaded as a complete body through
response.textbefore parsing. There is no response-size limit or streaming byte budget, so a malicious endpoint can also return an excessively large response and consume significant memory.Attack Path
- An attacker supplies a product URL such as an internal service address, cloud metadata endpoint, attacker-controlled hostname resolving to a private address, or public URL that redirects to one.
- The Agent foll ...[truncated 1584 chars]
- Remediation
View remediation
Remediation Suggestions
- Permit only explicitly supported schemes, normally
httpsand, only if necessary,http. Reject URLs containing credentials, malformed hosts, or unsupported ports. - Resolve the hostname before connecting and reject every address that is loopback, private, link-local, multicast, unspecified, reserved, or otherwise non-global.
- Disable automatic redirects or validate the scheme, hostname, port, and resolved addresses of every redirect target before following it.
- Prefer an explicit allowlist of supported e-commerce domains when business requirements permit. Match normalized hostnames exactly or as controlled subdomains rather than using substring tests.
- Protect against DNS rebinding by ensuring the validated address is the address used for the connection, or by enforcing equivalent destination restrictions at an outbound proxy or firewall.
- Stream responses and enforce a strict maximum byte count. Reject unexpected content types before parsing.
- Apply outbound network controls that block access to loopback, private networks, link-local metadata services, and internal management interfaces.
- Consider disabling environment-derived proxy configuration with an appropriately configured
requests.Sessionwhen proxy inheritance is not required. - Replace detailed network exception strings returned to users with generic errors, while retaining sanitized diagnostic details in protected logs.
- Add tests covering direct private IP addresses, IPv6 loopback and link-local addresses, encoded or unusual IP forms, DNS names resolving to private addresses, redirect chains, unsupported schemes, and oversized responses.
- Permit only explicitly supported schemes, normally
