CSRF

Cross Site Request Forgery

Cross SIte Request Forgery


Making a request on behalf of a user without their consent or knowledge

CROSS SITE REQUEST FORGERY


Requires some degree of social engineering.

But you already know that, don't you?

Cookies

Alice authenticates with http://example.com

Server sends back a cookie:
ASPSESSID = akj32uad980wa4rlmaf9034
This is sent up with every request to example.com

Server looks at cookie, and uses that session

Cookies


The referer [sic] doesn't matter! 

Where the request is going to is the important thing

Cookies


Cookies are NOT the problem

Trusting automatic behaviour is!

NTLM


Alice goes to http://example.com

Server sends a CHALLENGE_MESSAGE

Client responds with an AUTHENTICATE_MESSAGE

Server uses this to authenticate the request

NTLM


This is automatic, using the current windows session

The request is important, not the referer

Exploit


Simply make a request to a site that the user has an authenticated session with!

Example

<see example>

Possibilities

Add or elevate users to admin roles

Delete stuff

Create malicious resources 
(eg. Rich Text Objects with scripts)

imPossibilities

Read bank statement information

Screen scrape


Limitations - write only

Requests can be GET or POST

If request uses GET, the data cannot be read programatically cross-domain

<img src="http://mybank.com/balance.png" />

Limitations - no XHR

Same limitations as always

No cross-domain XHRs 
unless specifically allowed by server

limitations - no timing


Queuing requests is a guessing game

Eg. 
Adding a user
Making them admin

Protection

A separate authentication token for write requests

Protection

Alice authenticates with http://example.com

Server responds with cookie
ASPSESSID=l23j45093ifdpm34r0

Server stores in session
CSRF=klj45983uf0934nocn834

Server sends key down
<input type="hidden" name="CSRF" value="klj45983uf0934nocn834" />

Protection

Alice creates a user

Request is constructed:
  URL: http://example.com/add-user
  Data:  user=jane&CSRF=klj45983uf0934nocn834
  Cookie: ASPSESSID=l23j45093ifdpm34r0

Server opens the session, compares the CSRF token, sees it's good and does its thing

Protection

Bob tells Alice to go to http://dr-nefarious.com

Malicious site sends a request to
  URL: http://example.com/add-user
  Data:  user=jane
  Cookie: ASPSESSID=l23j45093ifdpm34r0

Server rejects the request

Hardening

Regenerate session every login

Avoid long-lasting logins

Regenerate CSRF tokens frequently

How do we fare - safe bits

Anything using StatePocketKey

Anything relying on the PageKey 

Actions marked with POST that use View States
(specifically, view state keys)

How do we fare - UNsafe bits

Webforms

Actions that don't require Viewstate

SOAP Web Services (possibly)
Made with Slides.com