Home Reading Room A Quick Guide to Cross-Site Request Forgery (CSRF) and How to Prevent...

A Quick Guide to Cross-Site Request Forgery (CSRF) and How to Prevent It

Cross-site request forgery is a critical vulnerability that can cause extensive damage to web applications. Learn about cross-site request forgery and how to avoid it in this blog.

SHARE
cross-site request forgery

Cross-site request forgery (CSRF) is a critical web application security vulnerability that is increasingly gaining prominence. As businesses embrace digital transformations with advancing technologies, the threat landscape has also widened for web application vulnerabilities.

The first CSRF vulnerability exploit dates to the early 2000s, but Peter Watkins initially coined the term in 2001. While the first popular CSRF exploit surfaced in 2005, known as the MySpace worm by Samy Kamkar, also known as “Samy worm” – it was the earliest known cross-site scripting worm – which has revolutionized the web security space.

In 2007, cross-site request forgery ranked 5th place in the OWASP Top 10 and later dropped from the OWASP framework owing to the low incidence rate in 2017. However, cross-site vulnerabilities made headlines once again in 2018, with high-profile cases reporting CSRF bugs. Multiple organizations like Facebook were also exposed to cross-site forgery request vulnerabilities.

Before understanding the implications of CSRF exploits, it is crucial to know CSRF’s meaning and fundamentals. This blog explains CSRF, its key concepts, how it works, and how to prevent it.

What is Cross-Site Request Forgery (CSRF)?

Alternately known as Session Riding or Sea Surf, Cross-Site Request Forgery is an attack method wherein threat actors design malicious requests to trick the users into visiting a duplicate website. The attacker can craft a fraudulent request, embed the malicious link in image tags, and trick the user into downloading the image through phishing or other techniques.

Typically, CSRF attacks target websites that trust some form of authentication by users before performing any action. It exploits a vulnerability in a web application when it cannot detect the difference between a valid user request and a forged one when the user is authenticated to the site. During a successful execution of a CSRF attack, an authenticated user is misdirected to a malicious website to perform actions with commands sent by the attacker.

An unsuspecting user is under the impression that they are performing an action on a legitimate website and unknowingly allow attackers to intrude on their system.

CSRF exploits can also occur because of cookies that are abused during cross-site requests. The process of fetching data from a third-party website is known as a cross-site request. Since all cookies, including session cookies, are also included in browser requests, the CSRF attack can be triggered.

Examples of Cross-Site Request Forgery Attack

Cross-Site Request Forgery attack is executed when a cybercriminal copies the layout, design, or website format from where data is being pulled [1].

Let’s understand a CSRF example in the context of a user logging into an e-commerce portal to purchase a product. For the CSRF attack to be triggered, the user must be authenticated to the site in an active session. The attacker exploits this trust and sends forged requests on behalf of the authenticated user. When the attack is successful, the attacker deceives the web application used to send their information to a fake website or place an order on their behalf.

The following section discusses the key concepts and components of CSRF and how it is carried out.

Key Concepts of Cross-Site Request Forgery

Successful execution of cross-site forgery attack includes two main techniques:

  • Cross-site forgery attack relies on social engineering methods to deceive targeted users into clicking a forged link or URL. The common ones include phishing mail, a fake chat link, a tracking system, or a fake push notification that will redirect the user to the fraudulent site.
  • CSRF attack aims to target users for performing state change requests. State changing requests do not reveal the data response of the request to the attacker and are used to only make some alterations in the data values, such as changing the email address, placing an order, changing passwords etc.

Through such attacks, the attacker can take control of the entire web application under some scenarios.

Components of Cross-Site Request Forgery

A Cross-Site Request Forgery attack consists of two main elements:

  1. Cross-Site: The user is tricked into clicking a fake link that takes them to a target website designed to steal information from the victim.
  2. Request Forgery: Cybercriminals send the malicious links to the user’s website or browser to which they are authenticated and trick them into clicking the duplicated link or values.

Learn More About CSRF Attacks

How Does a CSRF Attack Work?

As explained above, the CSRF attack is triggered when the user is authenticated to the web application, and the attacker can exploit the active session to trick the users.

There are two main methods of carrying out cross-site scripting intrusion:

1. GET Method

GET is an HTTP method that is used to retrieve any information from the specified resource.

To execute a cross-site forgery attack using the GET request, the user simply clicks on the forged link to find the malicious webpage. This website executes a script that sends an unsolicited request. Since the victim is unaware that they are on the duplicated platform, they perform the command and submit their credentials or download the cookies for the hacker to manipulate [2].

