You are on page 1of 6

CSRF - Cross-Site Request Forgery

Karthik B
What is CSRF?
Cross-Site Request Forgery (CSRF), also known as XSRF, Sea Surf, or Session
Riding, is an attack method that deceives a web browser into executing an undesired
action in an application where a user is logged in.

The repercussions of a successful CSRF attack can be severe for both businesses and
users. It can lead to strained client relationships, unauthorized fund transfers, altered
passwords, and data theft, including the pilfering of session cookies.

CSRF attacks typically employ malicious social engineering tactics, such as deceptive
emails or links, tricking victims into sending a falsified request to a server. Since the
user is authenticated by their application during the attack, distinguishing between a
legitimate and a forged request becomes impossible.

How is CSRF Attack performed?


The objective of a CSRF (Cross-Site Request Forgery) attack is to coerce a user into
submitting a request that alters the state of a web application. Examples of such state-
changing requests include submitting or deleting a record, initiating a transaction,
purchasing a product, changing a password, or sending a message.

CSRF attacks often leverage social engineering platforms to deceive victims into
clicking on a URL containing a maliciously crafted, unauthorized request for a
specific web application. The user's browser then sends this manipulated request,
including any relevant credentials (such as user session cookies), to the targeted web
application. If the user is actively logged into the web application, it interprets the
request as authorized, thereby allowing the attacker to exploit the CSRF vulnerability.

CSRF attacks focus on web applications that fail to distinguish between valid and
forged requests controlled by an attacker. There are various methods attackers can use
to exploit this vulnerability.
Consider the example of Bob, who has an online banking account on samplebank.com.
Unaware of the CSRF vulnerability, Bob regularly conducts transactions with his
friend Alice on the site. An attacker aims to exploit this vulnerability to transfer
$5,000 from Bob's account, requiring the following steps:

1. The attacker must construct an exploit URL.


2. The attacker must trick Bob into clicking the exploit URL.
3. Bob must have an active session with samplebank.com.

To fulfill the first requirement for a successful CSRF attack, the attacker crafts a
malicious URL to transfer $5,000 to his account.

Through various social engineering methods, the attacker can trick Bob into loading
this malicious URL, such as embedding it in HTML image elements, placing it on
frequently accessed pages, or sending it through email.

In this scenario, when Bob's browser automatically opens the URL upon receiving the
email, a malicious request is sent to the online banking application without his
intervention. If Bob is in an active session, the application treats this as an authorized
transfer request from him, facilitating the attacker's intended transfer.

There are limitations to a successful CSRF attack:

1. The attack's success depends on the user being in an active session with the
vulnerable application.
2. The attacker must identify a valid URL with a state-changing effect on the
target application.
3. The attacker must determine the correct values for the URL parameters;
otherwise, the target application may reject the malicious request.
How to test for CSRF vulnerability?
To check if a session is insecure, look into how the application handles sessions. If the
user manages the session, meaning information is accessible to the browser, the
application is at risk. "Client-side values" include HTTP authentication details and
cookies.

Resources that can be reached through HTTP GET requests are definitely vulnerable.
While POST requests are typically automated with JavaScript and are exposed,
relying solely on POST requests isn't sufficient to address CSRF vulnerabilities.

How to exploit CSRF Vulnerability?

Creating the HTML manually for a Cross-Site Request Forgery (CSRF) exploit can be
laborious, especially when dealing with requests containing numerous parameters or
other complexities. The most straightforward method to develop a CSRF exploit
involves utilizing the CSRF Proof of Concept (PoC) generator embedded in Burp
Suite Professional:

1. Choose a request within Burp Suite Professional that you wish to assess or
exploit.
2. Right-click on the request, navigate to "Engagement tools," and select
"Generate CSRF PoC" from the context menu.
3. Burp Suite will automatically generate HTML designed to trigger the selected
request (excluding cookies, which the victim's browser will add automatically).
4. To fine-tune aspects of the attack, you can adjust various options in the CSRF
PoC generator, particularly in situations where unconventional features of
requests need addressing.
5. Copy the generated HTML into a web page, open it in a browser logged into
the vulnerable website, and verify whether the intended request is executed
successfully, leading to the desired action.
How to prevent and mitigate CSRF Attack?
Cross-site Request Forgery (CSRF) vulnerabilities pose a significant threat, and their
prevention is a complex task with various considerations. Implementing effective
measures involves training, risk assessment, and the use of specific techniques. Here
are steps and principles to enhance the security of your web application:

Step 1: Train and Maintain Awareness

Ensure that everyone involved in building the web application, including developers,
QA staff, DevOps, and SysAdmins, is well-informed about CSRF vulnerabilities.
Conduct security training sessions to raise awareness and establish a proactive
security mindset.

Step 2: Assess the Risk

Understand that CSRF vulnerabilities are not applicable to public content; they
become dangerous when authentication is required. If your website only contains
public content, the risk of CSRF is minimal. However, for web applications with user
accounts, especially in e-commerce, treat CSRF as a significant risk.

Step 3: Use Anti-CSRF Tokens

Implement anti-CSRF tokens as they are considered the most effective method to
protect against CSRF attacks. Utilize tested implementations like CSRFGuard for
Java or CSRFProtector for PHP. Only develop your own mechanism if there's no
existing solution for your environment.

Step 4: Use SameSite Cookies

Set the SameSite attribute of your cookies to Strict. If this affects your web
application's functionality, consider setting the SameSite attribute to Lax, but avoid
setting it to None. While not all browsers support SameSite cookies, most do. Employ
this attribute as an additional layer of protection alongside anti-CSRF tokens.

Step 5: Scan Regularly


Regularly scan your web applications for CSRF vulnerabilities, which may be
introduced by developers or external libraries/modules/software. Use a web
vulnerability scanner for comprehensive assessments.

References:

https://portswigger.net/web-security/csrf

https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/

https://www.cloudflare.com/learning/security/threats/cross-site-request-forgery/

https://www.acunetix.com/websitesecurity/csrf-attacks/

You might also like