| Name |
Cross Site Request Forgery |
|
| Likelyhood of attack |
Typical severity |
| High |
Very High |
|
| Summary |
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie. |
| Prerequisites |
|
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
[Explore target website] The attacker first explores the target website to determine pieces of functionality that are of interest to them (e.g. money transfers). The attacker will need a legitimate user account on the target website. It would help to have two accounts. |
- Use web application debugging tool such as WebScarab, Tamper Data or TamperIE to analyze the information exchanged between the client and the server
- Use network sniffing tool such as Wireshark to analyze the information exchanged between the client and the server
- View HTML source of web pages that contain links or buttons that perform actions of interest.
|
| 2 |
Experiment |
[Create a link that when clicked on, will execute the interesting functionality.] The attacker needs to create a link that will execute some interesting functionality such as transfer money, change a password, etc. |
- Create a GET request containing all required parameters (e.g. https://www.somebank.com/members/transfer.asp?to=012345678901&amt=10000)
- Create a form that will submit a POST request (e.g. <form method="POST" action="https://www.somebank.com/members/transfer.asp"><input type="hidden" Name="to" value="012345678901"/><input type="hidden" Name="amt" value="10000"/><input type="submit" src="clickhere.jpg"/></form>
|
| 3 |
Exploit |
[Convince user to click on link] Finally, the attacker needs to convince a user that is logged into the target website to click on a link to execute the CSRF attack. |
- Execute a phishing attack and send the user an e-mail convincing them to click on a link.
- Execute a stored XSS attack on a website to permanently embed the malicious link into the website.
- Execute a stored XSS attack on a website where an XMLHTTPRequest object will automatically execute the attack as soon as a user visits the page. This removes the step of convincing a user to click on a link.
- Include the malicious link on the attackers' own website where the user may have to click on the link, or where an XMLHTTPRequest object may automatically execute the attack when a user visits the site.
|
|
| Solutions | Use cryptographic tokens to associate a request with a specific action. The token can be regenerated at every request so that if a request with an invalid token is encountered, it can be reliably discarded. The token is considered invalid if it arrived with a request other than the action it was supposed to be associated with. Although less reliable, the use of the optional HTTP Referrer header can also be used to determine whether an incoming request was actually one that the user is authorized for, in the current context. Additionally, the user can also be prompted to confirm an action every time an action concerning potentially sensitive data is invoked. This way, even if the attacker manages to get the user to click on a malicious link and request the desired action, the user has a chance to recover by denying confirmation. This solution is also implicitly tied to using a second factor of authentication before performing such actions. In general, every request must be checked for the appropriate authentication token as well as authorization in the current session context. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-306 |
Missing Authentication for Critical Function |
| CWE-352 |
Cross-Site Request Forgery (CSRF) |
| CWE-664 |
Improper Control of a Resource Through its Lifetime |
| CWE-716 |
OWASP Top Ten 2007 Category A5 - Cross Site Request Forgery (CSRF) |
| CWE-732 |
Incorrect Permission Assignment for Critical Resource |
| CWE-1275 |
Sensitive Cookie with Improper SameSite Attribute |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-21 |
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service. Attacks leveraging trusted identifiers typically result in the adversary laterally moving within the local network, since users are often allowed to authenticate to systems/applications within the network using the same identifier. This allows the adversary to obtain sensitive data, download/install malware on the system, pose as a legitimate user for social engineering purposes, and more.
Attacks on trusted identifiers take advantage of the fact that some software accepts user input without verifying its authenticity. Many server side processes are vulnerable to these attacks because the server to server communications have not been analyzed from a security perspective or the processes "trust" other systems because they are behind a firewall. Similarly, servers that use easy to guess or spoofable schemes for representing digital identity can also be vulnerable. Such systems frequently use schemes without cryptography and digital signatures (or with broken cryptography). Identifiers may be guessed or obtained due to insufficient randomness, poor protection (passed/stored in the clear), lack of integrity (unsigned), or improper correlation with access control policy enforcement points. Exposed configuration and properties files that contain sensitive data may additionally provide an adversary with the information needed to obtain these identifiers. An adversary may also "ride" an identifier via a malicious link, as is the case in Cross Site Request Forgery (CSRF) attacks.
Regardless of the attack vector, successful spoofing and impersonation of trusted credentials can lead to an adversary breaking authentication, authorization, and audit controls with the target system or application. |
|
| Taxonomy: WASC |
|
Entry ID
|
Entry Name
|
| 09 |
Cross-Site Request Forgery |
|
| Taxonomy: OWASP Attacks |
|
Entry ID
|
Entry Name
|
| Link |
Cross Site Request Forgery (CSRF) |
|