Cross-Site Request Forgery and Server-Side Request Forgery​

Cross-Site Request Forgery and Server-Side Request Forgery attacks have similar names, and both take advantage of how servers process URLs. But these attacks have very different impacts. Understanding the difference between them is an important part of VAPT for web applications.

What is Cross-Site request forgery (CSRF)

Cross-Site Request Forgery is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering, an attacker may trick the users of a web application into executing actions of the attacker’s choosing.

Cross-Site Request Forgery vulnerabilities have been featured on the OWASP Top Ten List for web applications until the most recent version. The reason for dropping them from the 2017 edition was that many web application frameworks contain CSRF protections; however, they are still present in 5% of web applications at the time of release.

An attacker exploits a CSRF vulnerability when a user visits a website designed to force secondary requests to a certain site. For example, the website may include an image or iframe which claims that it needs to be fetched from a certain webpage on the target site. When the user’s browser tries to fetch the content, it makes a state-changing request on the target site and resets a password or performs a financial transaction.

Server-side request forgery (SSRF)

Server-Side Request Forgery attacks are designed to exploit how a server processes external information. Some web applications may be designed to read information from or write information to a particular URL (like a REST API). If an attacker can modify the target URL, they can potentially exfiltrate sensitive information from the application or inject untrusted input into it.

The vulnerabilities associated with SSRF vulnerabilities are not limited to data exfiltration. In some cases, applications may be designed to read data from a particular URL. If this URL is trusted, the application may not be performing data validation. This could allow an attacker to provide malicious input that could exploit a buffer overflow, integer overflow, SQL injection or other vulnerability in the application.

Differences between CSRF and SSRF

Attack target

Cross-Site Request Forgery and Server-Side Request Forgery both exploit the webserver. However, only SSRF exploits are actually designed to attack the target.

The target of a CSRF attack is the user. While it is accomplished using flaws in how the web application is designed, its purpose is to perform legitimate but unauthorized actions on the user’s account with the web-based service.

SSRF forgery, on the other hand, is designed to primarily target the server. While, in the long run, the attack may affect users of the service, the primary purpose of the attack is theft of sensitive information on the server or exploiting other vulnerabilities by using SSRF to bypass input validation countermeasures.

Attack purpose

Cross-Site Request Forgery and Server-Side Request Forgery also differ in the purpose of the attack. In the case of SSRF, the primary purpose of the attack is to gain access to sensitive data. This could be performed directly (by forcing it to write data to an attacker-supplied URL) or indirectly (by allowing exploitation of a vulnerability that can be used to steal data).

CSRF vulnerabilities, on the other hand, do not provide an attacker with any access to sensitive data. While the attacker forces a user’s browser to visit the target site, the actual request and response are performed independently. Even if the attack results in sensitive data being sent in response to the malicious request, this data only goes to the target user’s computer, not the attackers. The purpose of exploiting a CSRF vulnerability is to force the target user to take action in the attacker’s interest, like changing an account password to one known to the attacker.

Conclusion: Detecting CSRF and SSRF vulnerabilities

While CSRF and SSRF vulnerabilities are very different, they are both enabled by the same problem: a failure to properly use URLs by the server. When looking for potential vulnerabilities in a web application, examining how the application uses URLs and the types, formats and destinations of requests made to or by it can help in identification of these vulnerabilities.