CSRF: Not All Defenses Are Created Equal Not All Defenses Are Created Equal 47 Tomcat 7 Includes a...

CSRF: Not All Defenses Are Created Equal 1

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

<form action=submitpage> <input name= amount type=text> <input name=dest type=text> <input type=submit value=Transfer></form>


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

<img src=”...”>

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

<form name=”evil” action=”http://server.com/submitpage” action=POST> <input type=”hidden” name=”amount” value=”100.00”> <input type=”hidden” name=”dest” value=”12345”></form><script>document.evil.submit()</script>


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

<html>Malicious code

Legitimate siteSession 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

<input type="hidden" name="FromEmail" value="[email protected]" /> <input type="hidden" name="Subject" value="Do something wild" /> <input type="hidden" name="GUID" value="0f41d8e54aa80b3193c28ed920" />

14

Primary Defense is the Synchronizer Token Pattern

The most common defense


Things to look out for

- How are tokens remembered?

- Completeness of coverage

15

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

16

Second Defensive Option is Double Submit Cookies

This option used less often, but useful for things like REST

<input> abc123

abc123

abc123 <input>=abc123


Things to look out for:

- Do not use the Session ID for this purpose!

17

Second Defensive Option is Double Submit Cookies

This option used less often, but useful for things like REST

<input> 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 Fixes Server Fixes


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

1. ViewState User Keys (.net)

2. AntiForgeryToken (.net MVC)

3. AntiCSRF (.net)

4. CSRFGuard (Java, PHP port is in progress)

5. HDIV (Java)


.net can add CSRF protections to the ViewState

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

Page.aspxPage.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.aspxOther.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



<% using(Html.Form("UserProfile", "SubmitUpdate")) { %>

<%= Html.AntiForgeryToken() %>



<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZ" />



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 POST

Not a problem if GET is idempotent

Can be hacked to work, google for details



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

<input> abc123

abc123




Can be used in a .net web app

New Token for each session

Only protects POST (not a problem if GET is idempotent)

- Won't work for Rest (unless you hack it)

<input> 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 requests

Keeps 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 value

Stored in session

Feature is still experimentallink=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


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 brokennonce2nonce3nonce4nonce5nonce6

nonce1


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

<form action=”foo”> <a href=”bar”>

<form action=”foo”><input type=”hidden”

value=”12345”>

<a href=”bar?csrt=12345”>


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

Date post:	29-Mar-2018
Category:	Documents
Upload:	trinhthu
View:	233 times
Download:	5 times

CSRF: Not All Defenses Are Created Equal Not All Defenses Are Created Equal 47 Tomcat 7 Includes a...

Documents