Cross-Site Request Forgery: New Attacks and Defenses

Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

OWASP

http://www.owasp.org

Cross Site Request ForgeryNew Attacks and Defenses

Collin JacksonStanford Universitycollinj@cs.stanford.edu(206) 963-0724

Joint work with Adam Barth and John C. Mitchell

6/25/2008

OWASP

Outline

CSRF Defined

Attacks Using Login CSRF

Existing CSRF Defenses

CSRF Defense Proposal

Identity Misbinding

OWASP

Threat Models Forum Poster

Injects content onto trusted siteSanitized (hopefully)

Web AttackerOwns https://www.attacker.comFree user visit

Network AttackerEavesdrop/corrupt normal trafficCannot eavesdrop/corrupt HTTPS

OWASP

Browser vs. Web Attacker

Isolate sites

Sites can opt in to sharing information

Prevent attacker fromAbusing user’s IP addressReading browser state associated with other

sitesWriting browser state associated with other

sites

OWASP

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">

OWASP

Problems with Data Export

Abusing user’s IP addressCan issue commands to servers inside firewall

Reading browser stateCan issue requests with cookies attached

Writing browser stateCan issue requests that cause cookies to be

overwritten

“Session riding” is a misleading name

OWASP

Cross-Site Request Forgery

OWASP

Login CSRF

OWASP

Payments Login CSRF

OWASP

Payments Login CSRF

OWASP

Payments Login CSRF

OWASP

Payments Login CSRF

OWASP

Inline Gadgets

OWASP

Using Login CSRF for XSS

OWASP

Post-XSS

OWASP

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

OWASP

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 IDNo extra state required

<input type=hidden value=23a3af01b>

OWASP

Keeping Secrets in NoForge

Parses HTML and appends token to hyperlinks

Dynamically created HTML lacks tokenLegacy application may break unexpectedly

Token appended to all external linksRemote site can immediately CSRF referrer

No login CSRF defenseRequires a session before token is validated

OWASP

Referer Validation

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:

OWASP

Why use Lenient Referer Checking?

Referer may leak privacy-sensitive informationhttp://intranet.corp.apple.com/projects/iphone/competitors.html

Common sources of blocking:Network stripping by the organizationNetwork stripping by local machineStripped by browser for HTTPS -> HTTP transitionsUser preference in browserBuggy user agents

Site cannot afford to block these users

OWASP

Lenient Referer Checking vs. Web Attacker

ftp://www.attacker.com/index.htmljavascript:"<script> /* CSRF */ </script>"data:text/html,<script> /* CSRF */ </script>

… and many more

Lenient Referer Checking is not secure!Don’t use it!

M. Johns '06

Referer:

OWASP

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

OWASP

Custom Header

XMLHttpRequest is for same-origin requestsCan use setRequestHeader within origin

Limitations on data export formatNo setRequestHeader equivalentXHR2 has a whitelist for cross-site requests

Issue POST requests via AJAX:

No secrets required

X-Requested-By: XMLHttpRequest

OWASP

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

OWASP

Proposal: Origin Header

Origin: http://www.evil.com 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+)?)?$

OWASP

Identity Misbinding

User is logged in to trusted site as attacker

Does not always require login CSRF

OpenID

PHP Cookieless Authentication

“Secure” cookies

OWASP

Web Attacker vs. OpenID

OWASP

Web Attacker vs. PHP Cookieless Authentication

OWASP

Network Attacker vs. “Secure” Cookies

Need a browser-based solution

Cookie-Integrity

Mitigation: Don’t allow self-XSS over HTTPS

OWASP

Conclusions

Beware of: 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