Understanding Cross-site Request Forgery

4,819 views

Published on

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

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,819
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
145
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • My name is [Name]. I work at HP as a [Title] in the Enterprise Security Products group.Today, we’ll talk about application security; what it is, why its needed, how to do it and what benefits you will see.
  • Why is there a problem, and why do you need application security?Like all organizations, you’ve undoubtedly, invested a lot of time and money attempting to insulate and protect your assets. Your networks are protected – firewalls are in nearly every devices that connects to a network. Your servers are protected, thanks to advances in intrusion prevention systems. But your software applications are still largely unprotected and vulnerable.Companies believed that if you protect the perimeter (network and server), the software will be unreachable and therefore not breachable. However, that has not proven to be the case: software is the New Entry Point.Let’s take a look at how…
  • Why is there a problem, and why do you need application security?Like all organizations, you’ve undoubtedly, invested a lot of time and money attempting to insulate and protect your assets. Your networks are protected – firewalls are in nearly every devices that connects to a network. Your servers are protected, thanks to advances in intrusion prevention systems. But your software applications are still largely unprotected and vulnerable.Companies believed that if you protect the perimeter (network and server), the software will be unreachable and therefore not breachable. However, that has not proven to be the case: software is the New Entry Point.Let’s take a look at how…
  • Understanding Cross-site Request Forgery

    1. 1. © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.UnderstandingCross-siteRequest ForgeryDaniel MiesslerPrincipal Security Architect, HP FortifyMay 2013
    2. 2. 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 Consultingdaniel.miessler@hp.comIntroductions
    3. 3. Agenda- Problem- Basics- Description- Validation- Defenses- Attack Vectors- CSRF Tester- Takeaways
    4. 4. © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.Problem
    5. 5. Problem | Overview CSRF is an OWASP Top 10 vulnerability but it’s not aswell understood as many others Many struggle with how to validate it Customers have difficulty explaining to managementwhy it’s important to fix We need to be well-versed in the main points to helpthe customer with their narrative to management
    6. 6. © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.Basics
    7. 7. 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
    8. 8. Basics | OWASP
    9. 9. Basics | Description“Cross-site Request Forgery is avulnerability in a website that allowsattackers to force victims to performsecurity-sensitive actions on that sitewithout their knowledge.”
    10. 10. Basics | DescriptionLet’s unpack that.
    11. 11. Basics | Description“Cross-site Request Forgery is avulnerability in a website that allowsattackers to force victims to performsecurity-sensitive actions on that sitewithout their knowledge.”
    12. 12. Basics | Description“Cross-site Request Forgery is avulnerability in a website that allowsattackers to force victims to performsecurity-sensitive actions on that sitewithout their knowledge.”
    13. 13. Basics | Description“Cross-site Request Forgery is avulnerability in a website that allowsattackers to force victims to performsecurity-sensitive actions on that sitewithout their knowledge.”
    14. 14. Basics | Description What do we mean by “sensitive actions”? How do attackers “force” victims to performthem? And how do the victims not know it’shappening?
    15. 15. 1. The target is a sensitive operation in theapplication, e.g. UpdateSalary.aspx, that’s able tobe tricked into executing.2. Victims can be forced to execute this action throughany method that gets them to load a resourceautomatically, e.g. img tag, script tag, onload formsubmit, etc. Note: credentials go with all requests!3. These happen unknowingly because the actions areperformed by the victim’s browser, not by the victimexplicitly.Basics | Description
    16. 16. Sensitive action examples: /EditDocument.aspx /Login.do /CreateAdmin.php /UpdateStatus/Basics | Examples
    17. 17. Forcing the victim to execute the action(GET):- <imgsrc=“http://site.com/transfer.php?fromacct=2042&toacct=4497 /> (GET)Basics | Forced POSTs
    18. 18. Forcing the victim to execute the action(POST):Basics | Description
    19. 19. Both XSS and CSRF are possible due to abusedtrust relationships: In XSS the browser will run malicious JavaScript because it was servedfrom a site (origin) it trusts. In CSRF the server will perform a sensitive action because it was sentby a client that it trusts.Basics | Trust Abuse
    20. 20. © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.Validation
    21. 21. Validation | CriteriaIf you can’t change something using your CSRFvulnerability, 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
    22. 22. Validation | CriteriaIf your CSRF vulnerability doesn’t changesomething sensitive, then you might not haveone.Note: sensitivity is a…sensitive matter. Who is itsensitive to? Could it be sensitive to some andnot others? Many changes are insignificant Remember that if the business understands the technicalrisk then they automatically win the “what matters”argument
    23. 23. Validation | CriteriaIf requests for your CSRF vulnerability areunique, you might not have one.Things to check for uniqueness:- Nonces- CAPTCHA- Multiple authentication levels
    24. 24. Validation | CriteriaThe 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 CSRFvulnerability should hear and learn these sameconcepts
    25. 25. Validation | WebInspectHow WebInspect identifies CSRF:1. Log in to the site2. Complete a form and generate post request with current sessioncookies3. If response is 30X, follow the redirection (with current sessioncookies) until the non-30x response is reached. This is response #1(R1)4. Log out and log in the site with different credentials (note sessioncookies should be changed here)5. Resend the same POST request as in step 2, but with the newcookies6. 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-able
    26. 26. Validation | Manual ValidationHow 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, anduniqueness5. Look for any additional controls that could stop CSRF, such asCAPTCHA 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 issuccessful8. If the action is performed without issue, it is most likely CSRF9. Remember that the issue must also satisfy the state change andsensitivity requirements. Non-uniqueness is not enough.
    27. 27. Validation | Caution with AutomationDon’t trust the claims from tools. They’re oftenright, but they’re only guessing at sensitivity: Validation of non-uniqueness doesn’t mean theaction is sensitive, i.e. it could be a “business”false positive even if it’s valid technically CSRF is a high-false-positive vulnerability whenautomation is used Tools make educated guesses that requirevalidation of all three criteria
    28. 28. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.Defense
    29. 29. Defense | Overview The primary defense for Cross-site RequestForgery is creating unique requests that cannotbe easily generated by attackers. This is usually accomplished via a nonce (anumber used once). CAPTCHAs can also be used, as well asauthentication prompts
    30. 30. Digging In | Nonces<%function session_initiate(first_name, last_name /* etc */) {session.fisrt_name = first_namesession.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
    31. 31. Defense | Nonces Nonces make it so that generic requests tosensitive resources don’t get executed This works by providing a one-time-secretwhen a legitimate client arrives at a givenlocation, and then that token (nonce) must besubmitted along with a request to prove that’slegitimate
    32. 32. Defense | CAPTCHA
    33. 33. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.Attack Vectors
    34. 34. Attack Vectors | Leveraging XSS The key to CSRF defense is that the attacker doesn’thave access to a valid nonce But with XSS present the attacker could force the victimto make a request to the site, consume the nonce, andadd it to the CSRF request This is what the Samy Worm did; he pulled the token firstand used it to submit the (now valid) friend addition
    35. 35. Attack Vectors | SAMYStep #9 from Samy’s technical descriptionof his attack:http://namb.la/popular/tech.html
    36. 36. Digging In | ClarificationForcing the victim to execute the action (POST):
    37. 37. Attack Vectors | Options Take control of a legitimate, well-trafficked butlow priority internal site and post a form thatsubmits the attack Use persistent XSS to inject code on avulnerable site, e.g. a forum Create a new site internally and entice usersto visit the site via email, etc. (phishing-ish)
    38. 38. © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.CSRF Tester
    39. 39. CSRF Tester | Overview• CSRF Tester is anOWASP tool for creatingCSRF PoC code• It works by capturing youdoing somethingsensitive, and thengenerating PoC code foryou try in another usercontext• You must set yourJAVA_HOME environmentvariable to launch it• Listens on port 8008
    40. 40. CSRF Tester | Usage• Send traffic through CSRFTester like any other proxy• Record the execution of asensitive action on the site• You then create a “report”of a certaintype, Form, iFrame, IMG,XHR, Link• That code is now the PoCfor testing to see if it’s aCSRF issue• The test is whether or notit executes from other
    41. 41. © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.Takeaways
    42. 42. Takeaways | Overview1. 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 bybypassing nonce defenses by having the user request avalid nonce before submitting7. Single sign-on can magnify CSRF issues8. Remember that customers are deeply confused by CSRFand will require constant reinforcement9. Repetition: State(change)/Sensitivity/Uniqueness (SSU)
    43. 43. Takeaways | Resources1. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)2. http://en.wikipedia.org/wiki/Cross-site_request_forgery3. https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project4. http://code.google.com/p/pinata-csrf-tool/5. http://www.threadstrong.com/courses/csrf/
    44. 44. © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.Questions

    ×