CSFR attacks, ASP.NET MVC 4

CSRF stands for Cross Site Request Forgery and is a technique employed to fooling a website by executing commands on behalf of a trusted (authenticated) user.

How it works

Commonly a malicious user sends a link to another user that maybe is authenticated on the target site and uses their session to execute commands like transfer money, change the email address and stuff like that.

CSRF in action

This time I’ll be working on a web site that allows authenticated users buy pastries at the online store. In this case, the goal of the attacker is to get a bunch of muffins on somebody else’s Mastercard.

The target site has a couple of web pages that allow users to logon, buy products and see their orders history:

Before going on, something to worth to mention is that after a user is successfully authenticated to a  website, the web browser will be sending the authentication cookie on every subsequent request to the server until the session expire (usually after 20 minutes of inactivity). This means that any incoming request from that session won’t be challenged for authentication (The user will not be redirected to the login page) even if they were accessing to secure resources.

By using a web debugging tool like Fiddler we can inspect the HTTP traffic, view the HTTP headers and understand how it works.

On login:

On every subsequent request after a successful login:

* ASPXAUTH is the ASP.NET authentication cookie.

If an attacker can see the source code of the target page, he can easily compose and submit a form to perform a CSRF attack.

The bad guy at work

Doing a little of social engineering, the bad guy figures it out that the target site is very busy on Friday morning where everybody is buying pastries for the office (which is a common thing to do in my country), so he assumes that by sending emails with links to the website’s hottest offers to a bunch of people, eventually a couple of them will be customers and maybe be interested on those offers, so they will be clicking on those links and if one of them still have the session's cookie alive, he will become a victim of the attack.

How to compose and submit the form

The first step is take a look at the target page source code

Now that we know the form structure, we can build a script like this:

By using this script we are posting an order at the online store using the good guy's session that will be delivered to the bad guy's address (Also note that the form won't be displayed at all).

Wanna try it yourself?

Follow these steps:

1. Download the sample app from here
2. Build and run the website
3. Register/Login
4. Place an order
5. View your orders history

So far, you just have used the site. Now click on this link (this is the link that the bad guy will be sending by email)  and you will see what happen. You should see a page with the message "The offer has expired, blah, blah, blah..." and then will be redirected to our website’s main page).

Now go to see your orders history and you will see what really happened ;)

If all went as planned, you should be seeing an order that you haven't posted, where the delivery address point to the bad guy's address, if this were a real site, this would have been aCSRF attack; you will be paying the bills and the bad guy will be getting stuff.

In future posts I’ll be covering some alternatives that ASP.NET provides to prevent this kind of attacks.

Note: this technique does not apply only to ASP.NET, CSRF attacks can be performed against other web technology such as Ruby on Rails or PHP.