A Cross Site Request Forgery (or CSRF) attack is where a victim’s browser is used to send HTTP requests to a target website which can be fired inconspicuously by using the victim’s credentials. This kind of attack generally requires a victim to be logged into the target site while navigating another malicious which will allow that site to send a HTTP request to the target.
Here is a simple example. You are logged into your online bank account, while still logged in you open up another browser tab to a website which has malicious code in it. Because you have already verified your identity with the bank website by using your login credentials, the malicious code can send a request to the website using your browser which the bank will accept as you.
I will go into the process a bit more below and show you how to some techniques which will allow you to reduce the risk of your website accepting these CSRF attacks as normal user actions. Before I go into the solution though, lets have a look at how this process works.
How CSRF attacks work
OK, so here we will go into how the process works when a website attempts to use a CSRF vulnerability. I will be assuming you are familiar with PHP coding, nothing will be too advanced here but it will help to have an understanding of the code I’m writing.
Let’s assume you have been using a website for a while, which you trust, where you buy plane tickets. We will call this website jacksflights.com.
You’re logged into jacksflights.com and navigate to another website in a separate tab called jacksplanetimes.com. Unfortunately, this website has a malicious code point which will attempt to book tickts on your account without you ever knowing. Generally it is done in one of two ways:
Images and iFrames
Anyone with a basic understanding of HTML coding will recognise an image tag which usually looks something like the one below:
<img src="http://www.test.com/testimg.png" />
Unfortunately, there is no way for a browser to really distinguish what the website is trying to get. So, if we replace the perfectly innocent image link with a link to an actual page with parameters, the browser is going to call that page. All we have to do it set the image to be tiny and not display in the browser anyway and the visitor would never know it was there:
<img src="http://www.jacksflights.com/book_flight.php?flight_id=1234" width="1px" height="1px" style="display: none;" />
This new link doesn’t actually link to an image, but as far as the browser is concerned, it doesn’t matter. It calls the page anyway, now, if the user is logged into jacksflights.com then the flight can be booked automatically without the user even being on the right page.
Some will choose to attempt the CSRF by using an iframe to do the very same thing, the process is almost exactly the same:
<iframe style="display: none;" src="http://www.jacksflights.com/book_flight.php?flight_id=1234" height="240" width="320"></iframe>
This is a very simple example of how a CSRF attack could happen using ‘src‘ links in iframes and images.
The method is where post data is set by the page and actually fired off to the page in question which is a way hackers have gotten around developers requiring data to be posted rather than collected (more on this later).
So on our malicious website, jacksplanetimes.com, we could have a form buried in the code which is fired off automatically on page load. Some hackers prefer to use an AJAX form submit to reduce any suspicious reloading of the page. In this example though, I will keep things simple and use a standard html form with hidden inputs.
Now, many websites accept form data being posted from any URL at all which means all we have to do is point the form ‘action‘ towards the page we want to send data. See below for the example code:
</pre> <form id="flightForm" action="http://www.jacksflights.com/book_flight.php" enctype="multipart/form-data" method="post"> <input type="hidden" name="flight_id" value="1234" /></form> <pre>
Again, a very simple example.
To sum up
You can see from these two examples that the very essence of a CSRF attack is by providing information to a page on an external website which the user is logged into in another tab. It takes the websites trust in a visitor and quietly submits information to it under the guise of being initiated by the visitor themselves.
In order to explain the fundamentals of CSRF exploits easily I’ve used very simple examples. In reality there can be a lot of data submitted in these attacks, we will continue to use the example in the next page though so you have an idea of the steps you can take to avoid getting hit with this.
Carry on reading on the next page to see how to protect your website from CSRF exploits and ensure all data is actually sent by the visitor and not an external website hijacking their credentials.