Hello, my red team just did an engagement against Splunk and among their findings is a SSRF vulnerability and so far, my research has come up empty as to whether anyone has seen this before or how it might be remediated. It came from the Burp Suite. Here are the pertinent results. I'm wondering if there is any generally accepted remediation or if it's more of a "by design" thing: 1. Out-of-band resource load (HTTP) There are 3 instances of this issue: / / / Issue background Out-of-band resource load arises when it is possible to induce an application to fetch content from an arbitrary external location, and incorporate that content into the application's own response(s). The ability to trigger arbitrary out-of-band resource load does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. However, in many cases, it can indicate a vulnerability with serious consequences. The ability to request and retrieve web content from other systems can allow the application server to be used as a two-way attack proxy. By submitting suitable payloads, an attacker can cause the application server to attack, or retrieve content from, other systems that it can interact with. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers. Additionally, the application's processing of web content that is retrieved from arbitrary URLs exposes some important and non-conventional attack surface. An attacker can deploy a web server that returns malicious content, and then induce the application to retrieve and process that content. This processing might give rise to the types of input-based vulnerabilities that are normally found when unexpected input is submitted directly in requests to the application. The out-of-band attack surface that the application exposes should be thoroughly tested for these types of vulnerabilities. Issue remediation You should review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary out-of-band resource load is intended behavior. If so, you should be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter. You should also ensure that content retrieved from other systems is processed in a safe manner, with the usual precautions that are applicable when processing input from direct incoming web requests. If the ability to trigger arbitrary out-of-band resource load is not intended behavior, then you should implement a whitelist of permitted URLs, and block requests to URLs that do not appear on this whitelist. References Burp Collaborator Vulnerability classifications CWE-610: Externally Controlled Reference to a Resource in Another Sphere CWE-918: Server-Side Request Forgery (SSRF) 1.1. https://127.0.0.1:8010/ Summary Severity: High Confidence: Certain Host: https://127.0.0.1:8010 Path: / Issue detail It is possible to induce the application to retrieve the contents of an arbitrary external URL and return those contents in its own response. The payload 4nsdulwsu383t3t64q9vmw0df4lz9qxjw7muci1.burpcollaborator.net was submitted in the SSL SNI value and the HTTP Host header. The application performed an HTTP request to the specified domain. The response from that request was then included in the application's own response. Request GET / HTTP/1.1 Host: 4nsdulwsu383t3t64q9vmw0df4lz9qxjw7muci1.burpcollaborator.net Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close Response HTTP/1.1 200 OK Server: Burp Collaborator https://burpcollaborator.net/ X-Collaborator-Version: 4 Content-Type: text/html Content-Length: 62 <html><body>1z0uzq36sdssv3cxx5t697zjngjglrgifigz</body></html> 1.2. https://127.0.0.1:8010/ Summary Severity: High Confidence: Certain Host: https://127.0.0.1:8010 Path: / Issue detail It is possible to induce the application to retrieve the contents of an arbitrary external URL and return those contents in its own response. The payload snj1u9wgur8rtrtu4e9jmk01fsln9ex7nvdi36s.burpcollaborator.net was submitted in the HTTP Host header. The application performed an HTTP request to the specified domain. The response from that request was then included in the application's own response. Request GET / HTTP/1.1 Host: 127.0.0.1:8010@snj1u9wgur8rtrtu4e9jmk01fsln9ex7nvdi36s.burpcollaborator.net Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close Response HTTP/1.1 200 OK Server: Burp Collaborator https://burpcollaborator.net/ X-Collaborator-Version: 4 Content-Type: text/html Content-Length: 62 <html><body>1z0uzq36sdssv3cxx5t697zjngjgligifigz</body></html> 1.3. https://127.0.0.1:8010/ Summary Severity: High Confidence: Certain Host: https://127.0.0.1:8010 Path: / Issue detail It is possible to induce the application to retrieve the contents of an arbitrary external URL and return those contents in its own response. The payload skg1r9tgrr5rqrqu1e6jjkx1csin6eu6wumhc51.burpcollaborator.net was submitted in the HTTP Host header. The application performed an HTTP request to the specified domain. The response from that request was then included in the application's own response. Request GET / HTTP/1.1 Host: skg1r9tgrr5rqrqu1e6jjkx1csin6eu6wumhc51.burpcollaborator.net Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close Response HTTP/1.1 200 OK Server: Burp Collaborator https://burpcollaborator.net/ X-Collaborator-Version: 4 Content-Type: text/html Content-Length: 62 <html><body>1z0uzq36sdssv3cxx5t697zjngjgkugifigz</body></html> ... View more