csrf not-all-defenses-are-created-equal

PowerPoint Presentation

CSRF: Not All Defenses Are Created Equal

Ari Elias-BachrachDefensium llc

November 2013

This Talk is a Review of Current Defensive Options

Or the long tail?

Is your application one of the 80%

This Talk Will Cover CSRF Defenses and Their Side Effects

What is CSRF

General (high level) fixes

Code level defenses

Server level defenses

CSRF occurs when an attacker tricks a user's browser into performing an action on a website

Normally, Browser's Form Submissions are Straightforward and Predictable

GET /submitpage?amount=100.00&dest=12345Server: server.com

POST /submitpageServer: server.com

amount=100.00&dest=12345

If action was a POST

If action was a GET

Normally, Browser's Form Submissions are Straightforward and Predictable

If you can predict all the parameters for an action, you can fake it

To Fake a GET

http://server.com/submitpage?amount=100.00&dest=12345

http://webmail.com/sendEmail?dest=boss@work&subj=resignation

If you can predict all the parameters for an action, you can fake it

To Fake a POST

document.evil.submit()

1. User navigates to website which attacker has some control over

2. User's browser tries to load content from site

3. Content performs action at a legitimate site

Anatomy of an Attack

Anatomy of an Attack

Malicious code

Legitimate site

Session cookie

In 2008, A CSRF flaw Was Used to Attack Cable Modems

Found a CSRF flaw in ADSL modems used by a Brazilian ISP

Used it to Change DNS settings

Sent users to malicious websites that looked like www.google.br

High Level Defenses (Design Patterns)

There are Four Design Patterns Which are Used

Synchronizer Token Pattern

Double Submit Cookies

Challenge Response

Check Referrer Header

Make at least one parameter unpredictable

Upon submission, check to ensure the submitted value matches the generated value

Primary Defense is the Synchronizer Token Pattern The most common defense

Things to look out for - How are tokens remembered? - Completeness of coverage

Primary Defense is the Synchronizer Token Pattern The most common defense

Generate a random value, store it in two places: 1 a cookie 2 a hidden form field

Upon submission, check to see if they match

Second Defensive Option is Double Submit CookiesThis option used less often, but useful for things like REST

abc123

abc123

abc123

=abc123

Things to look out for: - Do not use the Session ID for this purpose!

Second Defensive Option is Double Submit CookiesThis option used less often, but useful for things like REST

abc123

abc123

abc123

=abc123

A Third Option is Any Form of Challenge Response System Rarely Used Exclusively for CSRF Defense





Things to look out for: - User impact

A Fourth Option is to Check the Referrer Header I Have Never Seen This Implemented

