Cross-site Request Forgery (CSRF) and Confused Deputies

The slides themselves are creative commons licensed CC-BY-SA, and images used are licensed as individually attributed.

Topics covered in this lecture include:

Cross-Site Reference Forgery (CSRF), also known as...
XSRF
"Sea Surf"
Session Riding
Hostile Linking
One-click attack (Microsoft)
Cross-site request forgery (CSRF): What it is
Unauthorised commands are sent by a user, without their knowledge or understanding
Typically the user is already logged in to a website in their web browser, and an event causes the user’s browser to send a request
HTTP/S requests will automatically send session cookies etc
The request is treated as though it was sent on the users behalf
Cross-site request forgery (CSRF)
Attackers focus on triggering HTTP/S requests that have side effects / AKA state changing requests
Vulnerable if there is no additional authorisation required
Cross-site request forgery (CSRF)
The attack is blind: can’t leak information directly
Unless there is a XSS vulnerability in the target website
A user can be tricked
Trick the browser
A website can trick the browser into sending a request
Image tags, iframes, and other HTML elements that load via HTTP requests
JavaScript
XMLHttpRequests
Hidden forms
Stored CSRF flaws: when you can store the CSRF attack on the vulnerable website
Confused deputy problem
Confused deputy problem: when software is given privileges, and is tricked into misusing them
Clickjacking, and FTP bounce attacks, are examples where remote machines can be tricked into acting on behalf of others
CSRF is a confused deputy attack against a web browser
Ambient authority
In access controls, ambient authority refers to whenever access is granted without being provided reference to the privilege that is required in order to access the resource
Most modern systems have ambient authority
At any time the system can use more privileges than those required for specific tasks
For example, all requests considered in terms of
Users (ACLs, etc)
Sessions
HTTP GET requests
GET requests have parameters embedded in URLs
Officially GET requests shouldn’t make any state changes (although it’s not uncommon)
Attack:
HTTP POST requests
POST requests have parameters sent along as a query string
POST requests were once thought to be safe from CSRF…
Unlike with GET, its not just a matter of sending a link
However, POST requests can be triggered by:
Having the victim submit a crafted HTML form
Javascript: trigger form submit, or XMLHttpRequest
Other HTTP methods
PUT/DELETE/…
SOP will provide protection (unless disabled in headers)
CSRF examples: ING Direct
Online banking: ING Direct allowed money transfers!
CSRF examples: Facebook CSRF flaw
CSRF examples: Even more examples...
Netflix CSRF that could alter login credentials to compromise accounts
Youtube had a CSRF vulnerability that could enable almost any action
CSRF Prevention: Client
Don’t click links or visit websites you don’t trust
Clients can restrict requests / scripts etc, but it will break access to many websites
Logout and clear cookies more often
CSRF Prevention: Server
Server should check the headers
Have values sent along with the requests that are authorised, which an attacker cannot guess
Most defenses embed authentication tokens into requests
CSRF Prevention: Server...
Many frameworks include CSRF defenses that can be used or enabled
CSRF tokens: Form Keys AKA Synchronizer token pattern (STP)
Random tokens are embedded in all HTML forms, checked server side
Can also embed tokens in URLs, but is vulnerable since these are exposed via referrer headers, etc
For example, this approach is used by Drupal
CSRF tokens “Cookie to Header”
“Cookie to Header”
Relies on same-origin to protect the token
Copies the cookie to a custom HTTP header
An attacker can’t guess the token to also place it in the header
Used by various JS frameworks (such as AngularJS)
CSRF Prevention: Server and XSS
XSS on the same domain can circumvent all of the above defenses against CSRF
Javascript can read all randomly generated tokens, and craft a CSRF attack that circumvents these
CSRF Prevention: User interaction
Should not simply be multi-step, if the attacker can guess the steps
Challenge-response defenses
Re-authentication
Captcha
One-time passwords / authentication tokens
A strong defense, but affects UX
A second confirmation step could confirm details, with a generated CSRF token
For example, Paypal confirmation dialogue
Detection
Requests come from the victim’s IP address, so unless mitigations are designed in advance it may not be possible to differentiate from legitimate requests from users