Cross Site Request Forgery New Attacks and Defenses Collin Jackson Stanford University collinj@cs.stanford.edu (206) 963-0724 Joint work with Adam Barth and John C. Mitchell 6/25/2008

Outline CSRF Defined Attacks Using Login CSRF Existing CSRF Defenses CSRF Defense Proposal Identity Misbinding

Threat Models Forum Poster Web Attacker Network Attacker Injects content onto trusted site Sanitized (hopefully) Web Attacker Owns https://www.attacker.com Free user visit Network Attacker Eavesdrop/corrupt normal traffic Cannot eavesdrop/corrupt HTTPS

Browser vs. Web Attacker Isolate sites Sites can opt in to sharing information Prevent attacker from Abusing user’s IP address Reading browser state associated with other sites Writing browser state associated with other sites

Browser Security Policy Same-origin policy <iframe src="http://www.bank.com/"> <script> alert(frames[0].document.cookie); </script> Library import <script src="https://www.verisign.com/seal.js"> Data export <form action="https://www.bank.com/login">

Problems with Data Export Abusing user’s IP address Can issue commands to servers inside firewall Reading browser state Can issue requests with cookies attached Writing browser state Can issue requests that cause cookies to be overwritten “Session riding” is a misleading name

Cross-Site Request Forgery

Login CSRF

Payments Login CSRF

Payments Login CSRF

Payments Login CSRF

Payments Login CSRF

Inline Gadgets

Using Login CSRF for XSS

Post-XSS

Secret Validation Token CSRF Defenses Secret Validation Token Referer Validation Custom HTTP Header <input type=hidden value=23a3af01b> Referer: http://www.facebook.com/home.php X-Requested-By: XMLHttpRequest

Secret Validation Token vs. Web Attacker Hash of User ID Attacker can forge Session ID Save to HTML does allow session hijacking Session-Independent Nonce (Trac) Can be overwritten by subdomains, network attackers Session-Dependent Nonce (CSRFx, CSRFGuard) Requires managing a state table HMAC of Session ID No extra state required <input type=hidden value=23a3af01b>

Keeping Secrets in NoForge Parses HTML and appends token to hyperlinks Dynamically created HTML lacks token Legacy application may break unexpectedly Token appended to all external links Remote site can immediately CSRF referrer No login CSRF defense Requires a session before token is validated

  ? Referer Validation Referer: http://www.facebook.com/ Lenient Referer checking – header is optional Strict Referer checking – header is required Referer: http://www.facebook.com/  Referer: http://www.evil.com/attack.html ? Referer:

Why use Lenient Referer Checking? Referer may leak privacy-sensitive information 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

Lenient Referer Checking vs. Web Attacker ftp://www.attacker.com/index.html javascript:"<script> /* CSRF */ </script>" data:text/html,<script> /* CSRF */ </script> … and many more Lenient Referer Checking is not secure! Don’t use it!  Referer: M. Johns '06

Is Strict Referer Checking Feasible? 283,945 advertisement impressions from 163,767 IP addresses

XMLHttpRequest is for same-origin requests Custom Header XMLHttpRequest is for same-origin requests Can use setRequestHeader within origin Limitations on data export format No setRequestHeader equivalent XHR2 has a whitelist for cross-site requests Issue POST requests via AJAX: No secrets required X-Requested-By: XMLHttpRequest

Can browsers help sites with CSRF? Does not break existing sites Easy to use Allows legitimate cross-site requests Reveals minimum amount of information No secrets to leak Standardized

Proposal: Origin Header Privacy Identifies only principal that initiated the request (not path or query) Sent only for POST requests; following hyperlink reveals nothing Usability Authorize subdomains and affiliate sites with simple firewall rule No need to manage secret token state Can use redundantly with existing defenses to support legacy browsers Standardization Supported by W3C XHR2 and JSONRequest Expected in IE8’s XDomainRequest SecRule REQUEST_HEADERS:Host !^www\.example\.com(:\d+)?$ deny,status:403 SecRule REQUEST_METHOD ^POST$ chain,deny,status:403 SecRule REQUEST_HEADERS:Origin !^(https?://www\.example\.com(:\d+)?)?$

User is logged in to trusted site as attacker Identity Misbinding User is logged in to trusted site as attacker Does not always require login CSRF OpenID PHP Cookieless Authentication “Secure” cookies

Web Attacker vs. OpenID

Web Attacker vs. PHP Cookieless Authentication

Network Attacker vs. “Secure” Cookies Need a browser-based solution Cookie-Integrity Mitigation: Don’t allow self-XSS over HTTPS

Conclusions Beware of: OK: State-modifying GET requests Login CSRF Lenient Referer checking Sloppy secret token validation OpenID without binding to browser PHP cookieless authentication User opt-in to self-XSS (especially over HTTPS) OK: Careful secret token validation Strict Referer checking over HTTPS Custom headers