CSRF Attacks: Real Life Attacks and Code Walkthrough
What is CSRF Attack?
Cross-Site Request Forgery (CSRF) attacks execute unauthorized actions on web applications, via an authenticated end-user’s connection. Threat actors typically use social engineering schemes to trick users into executing these attacks.
For example, a user might receive an email or a text message with a link, which deploys malware or injects malicious code into a web page. Once the user clicks the link, attackers use the malware or injected code to send requests to the web application on the user’s behalf.
A CSRF attack is limited to the permissions of the targeted end user. An end user with limited permissions can be forced into changing email addresses, or transferring funds, while an admin account can be forced to compromise an entire web application.
This article focuses on the anatomy of CSRF attacks. To learn more, including how to prevent attacks, see our complete guide to CSRF.
In this article, you will learn:
- Real World CSRF Attack Examples
- How Does a CSRF Attack Work?
- Cross-Site Request Forgery Attack Code Example
Real World CSRF Attack Examples
The first CSRF vulnerabilities were reported in 2001. Because CSRF is carried out from the attacker’s IP address, it often leaves no forensic evidence in a website’s logs. For this reason there are a few reported incidents of CSRF, although the real number of attacks is much larger.
Here are a few examples of notable CSRF attacks.
- TikTok—in 2020, ByteDance received reports of a vulnerability that allowed attackers to send messages containing malware to Tiktok users. After deployment of the malware, the attackers could perform CSRF or cross-site scripting (XSS) attacks, causing other user accounts to submit requests on their behalf to the TikTok application. TikTok patched the vulnerability within three weeks.
- McAfee—in 2014, Check Point researchers discovered a CSRF vulnerability in the User Management module of an enterprise security product, McAfee Network Security Manager. The attack allowed malicious users to modify other user accounts. The vulnerability was patched in version 8.1.7.3.
- YouTube—in 2008, Princeton researchers discovered a CSRF vulnerability on YouTube, which allowed attackers to perform nearly all actions on behalf of any user—including adding videos to favorites, modify friend/family lists, send messages to a user’s contacts, and flagging inappropriate content. The vulnerability was immediately fixed.
- ING Direct—in 2008, ING Direct, the banking website of a Dutch-owned multinational banking group, had a CSRF vulnerability that allowed attackers to transfer money from users’ accounts, even though users were authenticated with SSL. The website did not have any protection against CSRF attacks, and the process of transferring funds was easy for attackers to see and replicate.
How Does a CSRF Attack Work?
Browsers can automatically cache or store user website credentials, including information about session cookies, IP addresses, basic authentication credentials, and more. The purpose of this mechanism is to allow users to continuously access web applications without having to authenticate at every step.
Once a user is authenticated, a website vulnerable to CSRF cannot distinguish between a legitimate user request and a forged one.
Most CSRF attacks trick users into clicking a malicious link. The link is often delivered via emails and chat messages using social engineering techniques.
The link may include malicious JavaScript or HTML code, which contains a request. Once a user clicks on the link, the code requests a specific task. If the attack is successful, the browser executes the task, letting the attacker perform unauthorized actions using the user’s session.
In addition to tricking users, threat actors can also directly store CSRF flaws on a vulnerable site. This is a much larger risk because it allows the attacker to control multiple user sessions, including administrator accounts, without having to trick each user into performing an action.
Attackers create CSRF attacks by either storing IFRAME or IMG tags in HTML fields or by launching cross-site scripting (XSS) attacks.
Related content: Read our guide to csrf token.
Cross-Site Request Forgery Attacks Code Example
To illustrate a CSRF attack, take an eCommerce website, examplebuy.com, that uses GET requests to accept purchases from customers. We’ll show how attackers can use CSRF to purchase products using other user’s accounts.
1. Attacker observes URL request format
The attacker observes that purchase requests on the website are in this format.
GET
https://examplebuy.com/shop/purchase?productid=3441&amount=200&address=33&20Park%20Drive%20NY%20NY HTTP/1.1
The request assumes that the user has an open session with the website. It uses an address ID to reference an address defined by the legitimate user.
2. Attacker crafts a forged request URL
The attacker now creates a forged URL that will purchase a product with a high purchase price, using another user’s account.
GET
https://examplebuy.com/shop/purchase?productid=5776&amount=2000&address=45%20Main%20Street%20NJ%20NY HTTP/1.1
The attacker manipulates three parameters in the request—changing the product to a product they want to buy, changing the amount, and using their own address.
3. Attacker hides the URL in an image
There are a number of ways to get the user to load the forged request URL. A common tactic is to hide the URL in an image tag, and embed it in an email sent to the victim, or a website they will visit. The image tag would look like this:
<img src = “https://examplebuy.com/shop/purchase?productid=5776&amount=2000&address=45%20Main%20Street%20NJ%20NY” width=“0” height= “0”>
4. Attacker uses social engineering to get the user to load the image
The attacker sends a phishing email to the victim, which either directly includes the image, or includes a link to a web page that embeds the malicious image tag. The URL is loaded on the user’s device.
5. Ecommerce site receives the forged request
Assuming that the user has an active session with the ecommerce site, when the URL is loaded, the website receives the forged purchase request. The website cannot identify that the request was not made directly by the legitimate user. It obeys the request and sends the goods to the attacker, billing the legitimate user’s account.
To learn how to prevent CSRF attacks, see our complete guide to CSRF
Preventing CSRF Attacks with Bright
Bright helps automate the detection and remediation of many vulnerabilities including CSRF, early in the development process, across web applications and APIs.
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 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.
Scan any web app, or REST, SOAP and GraphQL APIs to prevent CSRF vulnerabilities – try Bright free.
