Transcript Cross Site Request Forgery New Attacks and Defenses

Cross Site Request Forgery
New Attacks and Defenses
Collin Jackson
Stanford University
[email protected]
(206) 963-0724
OWASP
Joint work with Adam Barth and John C. Mitchell
6/25/2008
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org
Outline
CSRF Defined
Attacks Using Login CSRF
Existing CSRF Defenses
CSRF Defense Proposal
Conclusions And Advice
OWASP
Cross-Site Request Forgery (CSRF)
 In late 2007 Gmail had CSRF vulnerability.
 In CSRF attack, a malicious site instructs a
victims browser to send a request to an honest site,
as if the request were part of the victim’s interaction
with the honest site, leveraging the victim’s network
connectivity and the browser’s state, to disrupt the
integrity of the victim’s session
OWASP
Threat Models
Forum Poster
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
OWASP
Threat Models
Forum Poster
Websites such as forums let users to submit passive
contents such as images or hyperlinks.
Eg: The attacker could craft a HTML image element
that references victim's bank site (instead of image
element).
<img src =
"http://bank.example.com/withdraw?account=bob&amount=
1000000&for=Fred">
OWASP
Threat Models
Web Attacker
The attacker owns a domain name e.g attacker.com,
has a valid HTTPS certificate and operates a web
server.
If a user visits this website, the attacker could mount
a CSRF attack by instructing the browser to issue
cross-site requests using both the GET and POST
methods.
OWASP
Threat Models
Network Attacker
The attacker controls the user's network connection.
A compromised DNS server can be exploited by the
attacker to control the user's network.
OWASP
Cross-Site Request Forgery
OWASP
Login CSRF
OWASP
Payments Login CSRF
1. The victim visits a malicious merchant’s site
and chooses to pay using PayPal.
2. As usual, victim is redirected to PayPal and
logs into his or her account.
3. The merchant silently logs the victim into his
or her PayPal account.
4. To fund her purchase, the victim enrolls his or
her credit card, but the credit card has actually
been added to the merchant’s PayPal account.
OWASP
Payments Login CSRF
OWASP
Payments Login CSRF
OWASP
Payments Login CSRF
OWASP
Payments Login CSRF
OWASP
Inline Gadgets
OWASP
CSRF Defenses
Secret Validation Token
<input type=hidden value=23a3af01b>
Referer Validation
Referer: http://www.facebook.com/home.php
Custom HTTP Header
X-Requested-By: XMLHttpRequest
OWASP
Secret Validation Token vs. Attacker
Session ID
Session-Independent Nonce (Trac)
Session-Dependent Nonce (CSRFx, CSRFGuard)
HMAC of Session ID
OWASP
Session ID
The user's session identifier is used as the
secret validation token.
On every request the server validates if the
token matches the session identifier.
Disadvantage is that anyone who reads the
contents of the page, which contains the
user's session identifier in the form of CSRF
token, can impersonate the user till the
session expires
OWASP
Session-Independent Nonce
Instead of using the user’s session identifier,
the server stores a random nonce as a cookie
when the user first visits the site.
On every request the server validates that the
token matches the value stored in the cookie.
Disadvantage is that an active network
attacker can overwrite the session
independent nonce with his or her own CSRF
token, even if the web application is hosted
on the HTTPS.
OWASP
Session-Dependent Nonce
As a refinement of nonce technique, the
server stores the state that binds the user's
CSRF to the user's session identifier.
On every request the server validates that the
supplied CSRF token is associated with the
user's session identifier.
Disadvantage is that the server needs to
maintain a large state table to validate the
tokens.
OWASP
HMAC of Session ID
 Instead of using serverside state to bind the
CSRF token to the session identifier,the site
can use cryptography to bind the two values.
HMAC ensures that an attacker who learns
the user's CSRF token cannot infer the user's
session identifier.
OWASP
Referer Validation
When the browser issues an HTTP request, it
includes a referer header that indicates which
URL initiated the request.
This information in the Referer header could
be used to distinguish between same site
request and cross site request.
OWASP
Referer Validation
Privacy Issues with Referer header
The referer contains senstive information that
impinges on the privacy
The referer header reveals contents of the search
query that lead to visit a website.
Some organizations are concerned that
confidential information about their corporate
intranet might leak to external websites via
Referer header
OWASP
Referer Validation

Referer: http://www.facebook.com/

Referer: http://www.evil.com/attack.html
?
Referer:
 Lenient Referer checking – header is optional
 Strict Referer checking – header is required
OWASP
Referer Validation
 Lenient Referer Validation
The site blocks request whose referer header has
incorrect value
If the request lacks the header then the site
accepts the request.
Eg. Request issued from ftp and data URLs do
not carry Referer headers.
OWASP
Referer Validation
 Strict Referer Validation
The site blocks the request whose referer
header has incorrect value and also blocks
request that lack a referer header.
Disadvantage is that some browsers and
network configurations suppress referer
header for legitimate requests.
OWASP
Is Strict Referer Checking Feasible?
OWASP
Custom Header
Browsers prevent sites from sending custom
HTTP headers to another site but allow sites to
send custom HTTP headers to themselves.
Cookie value is not actually required to prevent
CSRF attacks, the mere presence of the header is
sufficient.
To use this scheme as a CSRF Defense, a site
must issue all state modifying requests using
XMLHttpRequest, attach the header and reject all
requests that do not accompany the header .
OWASP
Proposal: Origin Header
Privacy
Server Behavior
Security Analysis
OWASP
Conclusions And Advice
Login CSRF
 Strict Referer/Origin header validation
 Login forms typically submit over HTTPS, not blocked
HTTPS sites, such as banking sites
 Use strict Referer/Origin validation to prevent CSRF
Other
 Use Ruby-on-Rails or other framework that implements secret
token method correctly
Origin header
 Alternative to Referer with fewer privacy problems
 Sent only on POST, sends only necessary data
 Defense against redirect-based attacks
OWASP