The difference between cross-site and server-side request forgery

October 16, 2019 by

Howard Poston

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

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

Cross-Site request forgery

Cross-Site Request Forgery (CSRF) 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 were still present in 5% of web applications at the time of release.

The purpose of CSRF attacks is to force a user to take undesired actions on their online account. Accomplishing this involves taking advantage of state-changing requests, where a web server will take some action based upon an authenticated user browsing to a particular page. Examples may include changing an account password or making a transaction via an online banking portal.

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.

CSRF attacks work because the user is already authenticated to the target site and the forced request includes the cookie containing session information. 

Standard CSRF attacks assume that a user is already authenticated to a site, but CSRF attacks can also be “stored.” For example, the malicious image or iframe may be an advertisement that digital ad networks occasionally place on the target site or part of a comment on the site’s forum. In these cases, the attacker guarantees that the user is authenticated to the site when they are viewing the malicious content.

Server-side request forgery

Server-Side Request Forgery (SSRF) 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 wide use of REST APIs mean that vulnerable applications could provide a great deal of sensitive information to an attacker. Examples of potentially vulnerable data include:

• Cloud configuration information: AWS includes a REST API from which configuration information and (sometimes) authentication keys can be read if an attacker can redirect the API target
• Databases: NoSQL databases like MongoDB are designed to include a REST API that an attacker can use to query the database if authentication is not enabled
• Files: Files stored on the server may be readable using file:// URIs

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.

The impact of an SSRF vulnerability can be significant. A recent example of an attack exploiting SSRF (and the difficulty of protecting against it) is the Capital One data breach, which exposed the personal information of 106 million people.

Differences between CSRF and SSRF

Both CSRF and SSRF vulnerabilities take advantage of how a web server handles URLs. However, the two types of vulnerabilities differ greatly in the target of the attack and its purpose.

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 attacker’s. 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.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

Sources

• OWASP Top 10 - 2017, OWASP
• Cross-Site Request Forgery (CSRF), OWASP
• Server Side Request Forgery, OWASP
• What We Can Learn from the Capital One Hack, Krebs on Security