SSRF Vulnerability in HTTPRequestManager

[retrymp3]

Security: SSRF Vulnerability in HTTPRequestManager

Summary

I've identified a Server-Side Request Forgery (SSRF) vulnerability in Valdi's HTTP client that allows applications to make requests to arbitrary URLs (localhost, private IPs, cloud metadata) without validation.

Component: HTTPRequestManagerModuleFactory.cpp
Vulnerable Code: Lines 50-97

Vulnerability Details

User-provided URLs are passed directly to native HTTP request managers without validation:

// Line 51: URL extracted without validation
auto url = requestObject.getMapValue("url").toStringBox();

// Line 94-97: URL used directly
requestManager->performRequest(HTTPRequest(std::move(url), ...));

Missing: Scheme validation, IP filtering, hostname validation, URL sanitization

Impact

• Critical: Cloud metadata access → Complete cloud account compromise (if app runs on EC2/GCP/Azure)
• High: Internal service access → Data exposure, unauthorized access
• Medium-High: Network reconnaissance → Internal network mapping

Proof of Concept

POC repository: https://github.com/retrymp3/Valdi_SSRF.git (see apps/ssrf_poc/)

Test with: http://localhost:8080, http://169.254.169.254/, etc.

Proposed Fix

I have prepared a fix that adds URL validation:

• Blocks localhost, private IPs, cloud metadata IPs
• Only allows http:// and https:// schemes
• Validates URLs before making requests

Fix PR: #58

Disclosure Process

I attempted to report via HackerOne but was informed the Valdi repository is not in scope. I was advised to submit a GitHub PR. Also I couldn't see any opensource projects in Snapchat's scope on hackerone.

Question: What is the proper process for reporting security issues in Valdi or any of the opensource projects of Snapchat? Is there a seperate channel for this? hackerone does not to seem have any associated assets or scope.

References

• OWASP SSRF: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
• CWE-918: https://cwe.mitre.org/data/definitions/918.html

[retrymp3]

@cholgateSC Could you please confirm/acknowledge this?

[sockeye-d]

Is this even a vulnerability? The requests don't run on the server, since Valdi is just a client-side library from what I can tell, so they won't be able to access internal IP addresses. Like I don't actually think this allows an attacker to gain more access to internal services than they would already.

[clholgat]

Thanks for the effort, but Valdi is a client side framework, we don't believe this is a concern.

[sockeye-d]

Wouldn't that apply to basically every app ever? I'm not sure how blocklisting a few IPs is going to fix this. If you're on a secure corporate network, shouldn't the network itself mitigate access to internal servers through firewalls and authorization? A URL path like /admin/api/users should be behind authentication anyway, and wouldn't this require the use of a malicious app to make requests on an internal network and leak the results? I really don't see how it's the problem of the client-side UI library to mitigate this issue.

[sockeye-d]

Wouldn't that apply to basically every app ever? I'm not sure how blocklisting a few IPs is going to fix this. If you're on a secure corporate network, shouldn't the network itself mitigate access to internal servers through firewalls and authorization? A URL path like /admin/api/users should be behind authentication anyway, and wouldn't this require the use of a malicious app to make requests on an internal network and leak the results? I really don't see how it's the problem of the client-side UI library to mitigate this issue.

[sockeye-d]

Wouldn't that apply to basically every app ever? I'm not sure how blocklisting a few IPs is going to fix this. If you're on a secure corporate network, shouldn't the network itself mitigate access to internal servers through firewalls and authorization? A URL path like /admin/api/users should be behind authentication anyway, and wouldn't this require the use of a malicious app to make requests on an internal network and leak the results? I really don't see how it's the problem of the client-side UI library to mitigate this issue.

[retrymp3]

@sockeye-d SSRF is a common vulnerability, and frameworks can help prevent it at the source. It's not about Valdi being uniquely vulnerable.

On network security, yeah ideally corporate networks should have proper firewalls and internal services should be authenticated. But in practice, not all internal services are properly secured. There are often legacy systems, dev/staging environments, or services that assume "if you're on the network, you're trusted." The reality is that internal network security isn't always perfect.

On authentication, you're right that /admin/api/users should be behind auth. But there are plenty of internal services that aren't, or have weak auth, or the employee already has some level of access. The SSRF lets an attacker probe and potentially escalate beyond what the employee should have access to.

