What is it — and preventing attacks. A guide by a newbie of CSRF.

CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action.

What does CSRF stand for?

Cross Site Request Forgery

What is it?

Users who are genuinely logged in or authorised to use a service or website, find their authorisation exploited by another user who has embedded exploitable code on a page that they visit. This doesn’t even have to be on the same site.

Example Attack— No. 1

Unashamedly stolen from coding horrors (thank you).

  • Let’s say User 1 logs into a forum
  • User 2 has already posted an image on a discussion. He has however posted this:
<img src="http://foo.com/logout">

See — how the link is not an image. It’s actually a url that will log the user out.

Now the user would only have to visit the discussion page and they would be logged out if that was the url!

But this only will work with GET requests. POST requests won’t suffer this problem.

So the fix is:

Example Attack — No. 2

Also unashamedly stolen from coding horrors (thank you again).

Not a fix really.

  • The web developer changes the GET request for “http://site.com/logout” to a POST request.
  • But User 2 is still cunning.
  • He convinces User 1 to visit http://dodgy-site.com.
  • And User 1 visits this dodgy site — only for this script to appear on the page:
<body onload="document.getElementById('attack').submit()">
<form id="attack" action="http://foo.com/logout" method="post">
<input name="Log Me Out" value="Log Me Out" />
  • User 1 doesn’t even have to submit the form. The javascript does it automatically in this case.
  • User 1 is now logged out

Now — it doesn’t have to be javascript induced? It can be instead, a plain HTML form that is misleading users to submit it.

What if the form submitted, is a payment transfer or a change of the user’s password. Far more sinister things can be done by CSRF attacks.

So what’s the overarching problem:

The key to understanding CSRF attacks is to recognize that websites typically don’t verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. — Bill Zeller

Therefore, if the attacker, gets the user to submit a dodgy form in their browser, the attacker can pretend to be them, because the user already has the authorisation and everything else he needs to make requests to the genuine website. Even the attacker won’t have access from the cookies on his website — but when the url being attacked is used, it automatically pulls the cookies that belong to the same domain.

What CSRF Is Not!

It is not an authentication layer attack.

The user needs to be logged on (this is not an attack against the authentication layer), and for the CSRF request to succeed, it needs to be properly formed with the appropriate URL and header data such as cookies. — Troy Hunt (https://www.troyhunt.com/owasp-top-10-for-net-developers-part-5/)

Preventative Measures: #1 — Double Submitted Cookie

Double Submitted Cookie (thank you to unsplash.com and Picseli instagram.com/colouredpicseli)
  • A pseudorandom value should be generated when a user visits a site.
  • This value should be set as a cookie in the machine — and every form submission, or post request should include this random value.
  • When the form is submitted, the real server will compare the cookie with what was set in the form submission.

So how does this even help?

  • This is because domains can only see the cookies that they host themselves.
  • So if an attacker tries to trick a user to submitting a form that does sneaky stuff — he would have to guess the pseudorandom value that was set in the user’s cookie. The attacked can guess — but it can’t read that information on the real domain.

What are the benefits?

  • You don’t even need server-side state, or to store this key anywhere! You merely need to compare the values on every submission.

Auditing sites to check for CSRF attack holes

Coding horrors ends their article by asking this question:

If you want to audit a website for XSRF vulnerabilities, start by asking this simple question about every single HTML form you can find: “where’s the XSRF value?” — Coding Horrors

So the summarise, you need a:

  • CSRF token stored as a cookie
  • The same token embedded in the form for POST requests

How To Generate And Verify A CSRF Token


// Generate
$token = bin2hex(random_bytes(32));
$isUserGenuine = hash_equals($tokenForComparison, $_POST['token']));

Why use hash_equals?



Having A Token With Every Form

An answer provided by Scott Arciszewski and edited by Shores shows that you can make another token for every form request your site needs.

<input type="hidden" name="token" value="<?php
echo hash_hmac('sha256', '/my_form.php', $_SESSION['second_token']);
?>" />
$calc = hash_hmac('sha256', '/my_form.php', $_SESSION['second_token']);
if (hash_equals($calc, $_POST['token'])) {
// Continue...


*** What Are Timing Attacks





CSRF is a type of “Confused Deputy Attack”

Perfectly described in Haacked:

CSRF is a form of confused deputy attack. Imagine you’re a malcontent who wants to harm another person in a maximum security jail. You’re probably going to have a tough time reaching that person due to your lack of proper credentials. A potentially easier approach to accomplish your misdeed is to confuse a deputy to misuse his authority to commit the dastardly act on your behalf. That’s a much more effective strategy for causing mayhem! — Haacked

He goes on to describe that the confused deputy is your browser. It believes it has the authority to accomplish things without the user granting it authority — hence, a malicious attack can now ensue.

Session Fixation Attacks



One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.