CSRF Recall: Session using Cookies Browser Server POST/login.cgi - - PowerPoint PPT Presentation

CSRF

Recall: Session using Cookies

Server Browser POST/login.cgi S e t

• c
• k

i e : a u t h e n t i c a t

• r

G E T … C

• k

i e : a u t h e n t i c a t

• r

r e s p

• n

s e

How it works

1-user goes to evil.fish

2 - evil.fish includes form on bank.com

3 - form is submitted

• n bank.com

4 - bank.com helpfully transfers money into trout’s account

Cross Site Request Forgery

• Example:
• User logs in to bank.com
• Session cookie remains in browser state
• User visits another site containing:

<form name=F action=http://bank.com/BillPay.php> <input name=recipient value=badguy> … <script> document.F.submit(); </script>

• Browser sends user auth cookie with request
• Transaction will be fulfilled
• Problem:
• Cookie auth is insufficient when side effects occur

Ineffective CSRF Defense: POST

• GET requests are easier to launch CSRF attacks,

so some people naively switch to POSTs

• This does not help

Ineffective Defense: URL Rewriting

• CSRF exploits work because cookies are used for

authentication

• So why not encode the authentication token in the URL

instead?

• Assuming token is random, this protects against CSRF

attacks

• But: dangerous to pass auth tokens in URLs

(middleperson, logging issues)

Imperfect Defense: Referer Validation

Referer Validation Defense

• HTTP Referer header
• Referer: http://www.facebook.com/
• Referer: http://www.attacker.com/evil.html
• Referer:
• Lenient Referer validation
• Doesn't work if Referer is missing
• Strict Referer validaton
• Secure, but Referer is sometimes absent…

Referer Privacy Problems

• HTTP Referer may leak privacy-sensitive information
• REFERER: http://intranet.corp.apple.com/projects/iphone/

competitors.html

• Common sources of blocking:
• Network stripping by the organization
• Network stripping by local machine
• Stripped by browser for HTTPS -> HTTP transitions
• User preference in browser
• Buggy user agents
• Site cannot afford to block these users

Defenses

• Form keys
• CSRF tokens
• Short cookie expiration date
• Encourage users to log out

CSRF Token

• Requests include a hard-to-guess secret
• Unguessability substitutes for unforgeability
• Variations
• Session identifier
• Session-independent token
• Session-dependent token
• HMAC of session identifier

Token Validation

Token Validation

Blocking an Attack

Double-Submitted Cookies

• Secret tokens are great, but they require the server to

maintain state for every session

• Solution: double-submitted cookie!
• Instead of writing separate nonce, re-use the session ID
• When server replies to user, writes session ID to cookie

as usual, plus writes into hidden form field

• User posts form with value from hidden field and

cookie, server verifies these are same

Double-Submitted Cookies

• Why does this defense work?
• Attacker cannot reliably guess session ID (unless

there is also an XSS vuln)

• Solution is completely stateless
• Downside: passing session IDs in HTTP requests and

responses is risky

• Solution: put hash(session ID) in hidden form field

instead

Exercise

• https://google-gruyere.appspot.com/