Live Active security incident? Get immediate response
CWE Reference

CWE-352: Cross-Site Request Forgery (CSRF)

Official CWE-352 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.

Release 4.20weaknessStable
Search CWE CWE Dictionary

Glexia's Take

CWE-352: Session Riding

Cross-Site Request Forgery (CSRF) represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.

Executive Impact

  • 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 trick a client into making an unintentional request to the web server via a URL, image load, XMLHttpRequest, etc., which would then be treated as an authentic request from the client - effectively performing any operations as the victim, leading to an exposure of data, unintended code execution, etc. 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.

Developer Pattern

CWE-352 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.

Confidence

high confidence from CWE-352, 4.20.

Official CWE Definition

CWE-352: Cross-Site Request Forgery (CSRF)

The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.

Type
weakness
Abstraction
Compound
Status
Stable
Source
MITRE CWE definition

Developer And Remediation Guidance

How teams prevent and detect this weakness

Causes

  • This example PHP code attempts to secure the form submission process by validating that the user submitting the form has a valid session. A CSRF attack would not be prevented by this countermeasure because the attacker forges a request through the user's web browser in which a valid session already exists. The following HTML is intended to allow a user to update a profile.,profile.php contains the following code.,This code may look protected since it checks for a valid session. However, CSRF attacks can be staged from virtually any tag or HTML construct, including image tags, links, embed or object tags, or other attributes that load background images.,The attacker can then host code that will silently change the username and email address of any user that visits the page while remaining logged in to the target web application. The code might be an innocent-looking web page such as:,Notice how the form contains hidden fields, so when it is loaded into the browser, the user will not notice it. Because SendAttack() is defined in the body's onload attribute, it will be automatically called when the victim loads the web page.,Assuming that the user is already logged in to victim.example.com, profile.php will see that a valid user session has been established, then update the email address to the attacker's own address. At this stage, the user's identity has been compromised, and messages sent through this profile could be sent to the attacker's address.

Remediation

  • Architecture and Design: [object Object]
  • Implementation: Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.
  • Architecture and Design: 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]
  • Architecture and Design: 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.
  • Architecture and Design: Do not use the GET method for any request that triggers a state change.
  • Implementation: 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.

Detection

  • Manual Analysis: [object Object]
  • Automated Static Analysis: CSRF is currently difficult to detect reliably using automated techniques. This is because each application has its own implicit security policy that dictates which requests can be influenced by an outsider and automatically performed on behalf of a user, versus which requests require strong confidence that the user intends to make the request. For example, a keyword search of the public portion of a web site is typically expected to be encoded within a link that can be launched automatically when the user clicks on the link.
  • Automated Static Analysis - Binary or Bytecode: [object Object]
  • Manual Static Analysis - Binary or Bytecode: [object Object]
  • Dynamic Analysis with Automated Results Interpretation: [object Object]
  • Dynamic Analysis with Manual Results Interpretation: [object Object]
  • Manual Static Analysis - Source Code: [object Object]
  • Automated Static Analysis - Source Code: [object Object]

Mappings

Related CVEs, CWEs, and ATT&CK context

Related CWEs

Related CVEs

Related CVE mappings appear after CVE records are cross-indexed.

Open CWE CVE mapping

ATT&CK Relevance

ATT&CK relevance is shown only when reviewed or responsibly inferred.