understanding cross-site request forgery
DESCRIPTION
A description of the web application vulnerability known as Cross-site Request ForgeryTRANSCRIPT
© 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
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
Introductions
Agenda
- Problem
- Basics
- Description
- Validation
- Defenses
- Attack Vectors
- CSRF Tester
- Takeaways
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
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
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
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 | OWASP
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.”
Basics | Description
Let’s unpack that.
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.”
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.”
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.”
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?
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
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?fromacct=2042&toacct=4497 /> (GET)
Basics | Forced POSTs
Forcing the victim to execute the action (POST):
Basics | Description
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
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
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
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
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
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
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
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.
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
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
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
Defense | CAPTCHA
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
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)
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
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 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
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Takeaways
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)
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/
© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Questions