Read Time:3 Minute, 7 Second

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-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-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