# CSRF Protection

Authors: | Toshio Kuratomi
Date: | 21 February 2009
For Version: | 0.3.x

CSRF, Cross-Site Request Forgery is a technique where a malicious website can gain access to a Fedora Service by hijacking a currently open session in a user’s web browser. This technique affects identification via SSL Certificates, cookies, or anything else that the browser sends to the server automatically when a request to that server is made. It can take place over both GET and POST. GET requests just need to hit a vulnerable URL. POST requests require JavaScript to construct the form that is sent to the vulnerable server.

Note

If you just want to implement this in Fedora Services, skip to the Summary of Changes Per App section

## How CSRF Works

1. A vulnerable web service allows users to change things on their site using just a cookie for authentication and submission of a form or by hitting a URL with an `img` tag.
2. A malicious website is crafted that looks harmless but has JavaScript or an `img` tag that sends a request to the web service with the form data or just hits the vulnerable URL.
3. The user goes somewhere that people who are frequently logged into the site are at and posts something innocuous that gets people to click on the link to the malicious website.
4. When a user who is logged into the vulnerable website clicks on the link, their web browser loads the page. It sees the img tag and contacts the vulnerable website to request the listed URL sending the user’s authentication cookie automatically.
5. The vulnerable server performs the action that the URL requires as the user whose cookies were sent and the damage is done… typically without the user knowing any better until much later.

## How to Prevent It

### Theory

In order to remove this problem we need to have a shared secret between the user’s browser and the web site that is only available via the http request-response. This secret is required in order for any actions to be performed on the site. Because the Same Origin Policy prevents the malicious website from reading the web page itself, a shared secret passed in this manner will prevent the malicious site from performing any actions. Note that this secret cannot be transferred from the user’s browser to the server via a cookie because this is something that the browser does automatically. It can, however, be transferred from the server to the browser via a cookie because the browser prevents scripts from other domains from reading the cookies.

### Practice

The strategy we’ve adopted is sometimes called double submit. Every time we POST a form or make a GET request that requires us to be authenticated we must also submit a token consisting of a hash of the `tg-visit` to show the server that we were able to read either the cookie or the response from a previous request. We store the token value in a GET or POST parameter named `_csrf_token`. If the server receives the `tg-visit` without the `_csrf_token` parameter, the server renders the user anonymous until the user clicks another link.

Note

We hash the `tg-visit` session to make the token because we sometimes send the token as a parameter in GET requests so it will show up in the servers http logs.

#### Verifying the Token

The `jsonfasprovider1` does the work of verifying that `_csrf_token` has been set and that it is a valid hash of the `tg-visit` token belonging to the user. The sequence of events to verify a user’s identity follows this outline:

1. If username and password given

> 1. Verify with the identity provider that the username and password match

> > 1. [YES] authenticate the user
> > 2. [NO] user is anonymous.

2. if tg-visit cookie present

