A5 Cross-Site Request Forgery

Problem and Protection

Reminder: Security is token-based in a stateless environment

3. Browser writes the cookie and send it along with every other request

2. Server records the user's identity

in memory and sends a cookie

with a matching Session_Id

1. Browser sends the username/password that the user enters

Gmail allows a blogger to lose his domain

o  David Airey returned from vacation to find his domain owned by a stranger!

o  Digging found that the hacker had used a CSRF weakness in Gmail to create a Gmail filter

o  The filter forwards all emails to the attacker who transferred David's domain to himself

Here's what a CSRF looks like

What if ...

o  We have a forum that allows HTML encoding o  A logged-in user posts a note that renders as: <div class="normal">

Here's a picture of my lolcat: <img alt="Image cannot be found" src="http://

www.facebook.com/like.php?User=AgileGadgets" />.<br /><br />

Enjoy!

</div>

o  What happens? o  Everyone who is _______ in to ___________

will automatically ________ you.

Cross-site request forgery o  CSRF vulnerabilities occur when a website

allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action

o  Understand: Websites NEVER verify a person o  Websites can verify only that the request came

from the browser of an authorized user o  Because browsers run code sent by multiple

sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request

Cross-site request forgery

aka …

XSRF

How attackers do it

o  Post the attack and get victims to navigate to it o  Create and host a web page with the attack on it o  Find a public site that allows posting (blog

responses, forums) and put up a malicious link o  How do they get people to hit their tainted

pages? •  Phishing emails •  Blog posts and replies •  Chat

How we do not protect ourselves o  Check the HTTP referrer

•  Myth: If we check the referrer and only honor requests that originated from our site, we can eliminate CSRFs that came from some other site

•  Reality: The HTTP referrer is easily spoofed resulting in false positives and is stripped by some hosts and elements resulting in false negatives

o  Using some secret cookie •  Myth: If our secret cookie is missing from the request, we'll know it's

illegitimate •  Reality: All cookies are submitted with each request

o  Only accepting POST requests •  Myth: If we only put business logic behind POSTs vs. GETs, a simple link

click can't fire event logic •  Reality: Attacker can cause POSTs via JavaScript or by having a form that

posts on any event including Load or Ready o  Multi-step transactions

•  Myth: If the victim has to confirm everything, it can't be automated •  Reality: Once the attacker learns the steps, he simply has to automate each

step

How we protect ourselves

o  Synchronizer token pattern o  Require user interaction o  Clear sessions early and often

Synchronizer Token Pattern

1.  Server writes a token to session 2.  Server puts a token in the browser response

•  Pre-crafted querystring •  Hidden field

3.  Browser sends a new request to the server This request has the client-side token

4.  Server compares the token in the request to the token it saved to session

5.  If they're the same, we're genuine. If different, it is a CSRF attack

One token per session

o  Generate a value when a user gets a session o  Put that in every page in a hidden field o  If we stop seeing that value in some page,

we know its not a valid user

To

Unique token per request

o  On page 1's unload: •  Generate a new token (random number or GUID) •  Put that token in a hidden form field •  Save it to session

o  On page 2's load: •  Read the token from session •  Read it from the hidden form field •  If they don't match, reject the action

Use ViewState

o  ASP.NET WebForms pages have a hidden field with ViewState. It stores the values in all controls

o  Used so that the server knows which of the original form field values were changed

o  Tells the ASP.NET engine which events must be run •  ex: If a textbox value is different from what is stored

in ViewState, the engine knows it must run the textChanged event

o  If it is required by your sensitive page and is missing, it will thwart the attacker

Require user interaction

o  Before performing the sensitive action, require the user to respond: •  reenter a

username and password

•  Use a CAPTCHA

o  The attacker may have a session cookie, but he does not know the username and password used to get that cookie

Clear sessions

If a session doesn't exist, it can't be used

Summary

o  When an attacker tricks logged-in users into hitting some URL that is pointing at another site, it is a cross-site request forgery

o  Use the synchronizer token pattern to protect your surfers •  Use the cookie, but also manually check a

hidden form field or QueryString o  Expiring sessions promptly can also help

Further study

o  Synchronizer token pattern: •  http://bit.ly/SynchronizerToken

o  Summary of ASP.NET security hints: o  http://bit.ly/ASPSecurityHints

o  ViewState decoder: •  http://bit.ly/ViewStateDecoder