What is Cross-Site Request Forgery (CSRF)?

Cross-site request forgery (CSRF) is a common web security vulnerability. It’s also known as XSRF, “Sea Surf”, Session Riding, Cross-Site Reference Forgery, and Hostile Linking. It happens when an attacker tricks the browser of an authenticated user to perform malicious actions on a website unintentionally. The attack's impact can be limited or vast, depending on the user’s permissions.  

CSRF previously appeared on the list of the top 10 web application security risks from the Open Web Application Security Project (OWASP) in 2013, although it’s been dropped from the most recent release in 2017. 

How Does a CSRF Attack Work?

Two things must happen to execute a CSRF attack: 

1. The attacker tricks an authenticate or logged in user into clicking a link or loading a page, such as through social engineering like a phishing attack. When the user clicks the link, the script injected by the attacker runs.
2. The attacker sends a legitimate-looking HTTP request from the user’s browser. The website processes the request without distinguishing whether the request is sent by the actual user or the CSRF attacker.

Typically, the HTTP request sent by the user’s browser contains credentials linked with the website, like the user’s session cookies and IP address. A session cookie contains authentication data and represents the user’s session. With session cookies, the user won’t have to undergo repeated authentication steps for every visited page. 

The CSRF attacker could exploit the session cookie, impersonate the user, and send a forged request to perform malicious actions. As long as the session cookie is approved by the site, and the session is active, the site won’t distinguish whether the incoming requests are coming from the legitimate user or CSRF attacker. 

Websites which use session cookies (like those of banks, financial organizations, and e-commerce sites) are, therefore, vulnerable to CSRF attacks. However, since CSRF requires the user to be authenticated and logged in, online contents that do not require authentication (like public pages) are safe and unaffected. 

The Dangers of Cross-Site Request Forgery

CSRF attacks have been used to perform a number of malicious actions, like stealing data, changing passwords and other login credentials, spreading worms or malware, transferring funds, or making a purchase with the user’s credentials.

However, the impact of a CSRF attack would largely depend on the privileges of the compromised user. For instance, if the victim holds an administrator account, a CSRF attack could jeopardize the entire web application. 

How to Prevent a CSRF Attack

Many financial transactions happen online, so expect CSRF attacks to thrive. The proliferation of social networking platforms also contributes to the spread of scripts which trigger CSRF attacks. 

Many websites now have controls in place against CSRF attacks, but users shouldn’t assume every website they visit is safe. Here are some tips from a Network World’s op-ed which users can apply for cross-site request forgery prevention.

• Avoid opening suspicious emails, visiting shady sites, or performing social network communication while authenticated to a banking website. 
• Ensure your antivirus is up to date. 
• Don’t save passwords and other login credentials in the browser. 
• Disable scripting in your browser. Firefox has a plug-in for such a purpose, so consider using Firefox.
• Run online banking or financial transactions in one browser, then do other browsing activities in another browser.
• Log off entirely from a website immediately after a session.

As session cookies are automatically sent per request, attackers are fond of using them to make their attacks and execute malicious actions with the user’s privileges. For companies that maintain a website, these methods for CSRF mitigation should be useful:

• Use a CSRF token that’s not accessible to attackers and not sent along with forged requests. Banks can switch from session cookies to dynamically generated session tokens, making it more difficult for attackers to get a hold of a user’s session.
• Use a combination of CSRF token implementation and user-interaction-based defense (like re-authentication or a one-time token). This is recommended for highly sensitive operations. 

Fortunately, it’s possible to check whether your website or web app is vulnerable to CSRF attacks and to have a potential CSRF thwarted. One means to accomplish that is to set up continuous monitoring with web application vulnerability scanning so you can fix cybersecurity vulnerabilities before attackers exploit them. 

Zeguro’s monitoring report, for example, can detect not only CSRF attacks but also other web application security vulnerabilities. By identifying and patching security vulnerabilities in your web apps on a routine basis, you’ll reduce the risk of a web-based attack, enhancing your company’s security posture while also helping you fulfill the security requirements in compliance frameworks such as SOC 2, HIPAA, and PCI-DSS.