Understanding Cross-site Request Forgery

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Understanding
Cross-site
Request Forgery
Daniel Miessler
Principal Security Architect, HP Fortify
May 2013

Daniel Miessler, CISSP, CISA, GCIA
Principal Security Architect, HP Fortify
- 10 years experience doing security testing
- 5 years experience doing appsec testing
- Web Application Vulnerability Assessments
- Mobile Application Vulnerability Assessments
- Application Security Process Development
- Enterprise Security Consulting
daniel.miessler@hp.com
Introductions

Agenda
- Problem
- Basics
- Description
- Validation
- Defenses
- Attack Vectors
- CSRF Tester
- Takeaways

Problem

Problem | Overview
 CSRF is an OWASP Top 10 vulnerability but it’s not as
well understood as many others
 Many struggle with how to validate it
 Customers have difficulty explaining to management
why it’s important to fix
 We need to be well-versed in the main points to help
the customer with their narrative to management

Basics

Basics | Overview
 Often abbreviated as “CSRF” and pronounced as
“Sea Surf”
 #5 on the 2010 OWASP Top 10
 #8 on the 2013 OWASP Top 10

Basics | Description
“Cross-site Request Forgery is a
vulnerability in a website that allows
attackers to force victims to perform
security-sensitive actions on that site
without their knowledge.”

Let’s unpack that.

 What do we mean by “sensitive actions”?
 How do attackers “force” victims to perform
them?
 And how do the victims not know it’s
happening?

1. The target is a sensitive operation in the
application, e.g. UpdateSalary.aspx, that’s able to
be tricked into executing.
2. Victims can be forced to execute this action through
any method that gets them to load a resource
automatically, e.g. img tag, script tag, onload form
submit, etc. Note: credentials go with all requests!
3. These happen unknowingly because the actions are
performed by the victim’s browser, not by the victim
explicitly.

Sensitive action examples:
 /EditDocument.aspx
 /Login.do
 /CreateAdmin.php
 /UpdateStatus/
Basics | Examples

Forcing the victim to execute the action
(GET):
- <img
src=“http://site.com/transfer.php?fromac
ct=2042&toacct=4497 /> (GET)
Basics | Forced POSTs

Forcing the victim to execute the action
(POST):

Both XSS and CSRF are possible due to abused
trust relationships:
 In XSS the browser will run malicious JavaScript because it was served
from a site (origin) it trusts.
 In CSRF the server will perform a sensitive action because it was sent
by a client that it trusts.
Basics | Trust Abuse

Validation

Validation | Criteria
If you can’t change something using your CSRF
vulnerability, then you don’t have one.
Examples of state changes:
- Updating an account (new password?)
- Transferring funds
- Changing the role of a user
- Ordering an item
- Adding an administrator to a system

If your CSRF vulnerability doesn’t change
something sensitive, then you might not have
one.
Note: sensitivity is a…sensitive matter. Who is it
sensitive to? Could it be sensitive to some and
not others?
 Many changes are insignificant
 Remember that if the business understands the technical
risk then they automatically win the “what matters”
argument

If requests for your CSRF vulnerability are
unique, you might not have one.
Things to check for uniqueness:
- Nonces
- CAPTCHA
- Multiple authentication levels

The three components again…
1. Can you change state using it?
2. Is the function sensitive?
3. Is the request non-unique?
 This is the core of the validation process
 Any customer asking you to validate a CSRF
vulnerability should hear and learn these same
concepts

Validation | WebInspect
How WebInspect identifies CSRF:
1. Log in to the site
2. Complete a form and generate post request with current session
cookies
3. If response is 30X, follow the redirection (with current session
cookies) until the non-30x response is reached. This is response #1
(R1)
4. Log out and log in the site with different credentials (note session
cookies should be changed here)
5. Resend the same POST request as in step 2, but with the new
cookies
6. If necessary, follow redirects per step 3
7. Note the response as R2
8. If R1==R2, then it’s a non-unique request and therefore is CSRF-able

Validation | Manual Validation
How to manually verify CSRF:
1. Configure a proxy to observe traffic
2. Log in to the site with the issue in question
3. Perform the target functionality normally, through the browser
4. Observe the request, looking for state change, sensitivity, and
uniqueness
5. Look for any additional controls that could stop CSRF, such as
CAPTCHA or additional authentication
6. Log out and log in with a different set of credentials
7. Submit the initial request from the new context, and see if it is
successful
8. If the action is performed without issue, it is most likely CSRF
9. Remember that the issue must also satisfy the state change and
sensitivity requirements. Non-uniqueness is not enough.

