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

Description:
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.

Affected languages: Not Language-Specific
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-345, CWE-345

Consequences:
  - Confidentiality: Gain Privileges or Assume Identity

Detection methods:
  - Manual Analysis: This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and m
  - 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 ou
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             

Mitigations:
  - [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. 
                   For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330] 
                   Another example is the ESAPI Sess
  - [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.

Demonstrative examples:
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.
<form action="/url/profile.php" method="post"> <input type="text" name="firstname"/> <input type="text" name="lastname"/> <br/> <input type="text" name="email"/> <input type="submit" name="submit" value="Update"/> </form>
// initiate the session in order to validate sessions 
                      session_start(); 
                      
                      //if the session is registered to a valid user then allow upda

Real-world examples:
  - 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