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.
Extended Description
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.
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.
Likelihood of Exploit
Medium to High
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 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.
Effectiveness: High
These may be more effective than strictly automated techniques. This
is especially the case with weaknesses that are related to design and
business rules.
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.
Effectiveness: Limited
Automated Static Analysis - Binary / Bytecode
According to SOAR, the following detection techniques may be
useful:
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.
echo "Your profile has been successfully updated.";
}
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.
web interface allows password changes or stopping
a virtual machine via CSRF
Potential Mitigations
Phase: Architecture and Design
Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to
occur or provides constructs that make this weakness easier to
avoid.
For example, use anti-CSRF packages such as the OWASP CSRFGuard. [R.352.3]
Another example is the ESAPI Session Management control, which includes a component for CSRF. [R.352.9]
Phase: 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.
Phase: 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). [R.352.5]
Note that this can be bypassed using XSS (CWE-79).
Phase: 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.
Note that this can be bypassed using XSS (CWE-79).
Phase: 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. [R.352.4]
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
Do not use the GET method for any request that triggers a state
change.
Phase: 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.
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.
[R.352.1] [REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 2: Web-Server Related Vulnerabilities (XSS, XSRF, and
Response Splitting)." Page 37. McGraw-Hill. 2010.
More information is available — Please select a different filter.
Page Last Updated:
January 18, 2017
Use of the Common Weakness Enumeration and the associated references from this website are subject to the
Terms of Use. For more information, please email
[email protected].
Description
