This document provides information about Cross-Site Request Forgery (CSRF) attacks and potential methods of mitigation.
Cross-Site Request Forgery (CSRF) attacks typically target web applications. CSRF attacks can include unauthorized changes of user information or extraction of user sensitive data from a web application.
CSRF exploits utilize social engineering to convince a user to open a link that, when processed by the affected web application, could result in arbitrary code execution. CSRF exploit code can be stored in a web location (for example, a stored CSRF) in a one-pixel iframe/image or can be a component of a CSRF exploit. When processed, the CSRF link could allow the attacker to submit arbitrary requests via the affected web application with the privileges of the user. The origins of CSRF attacks are difficult to identify utilizing traceback methods. Social engineering methods can conceal the attacker's identity because the server is treating the request as a legitimate request from the user.
Examples of CSRF attacks are numerous but the most common involves a bank account transfer. For example, assume the human resources department of company X is leveraging a web portal that updates the salary information of the company’s employees. To execute that process, the human resources department needs to complete the following: authenticate to the web application, proceed to the raise salary area of the portal, and complete a form with the name of the employee and the amount of the raise. Once the preceding steps are completed, the user is required to press the submit button to process the form and complete the change. Assume the submitted form was for an employee named John Doe who was given a raise of US$100 dollars, this will generate the following HTTP POST request:
POST http://hr.companyX-internal.com/raisesalary.do HTTP/1.1
Depending on the application, a case could exist where the browser already has a valid authenticated session (browser cookie). If the human resources web application has a valid authentication session, then same action (for example, salary raise) will be executed with the following HTTP GET request:
GET http://hr.companyX-internal.com/raisesalary.do?usr=JohnDoe&amount=100 HTTP/1.1
The above request can be made by visiting a link and executing an HTTP GET request. The browser does not require a form submission.
The human resources web application, described in the above example, is susceptible to CSRF attacks. A user (for example, John Doe) could attempt to increase his salary by US$500 dollars without having access to the application, but could convince an employee in the human resources department to open a link or load an HTTP iframe that is redirected to a malicious link (for example, http://hr.companyX-internal.com/raisesalary.do?usr=JohnDoe&amount=500). Once the employee has been authenticated by the human resources application (for example, mid-day), the only requirement is to persuade the human resources employee to visit the link.
Mitigation Technique Overview
User Education and Security Awareness Training
To reduce the risk of CSRF attacks, it is advised to discuss safe browsing techniques. Attackers use web-based e-mail as an CSRF vector, either through embedded scripting or malicious links that result in CSRF exploitation. A baseline strategy should consist of the following:
Users are advised not to open e-mail messages from suspicious or unrecognized sources. If users cannot verify that links included in e-mail messages are safe, they are advised not to open them.
Users are encouraged to hover the mouse over the link to observe where the link is directed before clicking/selecting the link.
Check links for use of suspicious-looking characters.
It is recommended to maintain two different browsers. One should serve as a trusted sites browser and the other for casual web surfing. When a link contained in an email or from a social networking website is selected, the browser used for casual web surfing should be used to ensure that no valid cookies exist for an CSRF based attack.
Users should be cautious of links that require a login to authenticate. (for example, banks or the human resources website described in the above example)
Be suspicious of excessively long links.
Access only websites that are from known and trusted locations. If the user has concerns, contact the webmaster and the company hosting the website immediately.
Delete unsolicited e-mail messages or read them in plain text format to prevent the execution of malicious code.
Safe Web Application Development Practices
Utilizing safe design and development practices when designing web applications reduces the risk of creating applications that could be susceptible to CSRF attacks. Some safe design and development practices include:
For each user session or request, append unpredictable challenge tokens. This method ensures that each request is verified that the user is the source and not an CSRF link.
When possible, check if a request was issued by the site itself or from a cross-site request by checking the HTTP referrer header.
Use custom HTTP headers. For example, the Google Web Toolkit recommends attaching an X-CSRF-Cookie header to XMLHttpRequets which can provide protection against CSRF attacks.
Due to the nature of the CSRF attacks, the identification of the intent of a specific URL (for example, a salary raise described in the above example) is difficult. As a result, the identification of a malicious request is not always possible between the user and the server. The best countermeasures to mitigate CSRF attacks are safe web application development practices and user education. Cisco security products (for example, Cisco Ironport Web Security Appliances, Cisco ACE Web Application Firewall) can provide some level of protection, primarily against objects that trigger malicious requests. In addition, some general protections against Cross-Site Scripting that validate HTTP cookies and HTTP referrer headers can act as mitigations against CSRF attacks.
Organizations are advised to follow their standard risk evaluation and mitigation processes to determine the potential impact of this vulnerability. Triage refers to sorting projects and prioritizing efforts that are most likely to be successful. Cisco has provided documents that can help organizations develop a risk-based triage capability for their information security teams. Risk Triage for Security Vulnerability Announcements and Risk Triage and Prototyping can help organizations develop repeatable security evaluation and response processes.
Caution: The effectiveness of any mitigation technique depends on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.
CSRF is not easily distinguishable from legitimate web requests, yet there are Cisco products can provide some level of protection against CSRF attacks.
Cisco IronPort Web Reputation Filters system includes botsite protection, URL outbreak detection and exploit filtering that protects users from exploits delivered through cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injections or invisible iFrames. The power behind the reputation technology is derived from the system’s pattern-base assessment techniques and per object scanning capabilities. For more information, please refer to the Cisco IronPort Web Reputation Technology website.
ACE Web Application Firewall policy can be used to protect systems against cross-site scripting and request forgery attacks by validating the cookie and referrer field in the HTTP header. For more information, please refer to the Cisco ACE Web Application Firewall Getting Started Guide.
Cisco Intrusion Prevention System (IPS) provides protection against CSRF attacks. The following list provides information concerning IPS signatures (Cisco IPS Signature Update version S704) that can be used against recent CSRF (March 2013) threats:
1398/0 - Microsoft Outlook Web Access Cross Site Request Forgery Vulnerability
1881/0 - D-Link DSL-2640B Redpass.Cgi Cross Site Request Forgery Vulnerability
1930/0 - WordPress Cross Site Request Forgery Vulnerability
THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.
The urgency and severity ratings of this alert are not tailored to individual users; users may value alerts differently based upon their network configurations and circumstances. THE ALERT, AND INFORMATION CONTAINED THEREIN, ARE PROVIDED ON AN "AS IS" BASIS AND DO NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE ALERT, AND INFORMATION CONTAINED THEREIN, OR MATERIALS LINKED FROM THE ALERT, IS AT YOUR OWN RISK. INFORMATION IN THIS ALERT AND ANY RELATED COMMUNICATIONS IS BASED ON OUR KNOWLEDGE AT THE TIME OF PUBLICATION AND IS SUBJECT TO CHANGE WITHOUT NOTICE. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE ALERTS AT ANY TIME.