Scribd
Upload
155 views

Cross-Site Request Forgery: Collin Jackson

This document discusses cross-site request forgery (CSRF) and potential defenses. It outlines classic CSRF attacks where a user is unknowingly tricked by a malicious site into performing actions on another site where they are currently logged in. Common defenses discussed include using secret validation tokens, referer header validation, and custom headers. However, each defense has limitations. Advanced attacks are also described that extend beyond simple "session riding." The document concludes that while client-side changes from browsers could help, server-side defenses are ultimately required, though retrofitting existing applications can be difficult.

Uploaded by

Ade Haryanto Sagala
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
155 views

Cross-Site Request Forgery: Collin Jackson

This document discusses cross-site request forgery (CSRF) and potential defenses. It outlines classic CSRF attacks where a user is unknowingly tricked by a malicious site into performing actions on another site where they are currently logged in. Common defenses discussed include using secret validation tokens, referer header validation, and custom headers. However, each defense has limitations. Advanced attacks are also described that extend beyond simple "session riding." The document concludes that while client-side changes from browsers could help, server-side defenses are ultimately required, though retrofitting existing applications can be difficult.

Uploaded by

Ade Haryanto Sagala
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

CS 142 Winter 2009

Cross-site request forgery

Collin Jackson
Outline

Classic CSRF
Server-side Defenses
Advanced Attacks
Proposals for client-side changes
Data export
Many ways to send information to other
origins
<formaction="http://www.b.com/">
<inputname="data"type="hidden"value="hello">
</form>

<imgsrc="http://www.b.com/?data=hello"/>

No user involvement required


Cannot read back response
Classic CSRF attack
User visits victim site site
Logs in
User loads attacker's site
Or encounters attacker's
iframe on another site
Attacker sends HTTP requests to victim
Victim site assumes
requests originate
from itself
Classic CSRF Attack

Cookie: SessionID=523FA4cd2E

User credentials
DEFENSES
CSRF Defenses
Secret Validation Token
<inputtype=hiddenvalue=23a3af01b>

Referer Validation
Referer:http://www.facebook.com/home.php

Custom HTTP Header XRequestedBy:XMLHttpRequest


Secret Token Validation
Requests include a hard-to-guess secret
Unguessability substitutes for unforgeability
Variations
Session identifier
Session-independent token

Session-dependent token

HMAC of session identifier

See "Robust Defenses for Cross-Site Request Forgery" for a comparison of


these options.
Secret Token Validation
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
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


Suppression Measurement
283,945 impressions
Suppression over HTTPS is low
Lenient Validation Vulnerability
My site uses HTTPS, am I safe?
Problem: Browsers do not append
Referer if the source of the request is
not an HTTP page

ftp://attacker.com/attack.html
data:text/html,<html></html>
javascript:'<html></html>'
Strict Validation Problems
Some sites allow users to post forms
XSS sanitization doesn't include <form>
These sites need another defense

Many sites allow users to post


hyperlinks
Solution: Respect HTTP verb semantics
GET requests have no side effects

POST requests can change state


Custom Header Defense
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:


XRequestedBy:XMLHttpRequest

Doesn't work across domains


ANNOUNCEMENTS

Project 2, Mac OSX Tiger


ADVANCED ATTACKS
Broader view of CSRF
Abuse of cross-site data export feature
From users browser to honest server
Disrupts integrity of users session

Why mount a CSRF attack?


Network connectivity
Read browser state

Write browser state

Not just session riding


Login CSRF

Attackers
credentials
Payments Login CSRF
Payments Login CSRF
Payments Login CSRF
Payments Login CSRF
Rails vs. Login CSRF
Login CSRF Fails
CLIENT-SIDE DEFENSES
Can browsers help with CSRF?

Does not break existing sites


Easy to use
Hard to misuse
Allows legitimate cross-site requests
Reveals minimum amount of information
Can be standardized
Proposed Approaches

HTTP Headers
Identify the source of requests
Change Referer header or add a new Origin header
Send more information for POST than GET
Experiment: Cross-domain POSTs out of firewall accounted for
~0.0001% of traffic
Problem: Unsafe GET requests
Problem: Third-party content within an origin
Problem: How to handle redirects

Same-origin-only cookies
Doesn't help multi-domain sites: amazon.com and amazon.co.uk
These sites could use other defenses
Conclusion

Server-side defenses are required


Secret token validation use frameworks like Rails
Referer validation works over HTTPS
Custom headers for AJAX

No easy solution
User does not need to have an existing session for attacks to work
Hard to retrofit existing applications with defenses

You might also like