> 1. if session_id from `tg-visit` is in the db and not expired and (sha1sum(`tg-visit`) matches `_csrf_token` given as a (POST variable or GET variable)

> > 1. [YES] authenticate the user
> > 2. [NO] Take user to login page that just requires the user to click a link. Clicking the link shows that it’s not just JavaScript in the browser attempting to load the page but an actual user. Once the link is clicked, the user will have a `_csrf_token`. If the link is not clicked the user is treated as anonymous.

> 2. Verify via SSL Certificate

> > 1. SSL Certificate is not revoked and able to retrieve info for the username and (sha1sum(`tg-visit`) matches `_csrf_token` given as a POST variable or GET variable)

> > > 1. [YES] authenticate the user
> > > 2. [NO] Take user to login page that just requires the user to click a link. Clicking the link shows that it’s not just JavaScript in the browser attempting to load the page but an actual user. Once the link is clicked, the user will have a `_csrf_token`. If the link is not clicked the user is treated as anonymous.

This work should mostly happen behind the scenes so the application programmer does not need to worry about this.

See also

The `jsonfasprovider1` documentation has more information on methods that are provided by the identity provider in case you do need to tell what the authentication token is and whether it is missing.

#### Getting the Token into the Page

Embedding the CSRF token into the URLs that the user can click on is the other half of this problem. `fedora.tg.utils` provides two functions to make this easier.

This function does everything `tg.url()` does in the templates. In addition it makes sure that `_csrf_token` is appended to the URL.

This function sets config values to allow `_csrf_token` to be passed to any URL on the server and makes `turbogears.url()` point to our `url()` function. Once this is run, the `tg.url()` function you use in the templates will make any links that use with it contain the CSRF protecting token.

##### Intra-Application Links

We support single sign-on among the web applications we’ve written for Fedora. In order for this to continue working with this CSRF protection scheme we have to add the `_csrf_token` parameter to links between Fedora Services. Linking from the PackageDB to Bodhi, for instance, needs to have the hash appended to the URL for Bodhi. Our `url()` function is capable of generating these by passing the full URL into the function like this:

    <a href="${tg.url('https://admin.fedoraproject.org/updates')}">Bodhi</a>

Note

You probably already use `tg.url()` for links within you web app to support `server.webpath`. Adding `tg.url()` to external links is new. You will likely have to update your application’s templates to call `url()` on these URLs.

#### Logging In

Each app’s `login()` controller method and templates need to be modified in several ways.

##### Templates

For the templates, python-fedora provides a set of standard templates that can be used to add the token.

Genshi version of templates to make adding certain Fedora widgets easier.

###### `fedora.tg.templates.genshi.login.html`

Module author: Toshio Kuratomi <tkuratom@redhat.com>

New in version 0.3.10.

Include this using::
  <xi:include href=”${tg.fedora_template(‘login.html’)}” />

`fedora.tg.templates.genshi.login.html.``loginform`([message])

message: | Any text or elements contained by the <loginform> tag will be shown as a message to the user. This is generally used to show status of the last login attempt (“Please provide your credentials”, “Supplied credentials were not correct”, etc)

A match template for the main login form. This is a CSRF token-aware login form that will prompt for username and password when no session identity is present and ask the user to click a link if they merely lack a token.

Typical usage would be:

    <loginform>${message}</loginform>

`fedora.tg.templates.genshi.login.html.``logintoolitem`(@href=URL)

@href: | If an href attribute is present for this tag, when a user is logged in, their username or display_name will be a link to the URL.

A match template to add an entry to a toolbar. The entry will contain the user’s username and a logout button if the user is logged in, a verify login button if the user has a session cookie but not a CSRF token, or a login button if the user doesn’t have a session cookie.

Typical usage looks like this:

    <ul class="toolbar" id="#main-toolbar">
      <logintoolitem href="${tg.url('/users/info')}" />
    </ul>

###### `fedora.tg.templates.genshi.jsglobals.html`

Module author: Toshio Kuratomi <tkuratom@redhat.com>

New in version 0.3.10.

Include this using::
  <xi:include href=”${tg.fedora_template(‘jsglobals.html’)}” />

`fedora.tg.templates.genshi.jsglobals.html.``jsglobals`()

A match template to add global variables to a page. Typically, you’d include this in your `master.html` template and let it be added to every other page from there. This adds the following variables in the fedora namespace for other scripts to access:

> fedora.baseurl: | URL fragment to prepend to any calls to the application. In a TurboGears application, this is the scheme, host, and server.webpath. Example: https://admin.fedoraproject.org/pkgdb/. This may be a relative link.
> fedora.identity.anonymous:
> | If `true`, there will be no other variables in the fedora.identity namespace. If `false`, these variables are defined:
> fedora.identity.userid:
> | Numeric, unique identifier for the user
> fedora.identity.username:
> | Publically visible unique identifier for the user
> fedora.identity.display_name:
> | Common human name for the user
> fedora.identity.token:
> | csrf token for this user’s session to be added to urls that query the server.

Typical usage would be:

    <jsglobals />

Using the `<loginform>` template will give you a login form that automatically does several things for you.

1. The `forward_url` and `previous_url` parameters that are passed in hidden form elements will be run through `tg.url()` in order to get the `_csrf_token` added.
2. The page will allow “Click through validation” of a user when they have a valid `tg-visit` but do not have a `_csrf_token`.

Here’s a complete login.html from the pkgdb to show what this could look like:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml"
          xmlns:py="http://genshi.edgewall.org/"
          xmlns:xi="http://www.w3.org/2001/XInclude">
      <xi:include href="master.html" />
      <xi:include href="${tg.fedora_template('login.html')}" />

      <head>
        <meta content="text/html; charset=UTF-8"
        http-equiv="content-type" py:replace="''"/>
        <title>Login to the PackageDB</title>
      </head>

      <body>
        <loginform>${message}</loginform>
      </body>
    </html>

You should notice that this looks like a typical genshi template in your project with two new features. The `<loginform>` tag in the body that’s defined in `fedora.tg.templates.genshi` is used in the body to pull in the login formand the `<xi:include>` of `login.html` uses `tg.fedora_template()` to load the template from python-fedora. This function resides in `fedora.tg.utils` and is added to the `tg` template variable when `enable_csrf()` is called at startup. It does the following:

The second match template in `login.html` is to help you modify the login and logout links that appear at the top of a typical application’s page. This is an optional change that lets the links display a click-through login link in addition to the usual login and logout. To use this, you would follow the example to add a `toolbar` with the `<logintoolitem>` into your master template. Here’s some snippets from a `master.html` to illustrate:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml"
          xmlns:py="http://genshi.edgewall.org/"
          xmlns:xi="http://www.w3.org/2001/XInclude">

    [...]
      <body py:match="body" py:attrs="select('@*')">
    [...]
        <div id="head">
          <h1><a href="http://fedoraproject.org/index.html">Fedora</a></h1>
          <ul class="toolbar" id="#main-toolbar">
            <logintoolitem href="${tg.url('/users/info')}" />
          </ul>
        </div>
    [...]
      </body>
      <xi:include href="${tg.fedora_template('login.html')}" />
      <xi:include href="${tg.fedora_template('jsglobals.html')}" />
    </html>

Warning

Notice that the `<xi:include>` of `login.html` happens after the `<body>` tag? It is important to do that because the `<body>` tag in `master.html` is a match template just like `<logintoolitem>`. In genshi, the order in which match templates are defined is significant.

If you need to look at these templates to modify them yourself (perhaps to port them to a different templating language) you can find them in `fedora/tg/templates/genshi/login.html` in the source tarball.

##### Controllers

Calling Fedora Services from JavaScript poses one further problem. Sometimes the user will not have a current CSRF token and will need to log in. When this is done with a username and password there’s no problem because the username and password are sufficient to prove the user is in control of the browser. However, when using an SSL Certificate, we need the browser to log in and then use the new CSRF token to show the user is in control. Since JavaScript calls are most likely going to request the information as JSON, we need to provide the token in the dict returned from `login()`. You can either modify your `login()` method to do that or use the one provided in `fedora.tg.controllers.login()`.

Note

Fedora Services do not currently use certificate authentication but doing it would not take much code. Working out the security ramifications within Infrastructure is the main sticking point to turning this on.

Note

The Fedora Account System has a slightly different login() method. This is because it has to handle account expiration, mandatory password resets, and other things tied to the status of an account. Other Fedora Services rely on FAS to do this instead of having to handle it themselves.

### AJAX

Making JavaScript calls requires that we can get the token and add it to the URLs we request. Since JavaScript doesn’t have a standard library of crypto functions we provide the token by setting it via a template so we do not have to calculate it on the client. This has the added bonus of propagating a correct token even if we change the hash function later. Making use of the token can then be done in ad hoc JavaScript code but is better handled via a dedicated JavaScript method like the `fedora.dojo.BaseClient`.

#### Template

Warning

Just like `login.html`, the `<xi:include>` tag needs to come after the `<body>` tag since they’re both match templates.

#### JavaScript

The `fedora.dojo.BaseClient` class has been modified to send and update the csrf token that is provided by fedora.identity.token. It is highly recommended that you use this library or another like it to make all calls to the server. This keeps you from having to deal with adding the CSRF token to every call yourself.

Here’s a small bit of sample code:

    <script type="text/javascript" src="/js/dojo/dojo.js"></script>
    <script type="text/javascript">
        dojo.require('fedora.dojo.BaseClient');
        dojo.addOnLoad(function() {
            pkgdb = new fedora.dojo.BaseClient(fedora.baseurl, {
                username: '', password:''});
            pkg_data = pkgdb.start_request('/packages/name/python',
                {req_params: {collectionName: 'Fedora',
                        collectionVersion: 'devel'}});

        });
    </script>

## Summary of Changes Per App

> - On startup, run `enable_csrf()`. This could be done in a start-APP.py and APP.wsgi scripts. Code like this will do it:

>       from turbogears import startup
>       from fedora.tg.utils import enable_csrf
>       startup.call_on_startup.append(enable_csrf)

> - Links to other Fedora Services in the templates must be run through the `tg.url()` method so that the CSRF token can be appended.

> - You must use an updated login template. Using the one provided in python-fedora is possible by changing your login template as shown in the Templates section.

> - Optional: update the master template that shows the Login/Logout Link to have a “Verify Login” button. You can add one to a toolbar in your application following the instructions in the Templates section.

> - Use an updated identity provider from python-fedora. At this time, you need python-fedora 0.3.10 or later which has a `jsonfasprovider2` and `jsonfasvisit2` that provide CSRF protection. The original `jsonfasprovider1` is provided for applications that have not yet started using `enable_csrf()` so you have to make this change in your configuration file (`APPNAME/config/app.cfg`)

> - Get the CSRF token into your forms and URLs. The recommended way to do this is to use `tg.url()` in your forms for URLs that are local to the app or are for Fedora Services.

> - Update your `login()` method to make sure you’re setting `forward_url = request.path_info` rather than `request.path`. One easy way to do this is to use the `login()` and `logout()` as documented in Controllers

> - Add the token and other identity information so JavaScript can get at it. Use the `jsglobals` template to accomplish this.

This one still needs to be implemented
  - AJAX calls need to be enhanced to append the CSRF token to the data. This is best done using a JavaScript function for this like the `fedora.dojo.BaseClient` library.