Understanding CSRF

CSRF

Learning Objectives

• Understanding the working of CSRF
• Type of CSRF attacks
• Advance payloads for exploitation
• Defensive mechanisms

CSRF Lets attacker perform actions behalf on The user, Happens by exploiting the fact that browser stores user creds in cookies automatically, it allow attacker to perform actions on the site where user is authenticated.

Csrf has 3 Cycles:

1. Attacker already knows format of web app request to carryout a particular task and send a malicious link to user

2. Victim identity is verified on the website, by cookies, which are transmitted with each domain request and clicks on the link shared by attacker.

3. Insufficient security measure on the website makes the website unable to tell the difference between the real request and fake request

Risks of CSRF:

Although CSRF does not steal user data directly it will still cause harm:

1. UnAuthorised Access: As told above, attacker can control users Action, putting them on risk of financial loss, or account loss.

2. Exploiting Trust: CSRF exploits the trust users have on the website.

3. Stealthy Exploitation: CSRF works silently using browser standard behavior, without needing advanced payloads or malware, user might be unaware of the attack, making them vulnerable to repeated attacks.

Types of CSRF

Conventional CSRF attacks frequently concentrate on state-changing actions carried out by submitting forms. Victim is tricked into submitting the form without knowing the related data like cookies, URL parameter, etc. The Victim web browser sends http request to the app where victim is already authtenticated, These forms are made to transfer money, modify account information, or alter an email address.

XMLHttpRequest CSRF

Asynchronous CSRF: The idea is same as Normal CSRF but this happens in background, without the webpage reloading,

Normally web forms reload a page when you submit them, Old #CSRF exploited this

• Modern apps often **use JavaScript to send updates in the background** (AJAX/fetch requests) without reloading the page.
• Hackers can fake these background requests to make your browser do something you didn’t intend.

Example

• Suppose an email app lets you **change forwarding settings without reloading the page**.
• If the app is vulnerable:
• A hacker could make your browser **send a hidden POST request** that changes your forwarding address.
• You don’t see anything happen, but now your emails go to the attacker.

Key point: The attack is the same as classic CSRF — it abuses the trust between your browser and the website — but it happens quietly in the background using asynchronous requests.

Flash-based-CSRF

The term Flash Based CSRF describe the technique of conducting CSRF by taking advantage of flaws in Adobe Flash Player components

Internet applications with features like interactive content, video streaming, and intricate animations have been made possible with Flash but overtime security flaws became a major concern, particularly those which can do CSRF.