Validation | Caution with Automation
Don’t trust the claims from tools. They’re often
right, but they’re only guessing at sensitivity:
 Validation of non-uniqueness doesn’t mean the
action is sensitive, i.e. it could be a “business”
false positive even if it’s valid technically
 CSRF is a high-false-positive vulnerability when
automation is used
 Tools make educated guesses that require
validation of all three criteria

Defense

Defense | Overview
 The primary defense for Cross-site Request
Forgery is creating unique requests that cannot
be easily generated by attackers.
 This is usually accomplished via a nonce (a
number used once).
 CAPTCHAs can also be used, as well as
authentication prompts

Digging In | Nonces
<%
function session_initiate(first_name, last_name /* etc */) {
session.fisrt_name = first_name
session.last_name = last_name
/* etc */
session.form_token = generate_form_token()
}
%>
Then, in the page code:
<%
<form>
<input name=”field1”><br>
<input name=”field2”><br>
<input type=”submit”>
<input name=”form_token” type=”hidden” value=”<%= session.form_token %>”>
</form>
When the form is submitted, the following is executed:
if (post.form_token != session.form_token) {
log_CSRF_attack()
error_and_exit()
}
// normal form handling here

Defense | Nonces
 Nonces make it so that generic requests to
sensitive resources don’t get executed
 This works by providing a one-time-secret
when a legitimate client arrives at a given
location, and then that token (nonce) must be
submitted along with a request to prove that’s
legitimate

Attack Vectors

Attack Vectors | Leveraging XSS
 The key to CSRF defense is that the attacker doesn’t
have access to a valid nonce
 But with XSS present the attacker could force the victim
to make a request to the site, consume the nonce, and
add it to the CSRF request
 This is what the Samy Worm did; he pulled the token first
and used it to submit the (now valid) friend addition

Attack Vectors | SAMY
Step #9 from Samy’s technical description
of his attack:
http://namb.la/popular/tech.html

Digging In | Clarification
Forcing the victim to execute the action (POST):

Attack Vectors | Options
 Take control of a legitimate, well-trafficked but
low priority internal site and post a form that
submits the attack
 Use persistent XSS to inject code on a
vulnerable site, e.g. a forum
 Create a new site internally and entice users
to visit the site via email, etc. (phishing-ish)

CSRF Tester

CSRF Tester | Overview
• CSRF Tester is an
OWASP tool for creating
CSRF PoC code
• It works by capturing you
doing something
sensitive, and then
generating PoC code for
you try in another user
context
• You must set your
JAVA_HOME environment
variable to launch it
• Listens on port 8008

CSRF Tester | Usage
• Send traffic through CSRF
Tester like any other proxy
• Record the execution of a
sensitive action on the site
• You then create a “report”
of a certain
type, Form, iFrame, IMG,
XHR, Link
• That code is now the PoC
for testing to see if it’s a
CSRF issue
• The test is whether or not
it executes from other

Takeaways

Takeaways | Overview
1. CSRF is # 8 on the OWASP Top 10
2. Abuses server’s trust of client
3. Forces user to perform sensitive function
4. Validate by: State-change, Sensitivity, Non-uniqueness
5. Nonces are a common defense
6. XSS can assist CSRF by getting code onto a page and by
bypassing nonce defenses by having the user request a
valid nonce before submitting
7. Single sign-on can magnify CSRF issues
8. Remember that customers are deeply confused by CSRF
and will require constant reinforcement
9. Repetition: State(change)/Sensitivity/Uniqueness (SSU)

Takeaways | Resources
1. https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)_Prevention_Cheat_
Sheet)
2. http://en.wikipedia.org/wiki/Cross-
site_request_forgery
3. https://www.owasp.org/index.php/Category:OWASP_
CSRFTester_Project
4. http://code.google.com/p/pinata-csrf-tool/
5. http://www.threadstrong.com/courses/csrf/

Questions

Understanding Cross-site Request Forgery

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Understanding Cross-site Request Forgery (20)

Recently uploaded (20)

Understanding Cross-site Request Forgery

Editor's Notes