Description
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Related Weaknesses
CWE-345
CWE-345
CWE-346
CWE-441
CWE-642
CWE-613
Consequences
Confidentiality, Integrity, Availability, Non-Repudiation, Access Control: Gain Privileges or Assume Identity, Bypass Protection Mechanism, Read Application Data, Modify Application Data, DoS: Crash, Exit, or Restart
The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application – deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product’s users. Because the attacker has the identity of the victim, the scope of CSRF is limited only by the victim’s privileges.
Potential Mitigations
Phase: Architecture and Design
Description:
Phase: Implementation
Description:
Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.
Phase: Architecture and Design
Description:
Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]
Note that this can be bypassed using XSS (CWE-79).
Phase: Architecture and Design
Description:
Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.
Note that this can be bypassed using XSS (CWE-79).
Phase: Architecture and Design
Description:
Note that this can probably be bypassed using XSS (CWE-79), or when using web technologies that enable the attacker to read raw headers from HTTP requests.
Phase: Architecture and Design
Description:
Do not use the GET method for any request that triggers a state change.
Phase: Implementation
Description:
Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.
Note that this can be bypassed using XSS (CWE-79). An attacker could use XSS to generate a spoofed Referer, or to generate a malicious request from a page whose Referer would be allowed.
CVE References
- CVE-2004-1703
- Add user accounts via a URL in an img tag
- CVE-2004-1995
- Add user accounts via a URL in an img tag
- CVE-2004-1967
- Arbitrary code execution by specifying the code in a crafted img tag or URL
- CVE-2004-1842
- Gain administrative privileges via a URL in an img tag
- CVE-2005-1947
- Delete a victim’s information via a URL or an img tag
- CVE-2005-2059
- Change another user’s settings via a URL or an img tag
- CVE-2005-1674
- Perform actions as administrator via a URL or an img tag
- CVE-2009-3520
- modify password for the administrator
- CVE-2009-3022
- CMS allows modification of configuration via CSRF attack against the administrator
- CVE-2009-3759
- web interface allows password changes or stopping a virtual machine via CSRF