official support for Adobe Flash Player ceased on [December 31, 2020](https://www.adobe.com/products/flashplayer/end-of-life.html).

Even though Flash is no longer supported, a talk about Flash-based cross-site request forgery threats is important, particularly for legacy systems that still rely on antiquated technologies

malicious Flash file (.swf) posted on the attacker’s website would typically send unauthorised requests to other websites to carry out Flash-based CSRF attacks.

Attacks

A covert technique known as **hidden link/image exploitation** in CSRF involves an attacker inserting a 0x0 pixel image or a link into a webpage that is nearly undetectable to the user.

html
<! - Website →
<a href="https://mybank.thm/transfer.php" target="_blank">Click Here</a>
<! - User visits attacker's website while authenticated →

mitigations:

Get Ashbo3n’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

- Each Request should contain a unique CSRF token indentifier so the server can identify if its clicked from a valid source

Double submit cookie technique

one effective implementation of CSRF token is Double submit cookie technique where cookie value co-responds to a value hidden in form field, when server recives a request it checks the cookie value matches the form field value.

How it works

• Token Generation: When user initiates a session server generates a unique CSRF token, this is sent to user’s browser both as cookie and embedded into hidden form field of web browser where action is performed.
• User Action: Lets Assume User wants to transfer money, they fill out form which also includes the hidden CSRF token.
• Form Submission: After submitting the form 2 CSRF token is sent to the server, one in the cookie and other as part of hidden form data.
• Server Validation: The Server then Matches if the Cookie and hidden CSRF token matches, if yes they are considered legimate request else the request is rejected.

Same cookie Bypass

• These cookies come with a special attribute designed to control when they are sent along with cross-site requests.
• Strict, Lax, and None are the three potential values for the attribute.
• Max Protection: guarantees that the cookie is only sent if the request comes from the same origin as the cookie.
• Lax: Specific cross-site usage is permitted.
• None: of them need the secure attribute.

Pre-conditions for CSRF —

• User is authenticated.
• No CSRF token or origin check or a way to bypass it

CSRF’s goal is usually _make the victim’s browser perform actions using their cookies_ (transfer money, change email)

Attacker has to make victim click on there site either via URL shortening, Phishing, Social engeniering, or anything, after the victim has clicked on attacker’s domain, attacker domain can carry out the CSRF (if the targeted site has no csrf protection or can a find a way to bypass it) since The destination matches the cookie domain, and attack gets executed.

note: attacker’s page cannot read the response or the victim’s cookies via normal browser rules

How does CSRF work?

• Relevant Action: There has to be a relevant action, eg: such has modifying the email, changing user password, or any creds transfer.
• Cookie-based session handling: Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.
• No unpredictable request parameters: The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess.

POST /email/change HTTP/1.1
Host: vulnerable-web.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Cookie: session=yfjeiuJeiRfiRIcd
email=example-email.com

<html>
<body>
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>

Common Defensives against CSRF:

CSRF tokens

SameSite cookies

Referer-based validation

Bypassing CSRF token validation

• Validation of CSRF token depends on request method:

`GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

• Validation of CSRF token depends on token being present
• CSRF token is not tied to the user session

Bypassing SameSite cookie restrictions

SameSite is a browser security mechanism that determines when a website’s cookies are included in requests originating from other websites. SameSite cookie restrictions provide partial protection against a variety of cross-site attacks, including CSRF, cross-site leaks, and some CORS exploits.

What is a site in the context of SameSite cookies?

In the context of SameSite cookie restrictions, a site is defined as the top-level domain (TLD), usually something like `.com` or `.net`, plus one additional level of the domain name. This is often referred to as the TLD+1.

When determining whether a request is same-site or not, the URL scheme is also taken into consideration. This means that a link from `http://app.example.com` to `https://app.example.com` is treated as cross-site by most browsers.

Difference between a site and an origin?

The difference between a site and an origin is their scope; a site encompasses multiple domain names, whereas an origin only includes one. Although they’re closely related, it’s important not to use the terms interchangeably as conflating the two can have serious security implications.

Two URLs are considered to have the same origin if they share the exact same scheme, domain name, and port. Although note that the port is often inferred from the scheme.

|**Request from**|**Request to**|**Same-site?**|**Same-origin?**|

|`https://example.com`|`https://example.com`|Yes|Yes|

|`https://app.example.com`|`https://intranet.example.com`|Yes|No: mismatched domain name|

|`https://example.com`|`https://example.com:8080`|Yes|No: mismatched port|

|`https://example.com`|`https://example.co.uk`|No: mismatched eTLD|No: mismatched domain name|

|`https://example.com`|`http://example.com`|No: mismatched scheme|No: mismatched scheme|

All major browsers currently support the following SameSite restriction levels:

• [`Strict`](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions#strict)
• [`Lax`](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions#lax)
• [`None`](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions#none)
• Strict: If a cookie is set with the `SameSite=Strict` attribute, browsers will not send it in any cross-site requests
• Lax: `Lax` SameSite restrictions mean that browsers will send the cookie in cross-site requests, but only if both of the following conditions are met:
• The request uses the `GET` method.
• The request resulted from a top-level navigation by the user, such as clicking on a link.
• None: If a cookie is set with the `SameSite=None` attribute, this effectively disables SameSite restrictions altogether, regardless of the browser

Note: When setting a cookie with `SameSite=None`, the website must also include the `Secure` attribute, which ensures that the cookie is only sent in encrypted messages over HTTPS. Otherwise, browsers will reject the cookie and it won’t be set.