understanding cross-site request forgery

44
© 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

Upload: daniel-miessler

Post on 29-Nov-2014

2.748 views

Category:

Technology


1 download

DESCRIPTION

A description of the web application vulnerability known as Cross-site Request Forgery

TRANSCRIPT

Page 1: 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 MiesslerPrincipal Security Architect, HP FortifyMay 2013

Page 2: Understanding Cross-site Request Forgery

Daniel Miessler, CISSP, CISA, GCIAPrincipal 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

[email protected]

Introductions

Page 3: Understanding Cross-site Request Forgery

Agenda

- Problem

- Basics

- Description

- Validation

- Defenses

- Attack Vectors

- CSRF Tester

- Takeaways

Page 4: Understanding Cross-site Request Forgery

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Problem

Page 5: Understanding Cross-site Request Forgery

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

Page 6: Understanding Cross-site Request Forgery

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Basics

Page 7: Understanding Cross-site Request Forgery

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

Page 8: Understanding Cross-site Request Forgery

Basics | OWASP

Page 9: Understanding Cross-site Request Forgery

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.”

Page 10: Understanding Cross-site Request Forgery

Basics | Description

Let’s unpack that.

Page 11: Understanding Cross-site Request Forgery

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.”

Page 12: Understanding Cross-site Request Forgery

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.”

Page 13: Understanding Cross-site Request Forgery

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.”

Page 14: Understanding Cross-site Request Forgery

Basics | Description

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?

Page 15: Understanding Cross-site Request Forgery

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.

Basics | Description

Page 16: Understanding Cross-site Request Forgery

Sensitive action examples:

/EditDocument.aspx /Login.do /CreateAdmin.php /UpdateStatus/

Basics | Examples

Page 17: Understanding Cross-site Request Forgery

Forcing the victim to execute the action (GET):

- <img src=“http://site.com/transfer.php?fromacct=2042&toacct=4497 /> (GET)

Basics | Forced POSTs

Page 18: Understanding Cross-site Request Forgery

Forcing the victim to execute the action (POST):

Basics | Description

Page 19: Understanding Cross-site Request Forgery

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

Page 20: Understanding Cross-site Request Forgery

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Validation

Page 21: Understanding Cross-site Request Forgery

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

Page 22: Understanding Cross-site Request Forgery

Validation | Criteria

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

Page 23: Understanding Cross-site Request Forgery

Validation | Criteria

If requests for your CSRF vulnerability are unique, you might not have one.

Things to check for uniqueness:

- Nonces- CAPTCHA- Multiple authentication levels

Page 24: Understanding Cross-site Request Forgery

Validation | Criteria

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

Page 25: Understanding Cross-site Request Forgery

Validation | WebInspect

How WebInspect identifies CSRF:

1. Log in to the site2. Complete a form and generate post request with current

session cookies3. 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 37. Note the response as R28. If R1==R2, then it’s a non-unique request and therefore is

CSRF-able9. Remember that you have the vulnerability retest option in

WebInspect

Page 26: Understanding Cross-site Request Forgery

Validation | Manual Validation

How to manually verify CSRF:

1. Configure a proxy to observe traffic2. Log in to the site with the issue in question3. Perform the target functionality normally, through the browser4. Observe the request, looking for state change, sensitivity, and

uniqueness5. Look for any additional controls that could stop CSRF, such as

CAPTCHA or additional authentication6. Log out and log in with a different set of credentials7. Submit the initial request from the new context, and see if it is

successful8. If the action is performed without issue, it is most likely CSRF9. Remember that the issue must also satisfy the state change

and sensitivity requirements. Non-uniqueness is not enough.

Page 27: Understanding Cross-site Request Forgery

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

Page 28: Understanding Cross-site Request Forgery

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Defense

Page 29: Understanding Cross-site Request Forgery

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

Page 30: Understanding Cross-site Request Forgery

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

Page 31: Understanding Cross-site Request Forgery

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

Page 32: Understanding Cross-site Request Forgery

Defense | CAPTCHA

Page 33: Understanding Cross-site Request Forgery

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Attack Vectors

Page 34: Understanding Cross-site Request Forgery

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

Page 35: Understanding Cross-site Request Forgery

Attack Vectors | SAMY

Step #9 from Samy’s technical description of his attack:

http://namb.la/popular/tech.html

Page 36: Understanding Cross-site Request Forgery

Digging In | Clarification

Forcing the victim to execute the action (POST):

Page 37: Understanding Cross-site Request Forgery

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)

Page 38: Understanding Cross-site Request Forgery

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

CSRF Tester

Page 39: Understanding Cross-site Request Forgery

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

Page 40: Understanding Cross-site Request Forgery

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 PoCfor testing to see if it’s a CSRF issue

• The test is whether or not it executes from other user contexts, i.e. non-unique

Page 41: Understanding Cross-site Request Forgery

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Takeaways

Page 42: Understanding Cross-site Request Forgery

Takeaways | Overview

1. CSRF is # 8 on the OWASP Top 102. Abuses server’s trust of client3. Forces user to perform sensitive function4. Validate by: State-change, Sensitivity, Non-

uniqueness5. Nonces are a common defense6. 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 issues8. Remember that customers are deeply confused by

CSRF and will require constant reinforcement9. Repetition: State(change)/Sensitivity/Uniqueness

(SSU)

Page 44: Understanding Cross-site Request Forgery

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Questions