Chapter 4. Cross-site Request Forgery

In this chapter, we will cover cross-site forgery. This topic is not exactly new, and believe it or not, we have already encountered this in the previous chapters. In this chapter, we will go deeper into cross-site forgery and learn the various techniques of defending against it.

Introducing cross-site request forgery

Cross-site request forgery (CSRF) exploits the trust that a site has in a user's browser. It is also defined as an attack that forces an end user to execute unwanted actions on a web application in which the user is currently authenticated. We have seen at least two instances where CSRF has happened. Let's review these security issues now.

Examples of CSRF

We will now take a look at a basic CSRF example:

1. Go to the source code provided for this chapter and change the directory to chp4/python_tornado. Run the following command:

   python xss_version.py
   

2. Remember to start your MongoDB process as well.

3. Next, open external.html found in templates, in another host, say http://localhost:8888. You can do this by starting the server, which can be done by running python xss_version.py –port=8888, and then visiting http://loaclhost:8888/todo_external. You will see the following screenshot:

   

   Adding a new to-do item

4. Click on Add To Do, and fill in a new to-do item, as shown...

Other examples of CSRF

CSRF can also happen in many other ways. In this section, we'll cover the other basic examples on how CSRF can happen.

CSRF using the <img> tags

This is a classic example. Consider the following instance:

<img src=http://yousite.com/delete?id=2 />

Should you load a site that contains this img tag, chances are that a piece of data may get deleted unknowingly.

Now that we have covered the basics of preventing CSRF attacks through the use of CSRF tokens, the next question you may have is: what if there are times when you need to expose an API to an external app? For example, Facebook's Graph API, Twitter's API, and so on, allow external apps not only to read, but also write data to their system.

How do we prevent malicious attacks in this situation? We'll cover this and more in the next section.

Other forms of protection

Using CSRF tokens may be a convenient way to protect your app from CSRF attacks, but it can be a hassle at times. As mentioned in the previous section, what about the times when you need to expose an API to allow mobile access? Or, your app is growing so quickly that you want to accelerate that growth by creating a Graph API of your own.

How do you manage it then?

In this section, we will go quickly over the techniques for protection.

Creating your own app ID and app secret – OAuth-styled

Creating your own app ID and app secret is similar to what the major Internet companies are doing right now: we require developers to sign up for developing accounts and to attach an application ID and secret key for each of the apps.

Using this information, the developers will need to exchange OAuth credentials in order to make any API calls, as shown in the following screenshot:

Google requires developers to sign up, and it assigns the client ID

On the server end, all you need to do...

Summary

In this chapter, we covered the basic forms of CSRF attacks and how to defend against it. Note that these security loopholes can come from both the frontend and server side. In the next chapter, we will focus on misplaced trust in the client, which is a situation where developers are overly trusting and expect the code to work as they want in the browser, but for some reasons, it does not.