Cross site request forgery

in-depth study

Created by Piotr Podsiadly

OMG yet another security training

Lemme click that "I understand" button

Many security trainings are great

for making sure corporation is compliant with the law.

Impractical training

Reducing chance of being compromised

comes with the cost.

Web application security is difficult to master.

Let's dive into CSRF!

Cross site request forgery

The basics at first

GET example

from OWASP wiki page.

<img src="">


GET / HTTP/1.1

POST example

<body onload="document.forms[0].submit()">
<form action="" method="POST">


Content-Type: application/x-www-form-urlencoded


CSRF Definition

Attack that forces end user to execute unwanted actions on a web app in which they're currently authenticated.

  • state-changing requests, not theft of data
  • social engineering like sending a link via email or chat
  • administrative account victim

Sever scenario

Hacker sends "Password reset problem" email to helpdesk.

It reaches logged in Alice. Alice clicks the link in email.

<body onload="document.forms[0].submit()">
<form action="/personal-information" method="POST">

Hacker recovers Alice account password to and gains admin privileges

Why it works?

Session cookie headers are automatically passed with every page request matching associated domain

GET / HTTP/1.1
Cookie: SID=JWAAAsh-84ShNVVG...

How to prevent it?

Synchronizer Token Pattern - random "challenge" tokens associated with user's session

<form action="/personal-information" method="POST">

Same-origin policy prevents the hacker from reading DOM of other domain

Social engineering highlights

Hi, i lost my access to

Can you log in and click this link to see if you have same issue or is it just my account?

thanks, Peter

URL magic

  • аЬϲ - cyrlic, sigma
  • abc - latin

Nowdays mitigated by modern web browsers pа

HTML injection synergy

you can ensure user is already logged in by embedding your HTML on vulnerable website

<img src="/action?param=value">

In that case no user action is required

CSRF is good enough by itself, HTML injection just helps to scale it

CSRF prevention epic fails

With Synchronizer Token Pattern you can still be vulnerable

gun hold backward

or even hurt yourself.

Disclosure of CSRF-Token in URL

Don't put the token as GET request param value.

If you do, it can be read from:

  • browser history
  • http log files
  • referer header

or retrieved through social engineering by asking the user to copy and paste the link.

Cross-origin resource sharing

If you have CORS enabled

Access-Control-Allow-Origin: *

you allow any domain to read your site HTML/DOM. This includes reading CSRF-Token.


Persistent XSS is much more dangerous making CSRF almost irrevelant.

Hacker could read CSRF-Tokens but he can also read cookies values and impersonate the user.

CSRF would still be viable followup to XSS if cookies are marked with HttpOnly flag and there is no way to prevent it.

Fix XSS first!

Prevention Measures That Do NOT Work

  • Using a Secret Cookie
  • Only Accepting POST Requests
  • Multi-Step Transactions

Code review for CSRF

  • Is this a state changing action?
  • What if someone asks user to perform it without his consent?
  • Which HTTP method it uses?
  • Does it utilize common prevention logic?

OWASP code review wiki page


A library implementing synchronizer token pattern to mitigate the risk of CSRF attacks

A JavaEE Filter + exposes ways to integrate CSRF-Tokens into HTML.


Sources on github

Testing for CSRF

Can be easily automated:

  • record real traffic
  • log in again
  • replay the traffic with new session

Those requests that succeed are CSRF vulnerable

For manual test you can check existance of CSRF-Token in each request and if its there delete/change it. Also read OWASP testing guide v4

WAIT! There is more

We covered the basics, let's dive in to advanced topics at last!

CSRF in HTML5/Ajax web application

What if application uses XMLHttpRequest

  type: "POST",
  url: "/change-my-email",
  data: { email: "" }
}).done(function( msg ) {
    console.log( "Data Saved: " + msg );

instead of simple form

<form action="/change-my-email" method="POST">

HTTP/TCP level comparisson


POST /change-my-email HTTP/1.1
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest

simple form

POST /change-my-email HTTP/1.1
Content-Type: application/x-www-form-urlencoded

X- deprecated as per RFC 6648

Using jQuery does not protect from CSRF, someone can always make equivalent self-submitting form

PUT or DELETE method

Can you make it from HTML?

support for PUT and DELETE methods in forms - Nothing guarantees that it wont be an option in the future


Rails example - support for PUT in "legacy" browsers

<form action="/news/1" method="post">


With HTML form

<form enctype="text/plain" action="/doit" method="post">
  <input type="hidden" name='<?xml version' 
  <input type="submit" value="test"/>

browser create following request

POST /doit HTTP/1.1
Content-Type: text/plain
<?xml version="1.0"?><mySoapBody>isHere</mySoapBody>

JSON body

With HTML form

<form enctype="text/plain" action="/doit" method="post">
  <input type="hidden" name='{"ignoreMe":"' value='", "email":""}'>
  <input type="submit" value="test"/>

browser create following request

POST /doit HTTP/1.1
Content-Type: text/plain
{"ignoreMe":"=", "email":""}

AJAX or good old forms

It does not matter.

You should prottect from CSRF regardless of web technology stack.

blog post

Read only / public pages

CSRF definition key words: "execute actions" by "authenticated" user

Do we protect read only corporate account balance?

IP based throttling

Some read only pages may take more than few seconds to fetch and process the data

<img src=""/>
<h1>Refresh 10 times</h1>
<h3>and we will pay $1 to <a href="">UNICEF</a></h3>

Valued customers may have higher priority or a simple IP base throtling ensures one user cannot exhaust resources.

All these can be bypassed by CSRF

DDoS through CSRF fetches 100MB

    <meta http-equiv="refresh" content="30">
    <iframe src="" class="hidden"/>
    <h1>Please wait while we load the movie</h1>
    Buffering ... <img src="spinning-circle.gif"/>

1Gbps = 40 concurrent users with average home network

CSRF protection would prevent such attack

CSRF tokens and page usability

Protect everything antipatern

hackable URLs						

and web resource principles

Log-out usability and CSRF protection

CSRF - "execute action" by "authenticated" user

<img src=""/>

single sign-on


Protecting Log-in page from CSRF

Prompt pattern

Google log-in


When to protect

State changing actions by authenticated userProtect
Long running read only operation that consumes significant amount of resourcesProtect
Large files, network consuming resources that are not core functionality of the websiteDon't protect, implement proper throttling
Internet speed test appProtect
Static resources, lightweight read-only dynamic pagesDon't protect
Log-out pageDon't protect
Log-in pageProtect

blog post


Implement CSRF protection for actions that you dont want to be executed by users without their knowledge.

Knowledge check

This presentation


BY Piotr Podsiadly

Piotr Podsiadly