It is always wise not to use the HTTP GET request to perform state change requests dealing with sensitive data. Sending an HTTP GET request doesn’t result in data change generally. But in some situations, web apps still use GET instead of the POST to perform state changes. These activities include changing passwords or submitting a record etc. So, the GET HTTP method should be used to send non-sensitive data only, or attackers can exploit cross-site requests to execute an undesired action on the victim’s behalf.

2. POST Method

An HTTP POST request sends data to the server, which is embedded in the message body itself. While GET request is a convenient way to exploit CSRF vulnerability, most state-changing activities are done through HTTP POST requests. While it’s a myth that CSRF vulnerability cannot be exploited through the POST request, it is not the case. The attacker can deceive the user by creating a forged website that transmits malicious JavaScript and causes the user’s web browser to perform an undesirable action by sending a POST request when the page loads.

The following section highlights a few methods linked to CSRF protection.

Cross-Site Request Forgery Prevention Techniques

CSRF has severe ramifications on an individual’s data. It is even more concerning for organizations as attackers can use CSRF attacks to perform fraudulent transactions or disrupt the entire operation by accessing system-level privileges.

However, CSRF risks can be contained as web application security experts have proposed numerous CSRF prevention measures. Some of the best practices include:

1. Use CSRF Tokens

Organizations can implement CSRF prevention techniques using a CSRF token. These unique tokens have a secret value generated by a server-side application. Developers ensure that these requests are valid by adding a challenge token to every state change request linked to a specific user. These requests can range from transferring funds to adding personal credentials on the back end of the website.  And the token should be valid until the user ends the session. They are also known as the Anti-CSRF token, which protects users from falling prey to forged URL requests as the attackers also need to know the token to send malicious requests to the target user.

CSRF tokens can prevent cross-site request forgery attacks, as attackers fail to construct and feed their victims a fully valid HTTP request [3].

2. Use the SameSite Flag in Cookies

SameSite flag in cookies is a new method or attribute of preventing a CSRF attack. The SameSite attribute can be used to restrict cookies for cross-site requests for all third-party websites. This prevention technique enhances the security of web applications to a large extent. In this scenario, the website uses unique session cookies to determine if authentic users are logged in. Under suspicious behavior, the user or the bot will be blocked before any malicious activity is executed.

3. Implement Training and Raise Awareness

Apart from the above-mentioned cross-site request forgery prevention techniques, taking proactive steps is also important. You need to be well versed with the latest web application vulnerabilities to mitigate the threats arising from CSRF vulnerabilities.

Furthermore, it would help if organizations upskilled their employees periodically, especially those responsible for assessing and analyzing the security aspects of the organization — the IT and cybersecurity teams. A higher level of awareness and knowledge of the latest technologies and resources can help fortify organizations’ web applications’ security. The team involved in the web application development process should know about the risks associated with CSRF vulnerabilities. Sound knowledge of using an anti-CSRF token would be a significant step in making your web applications risk-free. Therefore, mapping your workforce to the proper training certification is also essential to mitigate the risks.

One such credible program is EC-Council’s Web Application Hacking and Security certification program that offers state-of-the-art training to candidates interested in taking their application security/cybersecurity skills to the next level.

Master Web Application Hacking and Security Skills with EC-Council

EC-Council’s Web Application Hacking and Security Training Certification equips you with niche skills aligned with application security job roles. The program covers every aspect of cross-site request forgery and how a web application security professional can identify such attacks. Apart from CSRF attacks, the program also covers different modules of web application vulnerabilities. You’ll learn about automated tools and techniques that will enable you to learn, hack, test, and secure web applications.

The program also includes capture-the-flag challenges to test one’s hacking skills, but the challenger can also follow an instructor to complete the challenge or work alone.

The certification will prove ideal for every aspiring web application penetration tester and organization looking for new ways to strengthen their cybersecurity teams.

Get Certified as a web application security expert -> Register Now


FAQs

1. How do I get my CSRF token?

Ans. You can get a CSRF token through a cryptographic strength pseudo-random number generator (PRNG). This generator is seeded with the timestamp, which signifies the time it was created. It also comes with a static secret.

You can also generate personal tokens by linking the outputs with user-specific entropy and taking the whole structure’s strong hash.

2. What are the two primary types of XSS vulnerabilities?

Ans. The primary XSS vulnerabilities include:

  • Reflected XSS: Malicious script comes from the current HTTP request.
  • Stored XSS: Malicious script comes from the website’s database.