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

CSRF

Recall: Session using Cookies Browser Server POST/login.cgi r o a t c i n t e h t u a e : i o k o c t - e S G E T … C o o k i e : a u t h e n t i c a t o r e s n o p s e r

How it works 3 - form is submitted on bank.com 4 - bank.com helpfully transfers money into trout’s account 2 - evil.fish includes form on bank.com 1-user goes to evil.fish

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/