CWE-352 Compound Stable Medium likelihood

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) happens when a web application cannot reliably tell if a user actually intended to submit a request, allowing an attacker to trick a user's browser into performing…

Definition

What is CWE-352?

Imagine you're logged into your bank's website in one tab. In another tab, you click a malicious link or visit a booby-trapped site. That malicious page can silently send a request to your bank's site—like a funds transfer—using your existing, logged-in session. Because your browser automatically includes your session cookies, the bank sees the request as legitimate and coming from you, even though you never intended to send it. To prevent this, applications must verify that state-changing requests (like logins, transfers, or profile updates) are deliberate. The most common and effective defense is to use anti-CSRF tokens: unique, secret values embedded in forms or requests that the server validates. Other protections include checking the `Origin` or `Referer` headers for same-origin requests, or requiring re-authentication for sensitive operations. Without these guards, attackers can exploit a user's trust in a site to perform actions without their consent.

Vulnerability Diagram CWE-352

Auswirkungen in der Praxis

Real-world CVEs caused by CWE-352

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

Wie Angreifer es ausnutzen

Angreiferpfad Schritt für Schritt

1
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.
2
The following HTML is intended to allow a user to update a profile.
3
profile.php contains the following code.
4
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.
5
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:

Verwundbares Codebeispiel

Vulnerable HTML

The following HTML is intended to allow a user to update a profile.

Verwundbar HTML

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

Angreifer-Payload

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:

Angreifer-Payload HTML

<SCRIPT>
  function SendAttack () {
  	form.email = "attacker@example.com";
```
// send to profile.php* 
  	form.submit();}
  </SCRIPT>
  
  <BODY onload="javascript:SendAttack();">
  
  <form action="http://victim.example.com/profile.php" id="form" method="post">
  <input type="hidden" name="firstname" value="Funny">
  <input type="hidden" name="lastname" value="Joke">
  <br/>
  <input type="hidden" name="email">
  </form>

Sicheres Codebeispiel

Secure pseudo

Sicher pseudo

// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}

What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.

Präventions-Checkliste

How to prevent CWE-352

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 Session Management control, which includes a component for CSRF. [REF-45]
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 Use the "double-submitted cookie" method as described by Felten and Zeller: When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult. This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]
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.

Erkennungssignale

How to detect CWE-352

Manual Analysis High

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 modify an active session. Specifically, manual analysis can be useful for finding this weakness, and for minimizing false positives assuming an understanding of business logic. However, it might not achieve desired code coverage within limited time constraints. For black-box analysis, if credentials are not known for privileged accounts, then the most security-critical portions of the application may not receive sufficient attention. Consider using OWASP CSRFTester to identify potential issues and aid in manual analysis.

Automated Static Analysis Limited

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

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis

Manual Static Analysis - Binary or Bytecode SOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Dynamic Analysis with Automated Results Interpretation High

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Web Application Scanner

Dynamic Analysis with Manual Results Interpretation High

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Fuzz Tester Framework-based Fuzzer

Plexicus Auto-Fix

Plexicus erkennt CWE-352 automatisch und öffnet in unter 60 Sekunden einen Fix-PR.

Codex Remedium scannt jeden Commit, identifiziert genau diese Schwachstelle und liefert einen reviewer-ready Pull Request mit dem Patch. Keine Tickets. Keine Hand-offs.

Demo anfordern Plexicus kostenlos testen

Häufig gestellte Fragen

Frequently asked questions

Was ist CWE-352?

Wie gravierend ist CWE-352?

MITRE stuft die Exploit-Wahrscheinlichkeit als mittel ein — eine Ausnutzung ist realistisch, erfordert aber meist bestimmte Bedingungen.

Welche Sprachen oder Plattformen sind von CWE-352 betroffen?

MITRE lists the following affected platforms: Web Server.

Wie kann ich CWE-352 verhindern?

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 Session Management control, which includes a component for CSRF. [REF-45] Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.

Wie erkennt und behebt Plexicus CWE-352?

Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-352 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.

Wo erfahre ich mehr über CWE-352?

MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/352.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.

Verwandte Schwachstellen

Weaknesses related to CWE-352

CWE-345 Parent

Insufficient Verification of Data Authenticity

This vulnerability occurs when an application fails to properly check where data comes from or confirm its legitimacy, allowing untrusted…

CWE-1293 Sibling

Missing Source Correlation of Multiple Independent Data

This vulnerability occurs when a system trusts a single source of data without verification, making it impossible to detect if that source…

CWE-346 Sibling

Origin Validation Error

This vulnerability occurs when an application fails to properly confirm the true origin of incoming data or communication, allowing…

CWE-347 Sibling

Improper Verification of Cryptographic Signature

This vulnerability occurs when an application fails to properly check the digital signature on data, or skips the verification step…

CWE-348 Sibling

Use of Less Trusted Source

This vulnerability occurs when a system has access to multiple sources for the same critical data, but it chooses to rely on the less…

CWE-349 Sibling

Acceptance of Extraneous Untrusted Data With Trusted Data

This vulnerability occurs when a system processes both trusted and untrusted data together, but fails to separate them. The application…

CWE-351 Sibling

Insufficient Type Distinction

This vulnerability occurs when an application fails to properly differentiate between different types of data or objects, leading to…

CWE-353 Sibling

Missing Support for Integrity Check

This vulnerability occurs when a system uses a communication protocol that lacks built-in integrity verification, such as a checksum or…

CWE-354 Sibling

Improper Validation of Integrity Check Value

This vulnerability occurs when software fails to properly check the integrity of data by validating its checksum or hash value. Without…

Ressourcen

Schluss mit dem Bezahlen pro Entwickler.
Schließ den Kreislauf.

Plexicus ist die KI-native ASPM, die scannt, filtert, fixt, pentestet und erklärt — autonom. Unbegrenzte Entwickler, unbegrenzte Repos, Fair-Use-KI-Aktionen. Echter kostenloser Tarif, €269/mo jährlich, wenn du bereit bist.

Kostenlos starten Demo buchen