Servage Magazine

Information about YOUR hosting company – where we give you a clear picture of what we think and do!

Securing you website with CSRF protection

Thursday, March 2nd, 2017 by Servage

secureCross-site request forgery (CSRF) is an exploit that allows a malicious user to send requests on behalf of another user in a web application. Even though protecting applications from CSRF attacks is not very difficult, these vulnerabilities are still fairly common. Now is a perfect moment to learn how to protect your application from such exploits.

How CSRF Works

A cross-site request forgery attack can happen when a user clicks a malicious link on a website or email message. State-changing operations, such as changing a user’s password should be implemented using POST requests. However, this is not always the case and applications sometimes use GET requests for this type of actions. This is a bad idea because they are rather easy to exploit.

Consider a scenario where it is possible to change a user’s password by visiting the following URL: If a malicious user knows that a specific person uses this website and most likely is already logged in, the user could send an email to the person that contains a link: <a href=””>Best New Year’s Deals</a>. When the user clicks the link, the password is changed without any confirmation from the user.

As mentioned earlier, this type of actions should be implemented to only work using POST requests. However, it is also possible to trick a user into submitting the same action using a POST request. A malicious website can have a form with a hidden field that contains the value of a new password. The form can be automatically submitted using JavaScript or by making the user believe the form does something else.

Next, let’s have a look at how we can protect ourselves from these exploits using two different approaches.

Verifying the Source Origin

The first approach works by checking that the request originates from the same website. There are three HTTP headers that can be used for this: Origin, Host and Referer.

The Host header is the target domain, such as The Referer header contains the domain that linked to the target domain. If a user clicks a link on Facebook, the Referer will be Origin is the source domain for CORS (cross-origin resource sharing) requests, which is used to send and load data from a different domain. If you compare the Origin and Referer headers with the Host header, you can determine if the request came from the same website or not.

CSRF Tokens

This method is used with POST requests. In every form, there should be a hidden form field that contains a CSRF token. The token is a cryptographically secure random character string that should be unique for every user and regenerated for every session. The token is loaded from a database, for example from a column called “csrf_token” from a “users” table. This token is inserted into the hidden field and sent with the form. If the token matches the value in the database, we can conclude that the form was submitted from the same website.

Securing you website with CSRF protection, 3.5 out of 5 based on 4 ratings
Categories: Guides & Tutorials


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet (leave a comment)

You are welcome to initiate a conversation about this blog entry.

Leave a comment

You must be logged in to post a comment.