[Security Fix] SAST: User-controlled url query parameter is fetched server-side and response bod...

[okaypatrick]

Security Fix

Type: SAST
Generated by: AI-Powered Fix Generator
Finding: User-controlled url query parameter is fetched server-side and response body is reflected, enabling SSRF and metadata exfiltration.
Rule: claude-ssrf-research-url (oogway-scanner)
File: app/routes/research.js (line 14)
Severity: HIGH

Explanation

The handler concatenated the user-controlled req.query.url with req.query.symbol and passed the result to needle.get, then reflected the response body to the client. An attacker could point url at internal services such as the cloud instance metadata endpoint (e.g. http://169.254.169.254/latest/meta-data/) and receive the response, leaking credentials and enabling SSRF.

The fix introduces a small allow-list of permitted upstream research providers and rejects any request whose url parameter is not on the list before performing the outbound HTTP call. The symbol is also URL-encoded to avoid breaking the allow-list contract by smuggling additional URL components. Existing functionality (rendering the research page and fetching from approved providers) is preserved.

Changes

• app/routes/research.js: Restrict the server-side fetch to an allow-list of trusted research provider URLs and URL-encode the symbol. This prevents an attacker from supplying an arbitrary url query parameter (e.g. http://169.254.169.254/latest/meta-data/) and having the server fetch and reflect its response, eliminating the SSRF / cloud-metadata exfiltration vector.

Test Suggestions

• GET /research?symbol=AAPL&url=https://www.google.com/finance?q= should still proxy and return upstream content.
• GET /research?symbol=x&url=http://169.254.169.254/latest/meta-data/ should return 400 and not perform any outbound request.
• GET /research?symbol=x&url=file:///etc/passwd should return 400.
• GET /research with no symbol should still render the research view.

Breaking Changes

• Requests to /research that supply a url value other than the allow-listed providers will now receive HTTP 400 instead of being proxied. Consumers depending on arbitrary url values must use a permitted entry or have it added to ALLOWED_RESEARCH_URLS.