GET /services/transfer.jsp HTTP/1.1Host: mybank.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0Accept: */*Accept-Language: en-US,en;q=0.5Referer: http://t.co/xblu14l6vLCookie: JSESSIONID=007f0100547a514c54060044;

A Fourth Option is to Check the Referrer Header I Have Never Seen This Implemented

Things to look out for: - Potential impact on other things which may modify the referer header

Actually Implementing These Patterns is Where it Gets Fun and Complicated

Code FixesServer Fixes

We Will Show Five Common Software Libraries That Can Be Used To Do CSRF Defense

ViewState User Keys (.net)

AntiForgeryToken (.net MVC)

AntiCSRF (.net)

CSRFGuard (Java, PHP port is in progress)

HDIV (Java)

.net can add CSRF protections to the ViewState

Viewstate is meant to maintain a form's state on postbacks

Page.aspx

Page.aspx


Adding the session ID to the view state makes it unpredictable

sessionID


Add to OnInit for all pages or once to base class protected override OnInit(EventArgs e) {base.OnInit(e); if (User.Identity.IsAuthenticated) ViewStateUserKey = Session.SessionID; }


Viewstate User Keys was designed to protect against 1 click attacks, which are a subset of CSRF attacks

Page.aspx

Other.aspx

Other.aspx

Only protects postbacks - Won't protect posts to other pages

.net MVC Applications Can Use AntiForgeryToken

What about .net MVC?

AntiForgeryToken - Part of the HtmlHelper class



Validate the token in the controller

[ValidateAntiForgeryToken]public ActionResult FunctionToProtect(){ // this is now run only if the token is valid}


By Default, will only work for POSTNot a problem if GET is idempotent

Can be hacked to work, google for details

Request.Params versus Request.Form param does GET r POST, form does only POST


Obvious problem: the forgetful programmer - must add to every controller and function that needs to be protected

Anticsrf for .net implements the double submit cookies pattern

Anticsrf

- For .net- Has no other requirements (like viewstate enabled, MVC, etc.)- Open source- Developed in C#

Available from http://anticsrf.codeplex.com/


Generates string using Guid.NewGuid()

Cookie: __CSRFCOOKIE=a22b81af-74f0-45ee-b2fd-1ead5f31f1c2;

in POST

__CSRFTOKEN=a22b81af-74f0-45ee-b2fd-1ead5f31f1c2

abc123

abc123

abc123

=abc123


Can be used in a .net web appNew Token for each sessionOnly protects POST (not a problem if GET is idempotent) - Won't work for Rest (unless you hack it)

abc123

abc123

abc123

=abc123

CSRFGuard Implements the Synchronizer Token Pattern and Makes a New Token For Each Session

Made By OWASP (open source, BSD license)

Java currently, PHP and .net port in progress

Keeps one token per session, stored in the session - exposure of token compromises entire session

CSRFGuard Implements the Synchronizer Token Pattern and Makes a New Token For Each Session

Modifies existing GET and POST requestsKeeps one token per session, stored in the session - exposure of token compromises entire session

link=nonce1

action=nonce1

CSRFGuard Can Also be Configured to Generate a New Token For Each Page

Each link or action would get a unique token valueStored in session

Feature is still experimental

link=page?nonce1

action=page2?nonce2

CSRFGuard Can Also be Configured to Generate a New Token For Each Page

Also supports AJAX

Sets the token value in an HTTP header

HDIV Uses Tokens With a Queue Based Expiry

link=page?nonce1

action=page2?nonce2

HDIV is a Java library that provides several security functions, including CSRF defense using the Synchronizer Token Pattern.

The queue includes all generated tokens (could be dozens per page).

These Five Libraries All Have Different Approaches To CSRF Defense

ViewState User Keys (.net)

AntiForgeryToken (.net MVC)

AntiCSRF (.net)

Synchronizer Token Pattern - only postbacks

Synchronizer Token Pattern - needs lots of code changes

Double Submit Cookies - only protects POST

These Five Libraries All Have Different Approaches To CSRF Defense

CSRFGuard (Java)

HDIV

Synchronizer Token Pattern - can be done per session or page

Synchronizer Token Pattern - per link/action - queue based expiry

We Can Also Implement CSRF Protection on the Server

Changing code on existing applications is hard

What if we asked the server to do CSRF protection

Tomcat 7 Includes a CSRF Prevention Filter

Generates a new UUID for each page loaded - default generator is java.security.SecureRandom)

Protects GET and POST - modifies links and form actions

Stores the last n UUIDs in the session - default for n is 5

http://server/page?org.apache.catalina.filters.CSRF_NONCE=31ACB2CA0A9...

link=nonce1

Tomcat's CSRF Prevention Filter Can Cause Usability Issues for User's With Multiple Browser Tabs Open

User opens a second tab (same session, same cookies, etc.)

Makes n mouse clicks (default n is 5)

Original tab is now broken

nonce2nonce3nonce4nonce5nonce6

nonce1

F5's ASM Can Insert a Token in All Links and Forms to Implement the Synchronizer Token Pattern

F5's ASM Can Insert a Token in All Links and Forms to Implement the Synchronizer Token Pattern

Will protect all GET and POST requests

Token are generated per session, and have an expiry time (configurable from 1-99999 seconds). Default is 600 seconds

Obvious problem of timeouts

Imperva SecureSphere Can Detect CSRF Attacks by Checking the Referrer Header

SecureSphere (Imperva's WAF) can alert and block when the referrer header of a request is from an external site

GET /services/transfer.jsp HTTP/1.1Host: mybank.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0Accept-Language: en-US,en;q=0.5Referer: http://t.co/xblu14l6vLCookie: JSESSIONID=007f0100547a514c54060044;

Imperva SecureSphere Can Detect CSRF Attacks by Checking the Referrer Header

The referrer header is not respected in all situations

Bookmarks, links from external sites, and plugins that stop or tamper with the referrer header can all cause false positives

All Three Of The Servers We Looked At Do CSRF Defense Differently

Synchronizer Token Pattern - Queue based expiry

Synchronizer Token Pattern - Time based expiry

Check Referrer Header - Is intended for detection, not prevention

CSRF Token Names Can Reveal What Library You Are Using



Tomcat

513 results

CSRFGuard

126,000 results


Almost all of the solutions we've mentioned that use tokens allow you to customize the name of the token

Some require you to edit source code to do it...

A single XSS flaw makes all of these CSRF defenses useless

There are numerous ways for a script to access the CSRF token value

document.cookiedocument.getElementByID('csrftoken')document.forms[0].elements[0]

Protecting GET Requests Comes At A Cost

GET /page HTTP/1.1Host: othersite.comReferer: http://mysite.com/page?CSRF_TOKEN=1ba5690d4ea45fbab3

CSRF tokens can be leaked through the referer header, and can be reused if they're still valid

We Have Seen Seven Widely Used Implementations of CSRF Defense

Know your defenses which solution you select will depend on your application

How many of these solutions were perfect?

Security is rarely 'plug n play'

We Have Seen Seven Widely Used Implementations of CSRF Defense

Know your defenses which solution you select will depend on your application

Environment and language used

Whether this is a new app or a retrofit of an old one

Idempotence

Potential user impact of some solutions


Ari Elias-Bachrach

[email protected]@angelofsecurity

Defensium llchttp://www.defensium.com


csrf not-all-defenses-are-created-equal

Technology