Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

XSS Deep Dive - AppSec Lesson

1,079 views

Published on

What IS Cross Site Scripting? Also know as ‘XSS’, cross site scripting is a web application vulnerability that allows an attacker to inject their own script into your application, manipulating your application into trusting it, as if their script was part of the application. The attack is then executed against users of your application in the browser. XSS is common, dangerous, and easy to find with automated tools, which is why it is #A6 on the OWASP Top Ten. This Application Security Lesson will teach you what XSS, how to differentiate the 3 types of XSS, explain how to find it, but most importantly, how to prevent it. This talk also includes a live demonstration of the vulnerability, with audience participation.

Published in: Technology
  • Be the first to comment

XSS Deep Dive - AppSec Lesson

  1. 1. A7: Cross Site Scripting Deep Dive OWASP OTTAWA APPLICATION SECURITY LESSON Tanya Janca Tanya.Janca@owasp.org @SheHacksPurple Tanya Janca OWASP Ottawa Chapter Leader OWASP DevSlop Project Leader
  2. 2. Outline • The OWASP Top Ten & A7: XSS • What IS cross site scripting (XSS)? • Three types of XSS • What are the risks? • Demo • How do we protect against this? • How do we find or test for XSS? • Q&A @SheHacksPurple
  3. 3. XSS and the OWASP Top Ten The OWASP Top Ten is a powerful awareness document about the most critical web application security flaws. It is NOT a standard. XSS is #7 in the new release. @SheHacksPurple
  4. 4. XSS and the OWASP Top Ten
  5. 5. What is Cross Site Scripting? • Cross-Site Scripting (XSS) is an attack where malicious scripts are injected into an otherwise normal web site, then executed in the browser. • The malicious code is sent to a different user. • The malicious code can do anything that JavaScript has the power to do. XSS is *extremely* widespread and dangerous.
  6. 6. What is Cross Site Scripting? • XSS works because the browser thinks the script is from the application, so it trusts it. • This can happen when an app outputs data that was not validated and not output encoded. • This means the script can access cookies, session tokens or anything else your app has. • More than just alert boxes.
  7. 7. What is Cross Site Scripting? • XSS is the second-most found web app vulnerability, it’s in about 2/3 of apps • There are many automated tools and frameworks for exploitation available, unsophisticated actors can exploit it easily • It’s even easier to find in older/more mature frameworks and languages
  8. 8. What is Cross Site Scripting? You need two ingredients for XSS: 1. Lack of data validation/sanitization 2. Lack of output encoding/escaping.
  9. 9. The three types of XSS 1. Reflected (most common) 2. Stored 3. DOM (the strange one)
  10. 10. The three types of XSS: Reflected (1/3) • Happens when un-sanitized input is reflected off of the web server as un-encoded HTML output to the application, and the app executes it as if the malicious script is it’s own script • Usually the user needs to click a link in an email or on a site to execute such an attack
  11. 11. The three types of XSS: Stored (2/3) • Your application stores un-sanitized /un-validated user input in the database, that is then output to the application (un-encoded). • System administrators are often the target of such attacks, because they have special privileges & access on your app/network
  12. 12. The three types of XSS: Stored (2/3) • Can affect any user, even if they have not “clicked” or accessed a questionable site • This is considered a critical risk
  13. 13. The three types of XSS:DOM (3/3) NOT THAT KIND OF DOM!
  14. 14. The three types of XSS:DOM (3/3) • DOM = Document Object Model • Does not involve the server, all happens on the client side • Happens in JavaScript frameworks, single page applications and APIs that dynamically include user input (un-encoded) onto a page @SheHacksPurple
  15. 15. The three types of XSS:DOM (3/3) • DOM based XSS happens during runtime in the browser/application/client-side. While the 2 other forms of XSS end up hitting the server, DOM XSS never does. • This means DOM XSS is more difficult, because sanitization is only on the client-side. @SheHacksPurple
  16. 16. What are the risks? • Stolen Cookies or Sessions– used for impersonation or identity theft • Website defacement – Embarrassing • Keylogging • Anything that JavaScript is capable of, the possibilities are endless @SheHacksPurple
  17. 17. Demo!
  18. 18. How do we protect against this? https://www.owasp.org/index.php/ XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
  19. 19. How do we protect against this? (general advice) Treat ALL DATA as untrusted. Sanitize and validate all data before using it in your system, and encode and/or escape all data before outputting it. @SheHacksPurple
  20. 20. How do we protect against this? The plan 1. Validate and Sanitize all user input 2. Encoding (and escaping) output 3. Security Headers 4. Code Review 5. VA scans and security testing @SheHacksPurple
  21. 21. How do we protect against this? #1 Input Validation Ensuring that the input you get is what you expect it to be. Examples: • If you are expecting a date, why is it 100 characters long? • Why would a first name have the “<“ character in it? • Why would a currency field accept letters? @SheHacksPurple
  22. 22. How do we protect against this? #1 Input Sanitization Ensuring that the input you receive cannot cause damage to your application. • Examples: If you are expecting a date, 100 characters will cause a database error. • The “<“ might be part of a malicious script. • A very large value could cause a buffer overflow if you are not using a “memory safe” language. @SheHacksPurple
  23. 23. How do we protect against this? #1 Input Validation and Sanitization Use the functions in your framework, write your own. .Net: Microsoft AntiXSS library Java (spring):JSoup XSS Api’s Python (JinJa): str(utils.escape('malicious code here')) @SheHacksPurple
  24. 24. How do we protect against this? #1 Input Validation & Sanitization You should validate and sanitize ALL data! • User entered-data from your application • Parameters in the URL • Data from an outside API • Data from the database that originates from. a user, it may not have been validated properly the first time @SheHacksPurple
  25. 25. How do we protect against this? #1 Input Validation & Sanitization Methods: • Type Checking • Validation against a schema (XML) • Min/max range • Check against a list (January, February, March..) • Regex @SheHacksPurple
  26. 26. How do we protect against this? #2 Encoding and Escaping Encoding describes how the file's characters are physically written in binary (Unicode or ASCII). Escaping refers to the process of replacing special characters with their XML/HTML/URL equivalent. For instance %20 -> single whitespace @SheHacksPurple
  27. 27. How do we protect against this? #2 Encoding and Escaping Use the encoding functions in your framework, don’t write your own. .Net: HttpUtility.UrlEncode Java: URLEncoder.encode(q,"UTF-8"); JavaScript: encodeURI(uri) Python: urllib.quote(string[,safe]) @SheHacksPurple
  28. 28. #2 Encoding and Escaping If you have to do it manually…. In Body and Div tags • &  &amp; • <  &lt; • And so on How do we protect against this? @SheHacksPurple
  29. 29. #2 Encoding and Escaping Key Take Away: • If you must, encode and/or escape it, everywhere! • Use your framework. • Follow the OWASP Cheat Sheet if you’re having problems. How do we protect against this? @SheHacksPurple
  30. 30. #1 & 2 Repeatability • Create templates • Make these two as easy and as uniform as possible, make it effortless • You want to everyone is doing this the same way, on every project, organization-wide How do we protect against this? @SheHacksPurple
  31. 31. Dom XSS
  32. 32. How do we protect against this? (DOM XSS) #1 Rule: Don’t use unsanitized data in your JavaScript. Just don’t. @SheHacksPurple
  33. 33. How do we protect against this? #3 Security Headers! • Use HTTPOnly cookie flag, to prevent JavaScript from accessing your cookies/session @SheHacksPurple
  34. 34. How do we protect against this? #3 Security Headers! • Use X-XSS-Protection response header to turn back on browser XSS protection, if the user has disabled it • Stops pages from loading if it detects an XSS attack • Chrome and IT only @SheHacksPurple
  35. 35. How do we protect against this? #3 Security Headers! • Use Content-Security-Policy, to set your source for client-side resources Content-Security-Policy: <policy-directive>; <policy-directive> @SheHacksPurple
  36. 36. How do we find XXS? Where do we look? #4 Reviewing your code: what to look for 1. Validate & Sanitize all data from an untrusted source 2. Encode all output from an untrusted source @SheHacksPurple
  37. 37. How do we find XXS? Where do we look? #5 Testing your code: what to use 1. OWASP Zed Attack Proxy (ZAP) 2. Burp Suite/AppScan/Acunetix/Etc. 3. XSSer, Vega, Arachni 4. Manual testing/abuse your app @SheHacksPurple
  38. 38. Questions? Tanya Janca OWASP Ottawa Chapter Leader OWASP DevSlop Project Leader Tanya.Janca@owasp.org @SheHacksPurple
  39. 39. OWASP OTTAWA TOP TEN COUNTDOWN CONTINUES… UP NEXT! A1: INJECTION @OWASP_Ottawa

×