Cross-Site Request Forgery, CSRF, XSRF, or session riding attacks, as it can be otherwise referred to are becoming an increasingly common type of attack. A CSRF attack forces users to carry out unwelcome attacks on websites and applications within which they are already authenticated. It does not seek to steal information. Instead, it is specifically targeted at state-changing requests.
We will explore some examples of cross-site request forgery attacks at a later point in this guide. Essentially, attackers will use this tactic to fool users of a specific site or application into executing particular actions that are chosen by themselves.
Victims of CSRF attacks may force users to perform a state-changing request such as changing an email address or other contact information, moving money or transferring funds. More worryingly for organizations, if an administrators account is compromised, this can cause the whole web application to become vulnerable and jeopardize matters on a far wider scale.
An Explanation of Cross-Site Request Forgery
Essentially, web applications and browsers will assume that requests which are made from a users browser belong to, and have come from the user. For instance, if a person clicks on any link within a webpage, the browser will initiate a request to a server that is usually classified in one of two ways.
GET and POST
A GET request is a demand for a page. Whereas, a POST request is submitted when you transmit information to the server.
So, if you type in www.techsolutions.cc, this will initiate a GET post. However, if you then search on the site for ‘Cross-Site Request Forgery Examples,’ this will then be transmitted as a POST request.
The intent of a Cross-Site Request Forgery is to send a specific request from someone’s browser without their explicit consent.
This is, in essence, what CSRFs are all about.
Why Do People Carry Out CSRF Attacks?
The motivations of CSRF attacks are either financially fuelled or intended to change key information within a user account or within an application or website.
For instance, in the examples of CSRF attacks that we are aware of, they have been used to carry out the below functions:
- Amend a user password or force a password reset
- Move money from a bank account
- Amend the delivery address for a purchase
- Utilise a Content Management System (CMS) to remove or add content to a website
- Upvote Answers, Follow or Like Social Media Accounts
- Exploitation of an administrative application
- Amend a content number or email on a user account
- Amend a cart or shopping basket online
- Alter firewall and router configurations
While in no means is this an exhaustive list, it gives you a general idea of the type of actions that can be initiated under a CSRF attack.
Cross-Site Request Forgery Risks Vs. Cross-Site Scripting
CSRF Vs. XSS
As with any type of attack of this nature, there are certain dangers that present themselves under a Cross-Site Forgery Attack. There are many other types of cross-site attacks, and while they are closely linked to Cross-Site Scripting, also referred to as XSS, they are distinctly different in their nature and in the risks posed.
There are plenty of Cross-Site attacks that result in content being posted on a public website which people read through a browser. For instance, if you consider a media news site which allows its users to be able to post comments in response to what they read, or any other review site, these are commonplace in today’s digital space. Not all of these sites will filter out content, and in doing so, they allow others to post data on their site, such as browser scripts, comments, and HTML.
In the case of an XSS attack, simply the act of reading content that is posted by an attack could trigger any number of actions on that site. This may include posting comments, placing bids, making purchases, and more. Essentially, XSS enhances scripts that are otherwise posted out as content. However, an XSRF attack is quite different.
Now, we shall explain how an XSRF attack works and how XSRF is different from XSS.
XSRF Examples
With online banking, companies will typically authenticate a user; then within the user’s browser, they will set-up a ‘session cookie’ in order to track them through a sequence of different transactions. If that user then opens another window within the same browser in order to access a media or bidding site (as an example), and that said site contains image tags which may reference a particular page or location on that banking site using HTML; when the users browser reads the image tag, it will first of all attempt to fetch the image in order to display this. However, and here’s the interesting part, when it attempts to fetch this, instead, it will initiate an HTTP request to the bank.
This HTTP code will request that the bank transmits a transfer between accounts for a set value using a function that is called transfer.php; this will, in effect move money from the user account into that of the hacker.
This is just a singular example, and it is dependant upon the bank actually having a PHP function that can be initiated in such a manner.
Attackers can post these requests on sites such as social media, media streaming, blogs, articles, news and media sites; almost anywhere that allows people to leave and post comments without mediation or approval.
Further Reading:
In this case, as far as the financial organization is concerned, this is a genuinely legitimate transaction as the cookie for the banking session is transmitted back with the HTTP request.
XSS is all about scripts in browsers, and XSRF focuses on URLs that are placed within content online. XSRF and XSS attacks are as dangerous as one another.
Testing for CSRF Vulnerabilities
Thankfully, the detection of XSRF flaws can be prevented relatively easily, as long as you are aware of what to look out for. This is also covered in this Guide to CSRF.
With the correct use of source code analysis and CSRF tokens, there is hope for the complete eradication of CSRF bugs altogether.
What Are CSRF Tokens?
A CSRF token is a mechanism on the client-side that is utilized in order to ensure each request that is made is entirely unique for a user. When the server-side undertake verification of the token, validation of the request occurs. Due to the fact there is a new token created by the app every time a new page is served, this means that the request is unable to be forged.
There are four key stages you can run through in order to effectively test for CSRF vulnerabilities and bugs.
Stage 1 – Understand the different types of Cross-Site Request Forgery attacks
Stage 2 – Review the countermeasures and causes of CSRF attacks
Stage 3 – Conduct testing and further explorative exercises
Stage 4 – Define and fine-tune user testing and test cases
Now, let’s look at each stage in a little more detail
Stage 1
Understanding the different types of Cross-Site Request Forgery attacks
While the anatomy of a Cross-Site Request Forgery attack is constant, the goals of the different types of CSRF attacks can vary greatly. As we have already touched upon earlier in this post, CSRF bugs can be used to carry out spoofed email messaging, fraudulent transactions, install back-doors, and steal sensitive data.
The Anatomy of Cross-Site Request Forgery
- The attacker identifies a functionality that is considered to be vulnerable to CSRF.
- The attacker creates a link that calls upon the identified function and which can execute the attack of their choosing. *The form of the link will depend on the specific ‘payload’ the attacker wishes to execute*
- The attacker will await a client that authenticates with the website or application that is vulnerable.
- The user client is tricked into following the malicious link.
- A forged request is sent from the user client to the compromised server.
- The server then carries out the forged request.
Stage 2
Review the countermeasures and causes of CSRF attacks
This section will cover two very important areas of CSRF attacks. Knowing what can cause a cross-site request forgery is one thing. However, having the knowledge of how to prevent a CSRF attack is equally, if not more important.
The Causes of CSRF Attacks
The only reason a compromise can occur is if the forged request is trusted by the web application or website. The most common cause of this is an authentication code that is either missing or omitted entirely. If the web application does not have the proper functionality to correctly confirm that each client request is not forged and that it is a genuine request that is coming from a legitimate action of the client, this can cause a vulnerability that may lead to a CSRF attack.
Typically, web applications with Cross-Site Request Forgery vulnerabilities will implement a consistent system of authentication where they perform user validation against a persistent token, which could be a session cookie as just one example.
With this type of authentication, when a request is made to the server, it simply checks to see if the user is logged in, not accounting for the legitimacy of whether that action has genuinely been sent from the client.
CSRF Prevention and Countermeasures
In order to prevent a cross-site request forgery occurrence, consider a transient system of authentication. The reason this type of system is effective is that it verifies each request using a secondary check. A good way to do this is through the transmission of a secret in each URL. Especially for those who request to update, mail, delete or create new actions. This is effective because an attacker will be unable to execute any type of attack without knowing the secret.
The only caveat to this will be if an attack executes a cross-site script attack in order to steal the secret.
Another method that is effective in protecting users from a CSRF attack is through the use of CAPTCHAs requiring clients to undergo validation check before the application permits any requests.
Other effective prevention methods against CSRF attacks include the use of POST rather than GET requests in order to perform specific actions or to confirm the HTTP referral header. However, if an attacker is aware of these measures, they have the potential capacity to forge a POST command through the use of a malicious script along with being able to spoof the HTTP referrer.
It goes without saying; developers will always need to be vigilant when it comes to finding new ways to protect against attackers.
Stage 3
Conduct testing and further explorative exercises
Now that you understand how cross-site request forgery attacks work, along with a number of ways you can potentially protect against CSRF attacks, there is a genuine requirement to perform rigorous testing and evaluation exercises. Without going into the complexities of each test, here are the three fundamental test subjects you will need to work through.
- Perform a fundamental CSRF test
- Perform a test on the use of a secret in URLs
- Perform a test on the use of a secret in Cookies
Stage 4
Define and fine-tune user testing and test cases
This is the last step of testing for CSRF vulnerabilities and bugs. This is the stage where you need to define and fine-tune the test case information in order to ensure proper coverage from all your tests and ensure you have worked through all of the potential scenarios.
As we have referred to frequently throughout this post, there are different types of attacks that CSRF bugs can be used to initiate. The key point we want to stress is that you must test the different payloads based on the individual features and characteristics of your specific application.
Another point that we need to highlight is the need for you to extend the test automation by adding Cross-Site Request Forgery test cases to this schedule. A logical way to do this is to formulate a list of:
- All GET requests in URLs
- All POST requests
Make a note of your own script which makes the requests with alternate session tokens.
Essentially, all state-changing actions need to be protected, and wherever it is physically possible, 2FA (two-factor authentication) should also be applied.
It goes without saying that any particularly sensitive application such as those which are classified within the financial services sector should also ensure that users are automatically logged-out after periods of inactivity.
Other Ways to Combat CSRF Vulnerabilities
There are other methods that can be deployed to help prevent a CSRF attack. The best way is to review the different parties that are linked to such an attack.
- The User
- The Content Host
- The Bank (as an example)
The Content Host – Should be more diligent at filtering inputs from users in order to effectively delete, quarantine, or otherwise remove elements which are particularly meaningful in HTML tags and scripts.
The Bank (as an example of an E-commerce Site) – Should contemplate moving any session-tracking mechanisms to dynamically produced session tokens which get included as an HTML form element that alters from one page to another as the user enters the application.
When done this way, it is difficult for an attacker to actually grasp a particular session. Considering CSRF specifically, an application that is built in such a way will have no cookie that would be passed back when the browser attempted to fetch an image which was referred to on a third-party site.
The User – There are a few simple steps that users can take to negate the risks of a CSRF attack from occurring. Using different browsers for your banking, browsing, shopping, and any form of financial transaction. If there is an attempt of a CSRF, the risk is mitigated as nothing of interest to an attacker can occur on a browser that is simply used for looking at things online.
‘NoScript’ is also a useful add-on that enables you to prevent and block scripts from running, particularly malicious scripts. Disabling scripting altogether is a common protection method used.
Cross-Site Request Forgery is a rather complex term for a relatively straight-forward type of cyber-attack. In a nutshell, a CSRF bug means that an intruder can force someone to take action online without their knowledge or express permission. To frame it another way, it is the same concept as somebody forging your signature on a piece of paperwork but is occurring online in the digital realm instead.
There is no evidence of the attack, which makes it appear as if the request came from the same IP that actually belongs to the user, who in such a case will also be known as the victim of the XSRF attack.
Unless prepared for thoroughly from a development perspective, a CSRF attack can pose serious risks to both users and organizations. From financial losses through to damaging the reputation of an entire business, the consequences are quite severe.
It can impact any type of web application that is not prepared in advance for such an attack. See: Security Management
