“Server Side Request Forgery” (a.k.a. SSRF) is a class of web-application vulnerability in which an attacker can cause a website to access unintended server-side resources, including the unauthorized reading, writing, or execution of server resources.
Web-applications designed to pass URLs (references to server accessible content) or portions thereof, from the client browser to the application server using HTTP request parameters or HTTP request headers, are at risk for Server Side Request Forgery exploitation unless they protect against it.
Server-side Request Forgery (SSRF) is related to another type of vulnerability called Open Redirects in the sense that they both rely on untrusted input to reference other web-resources.
Server-Side Request Forgery Example
Consider a web-application at which user choices are reflected in subsequent queries to back-end systems by the web-server. For example, a health insurance provider’s website might allow subscribers to search for doctors, patient history, or schedule appointments through various separate and distinct back-end services. Let’s assume that out web-application is running in the DMZ and the service applications are internal. Let’s further suppose that the design involves passing two parameters from the client to the web-server:
- target: The domain name of an internal system that will service a type of client query
- qstring: The parameter string that will be appended to the target to form a full URL that will be submitted to the target system
Thus, a properly formed query to our web-server might resemble the following:
/processRequest?target=scheduling&qstring=pid=1234%26op=read%26date_range=….. (truncated for brevity)
that would request the patient’s appointment or test schedule for the given data range.
Next, consider a scenario in which an attacker submits a malicious URL that exploits services not intended for exposure through the website:
/processRequest?target=scheduling&qstring=pid=1234%26op=delete%26date_range=….. (truncated for brevity)
that deletes the patients appointments for the indicated date range.
To summarize, the web-application has been fooled into making illicit requests to back-end services.
For additional insight into how to test for Server-side Request Forgery, please see the article entitled: “How to Test For Server-Side Request Forgery“.
For additional insight into how to prevent or fix Server-side Request Forgery, please see the article entitled: “How To Prevent Server-side Request Forgery“.
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.