Cross-Site Request Forgery, often abbreviated as CSRF, is a possible attack that can occur when a malicious website, blog, email message, instant message, or web application causes a user’s web browser to perform an undesired action on a trusted site at which the user is currently authenticated. The impact of a CSRF attack is determined by the capabilities exposed within the vulnerable application. CSRF attacks are, on the most basic level, used by an attacker to make a target system perform any available and malicious function via the target's browser without knowledge of the target user. This function usually is not known by the victim until after it has occurred as well.
A CSRF vulnerability can give an attacker the ability to force an authenticated, logged-in user to perform an important action without their consent or knowledge. It is the digital equivalent to someone forging the signature of a victim on an important document. It is in fact more effective, because the attacker leaves no trace of evidence behind. This is because the forged request contains all of the information and comes from the same IP address as a real request from the victim. This means that any application that allows a user to send or update data is a possible target for an attacker.
One important thing to remember is that for CSRF to work, the victim has to be logged in the targeted site. While this may feel like an impedance to the attacker, many websites let the user choose to “keep me logged in”. This greatly increases the size of the timeframe in which a forgery can be made.
The most common goal of a CSRF is theft—either data theft, identity theft, or financial theft. Some common uses of CSRF include:
- Transfer money from one bank account to another. Your online session at your bank becomes compromised, and treats this like a legitimate request and sends $1000 from your account to Mallory’s account. All evidence suggests you legitimately made this transaction from your logged-in browser.
- Use a content management system to add/delete content from a website. If the victim is an administrative user, the entire website would be under the attacker’s control.
- Change a user’s password. If a victim is logged into their account, the attacker can simply forge a request for an email change. Once this goes through, If the attacker can forge a password reset request, the attacker could subsequently gain full control of the victim’s account.
- Add items to a user’s shopping basket or change the delivery address of an order. Many websites have a “my account” page or other similar pages that stores a user's information, and often allows a user to change their address or adjust their shopping cart. With CSRF, an attacker can adjust this information, and to the website, it will look as if the victim was the originator of all changes.
There are two main methods by which Cross-site Request Forgery may be prevented.
- Stopping the browser from sending third-party cookies to the web application.
- Synchronizing the cookie with an anti-CSRF token that was already provided to the browser.
- Requiring a “challenge response,” which is often used in conjunction with the other two available prevention techniques.
Technique #1. Same-Site Cookies
The Same-Site Cookie attribute is a newly developed attribute that can be set on cookies to instruct the browser to disable third-party usage for specific cookies. This attribute is set by the server while at the same time setting the cookie itself, and requests the browser to only send the cookie in a first-party context. Because of this, the request has to originate from the same location. Therefore, requests made by third-party sites can not include the same-site Cookie. This effectively eliminates CSRF without requiring the use of synchronizer tokens. The only downside is that Same-Site Cookies are only available in some modern browsers.
Technique #2. Anti-CSRF Tokens
The recommended and most widely adopted prevention method for Cross-site Request Forgery is an anti-CSRF token, otherwise known as a synchronizer token. When a user submits information or interacts with the site, or does anything else that generates a cookie, the anti-CSRF token should also be included with the cookie request. This request then gets run through a verification process, wherein the authenticity or even existence of this token is verified before processing the request. If the token is missing or incorrect, the request can be rejected.
To insure quality of protection with Anti-CSRF tokens, it is essential that the library of known tokens is regularly updated to match existing threats. Many of these libraries are open source and easily accessed. In a perfect world, both methods would be combined to help defend against a CSRF attack.
Technique #3. Challenge Response
As an additional layer of protection, you can require a challenge response from a user when a form is submitted. Some examples of challenge responses include:
- Re-Authentication of Password or Personal Information
- CAPTCHA validation
- Issue a one-time token
While challenge-response can be an effective deterrent against CSRF when designed and implemented accordingly, it does have an impact on user experience. For applications in need of high security, both tokens and challenge-response should be used to ensure security.
CSRF attacks can be used on a huge array of sites. If a site allows data to be altered on the user side, then it is a potential target for an attacker. With some of the fixes listed, above, your website can guarantee a much higher level of security. on a wide-range of sites. Any site where data can be altered is a potential target.
The Impact of a successful CSRF attack can vary greatly depending on the privileges of the victim. If the target is a basic user, everything from their personal information to site privileges can be compromised. While that sounds bad, if an administrator account is compromised, an attack can cripple the entire site. This shows the scale of a possible attack and why CSRF protection is an essential part of any web security package.
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
- Wikipedia: Cross-Site Request Forgery
- Blog: How to Prevent Clickjacking Attacks
How Barracuda Can Help
The Barracuda Web Application Firewall automatically protects your website and we applications from CSRF attacks along with thousands of other cyber-threats including OWASP Top 10 threats. If you do not yet have a web application firewall, you can request a free trial from Barracuda. You can also use the Barracuda Vulnerability Manager to do a free scan of your website to check if it vulnerable to a CSRF attack.
In addition to providing firewall-based protection, Barracuda also offers CSRF protection in our Barracuda Load Balancer ADC product. The load balancer is a secure Application Delivery Controller designed to ensure website availability, acceleration, and control. Automatic updates ensure comprehensive security for existing and emerging Layer 7 threats such as Cross-site Scripting, SQL injections, and Cross-site Request Forgery.
Do you have more questions about Cross Site Request Forgery? Contact us today.