Server-Side Request Forgery (SSRF) :
SSRF stands for the Server Side Request Forgery. SSRF is a server site attack that leads to sensitive information disclosure from the back-end server of the application. In server site request forgery attackers send malicious packets to any Internet-facing web server and this webserver sends packets to the back end server running on the internal network on behalf of the attacker. This vulnerability is mostly found in the application that has the facility to feed the URL for fetching data from the respective servers, also present in the application in which two or more servers from different hosts communicate with each other for information sharing.
Let’s explore the concept with help of an example :
In the above fig, you can observe that attacker sends Crafted Packet A to the publicly available server, and to fulfill the users query public server sends the request to the back end server with Packet B, as this request comes from the public server back end server would trust that Packet B coming from the internal network and accept the packet and send a response. This is possible because the attacker makes the request on behalf of other servers.
Types Of SSRF :
1. Blind SSRF:
In a Blind SSRF, attackers are not able to control the data of packet B that are sent to the application in a trusted internal network. Here attacker can control the IP address and ports of the server. To exploit this type of SSRF we have to feed the URL followed by the colon and port number, by observing responses and error messages from the server we can find the open and close ports of the server. We have tried this procedure for the different ports to check their status.
2. Limited Response / Partial SSRF :
In this type of SSRF, we get a limited response from the server like the title of the page or get access to resources but can’t see the data. We can control only certain parts of packet B that arrive at the internal application this type of vulnerability can be used to read local system files such as /etc/config, /etc/hosts, etc/passwd, and many others. By using the file:// protocol we can read files on the system. In some cases, XXE injection, DDos these types of vulnerability may useful be exploit Partial SSRF Vulnerability.
3. Full Response SSRF :
In Full SSRF we have complete control over Packet B (shown in fig). Now we can access the services running on the internal network and find the vulnerabilities in the internal network. In this type of SSRF we can use the protocols like file://, dict://, http://, gopher://, etc. here we have a large scope of creating different requests and exploiting the internal network if any vulnerabilities are present. Full SSRF vulnerability may cause the application to crash through a buffer overflow, by sending a large string in the request causes the buffer overflow.
Potential Blocks During Testing SSRF Vulnerability :
- Whitelisting: Server only allows a few domain names to be used in the request, the server has a white list of the domain if the domain name from that list matches with a domain name from the request then only accept the request otherwise server decline the request.
- Blacklisting:-Server discard all the request containing IP addresses, domain names, and keywords from the blacklist of the server.
- Restricted content:- Server allows to access the only a particular amount of files to the user, it allows only a few file extension types for public access.
Key Points To Test SSRF Vulnerability :
- Always make sure that you are making requests to back end server on the behalf of public server, not from the browser.
- To fetch the data from the server also try http://localhost/xyz/ with http://127.0.0.1/xyz.
- The server may have firewall protection always try to bypass the firewall if possible.
- Make sure that the request is coming from the server, not from your local host.
Share your thoughts in the comments
Please Login to comment...