On malicious apps: It's not about malicious apps - it's about legitimate apps that accept user-controlled URLs. Like an image preview feature where users can paste any URL, or a webhook testing tool, or an API client. The app itself is fine, but if it doesn't validate URLs, an attacker can abuse it.

I get that you might not see this as the framework's responsibility. That's fair. But I think of it like input validation. Frameworks often provide sanitization/validation helpers because developers make mistakes. URL validation is similar. It's a relatively small fix that prevents a whole class of vulnerabilities, and developers using Valdi don't have to think about it.

That said, if you don't think this is worth fixing at the framework level, I understand. The severity is definitely context dependent and requires specific conditions to be exploitable. I just figured it was worth proposing since it's a relatively small change that could prevent real issues.

[retrymp3]

@sockeye-d @clholgat This is a actually a common misconception about SSRF. SSRF vulnerabilities are not limited to server side applications they are equally dangerous in client side applications, especially mobile apps. CWE-918 applies to any application making network requests from a privileged network position, including mobile and client-side apps.

Client devices have network access that attackers can exploit. Mobile apps which often run in privileged network contexts and cloud-hosted applications can access metadata services. The issue allows bypassing network security boundaries.

Let me give a scenario of this in a malicious context:

Here's a brief scenario:

Attacker (external) sends malicious URL to employee (http://192.168.1.100:8080/admin/api/users")
Employee uses Valdi app with this URL while on corporate network
App makes request from employee's device (inside corporate network)
Firewall allows request (trusts internal network)
Internal service responds with sensitive data
Attacker extracts data from error messages, logs, or UI displayed to employee
Whether the attacker can see that response depends on how the app is built:

If app shows errors in UI, logs responses, or displays error messages with response data, attacker can extract it
If app makes POST/DELETE requests → attacker might not even need to see the response.
Even without seeing responses (blind SSRF), you can still:

Port scan internal services (timing differences reveal open or closed ports)
Enumerate services (error codes reveal what exists)
Trigger actions on internal APIs
I know I might've went too deep into this, was interesting and I did invest some hefty time in it and thus defending this 😂. But I understand that this isn't a traditional SSRF and is dependent on the app that has based this on. But I think a possible attack scenario like the one I described is possible.

[sockeye-d]

But I think of it like input validation

Input validation is not normally the responsibility of the UI framework? I think that because the requirements are going to be so vastly different between different apps, one solution can't possibly cover all the cases.

It's not about malicious apps - it's about legitimate apps that accept user-controlled URLs

So the scenario is that a hacker has access to a device on an internal network? That seems unrealistic and if they were in that situation, I think an ssrf attack would not be important compared to how many other systems they would have access to.

[retrymp3]

Fair points. But the hacker doesn't need device access. It's more like, attacker sends phishing email/link to employee: "Check this image: http://192.168.1.100:8080/admin/api/users"
Employee opens it in a Valdi app (maybe an image viewer, webhook tester, or API client that accepts URLs)
App makes request from employee's device which happens to be on corporate Wi-Fi/VPN
Attacker never had device access they just tricked the employee into using a malicious URL

So the employee's device becomes the proxy. On framework responsibility, you're right that input validation requirements vary. Maybe instead of mandatory blocking, it could be optional? Like a config flag or a validation hook that apps can enable? That way apps that need strict URL validation can use it, but it doesn't impose requirements on everyone.

I get that this might not be worth the complexity though. If you think apps should handle their own URL validation based on their specific needs, that's totally reasonable. Just wanted to clarify the attack vector since it doesn't require device access.

[sockeye-d]

Yes, but the Valdi app in this case must be one the hacker controls? Otherwise they can't leak the data out of the request, and it just stays in the app.

[retrymp3]

If the attacker doesn't control the app, they can't see the response. So this would be "blind SSRF" where the attacker can make requests but can't read responses.

Even without seeing responses, blind SSRF can be used to do things like, port scanning internal services (timing differences can be used to figure out open and closed ports), triggering actions on internal APIs(based on how the app works), Service enumeration can be done (based on error codes).

This is much less severe than traditional server side SSRF where the attacker can read responses. For data exfiltration, the app would need to leak the response somehow (display errors, log responses, etc.), which most well built apps wouldn't do.