CNIT 129S: 12: Attacking Users: Cross-Site Scripting (Part 2 of 3)
1 like685 views
The document discusses techniques for finding and exploiting cross-site scripting (XSS) vulnerabilities in web applications. It outlines approaches for testing user input reflections, bypassing defensive filters, and various methods of executing scripts, including encoding and obfuscation techniques. Additionally, it addresses limitations imposed by sanitization and provides examples of strategies to exploit XSS vulnerabilities effectively.
CNIT 129S: 12: Attacking Users: Cross-Site Scripting (Part 2 of 3)
- 1. CNIT 129S: Securing Web Applications Ch 12: Attacking Users: Cross-Site Scripting (XSS) Part 2
- 2. Finding and Exploiting XSS Vunerabilities
- 3. Basic Approach • Inject this string into every parameter on every page of the application • If the attack string appears unmodified in the response, that indicates an XSS vulnerability • This is the fastest way to find an XSS, but it won't find them all
- 4. When the Simple Attack Fails • Applications with rudimentary blacklist-based filters • Remove <script>, or < > " / • Crafted attacks may still work
- 5. Response Different from Input • XSS attacks that don't simply return the attack string • Sometimes input string is sanitized, decoded, or otherwise modified • In DOM-based XSS, the input string isn't necessarily returned in the browser's immediate response, but is retained in the DOM and accessed via client-side JavaScript
- 6. Finding and Exploiting Reflected XSS Vulnerabilities
- 7. Identifying Reflections of User Input • Choose a unique string that doesn't appear anyhere in the application and includes only alphabetical characters that won't be filtered, like "myxsstestdmqlwp" • Submit it as every parameter, one at a time, including GET, POST, query string, and headers such as User-Agent • Monitor responses for any appearance of the string
- 8. Testing Reflections to Introduce Script • Manually test each instance of reflected input to see if it's exploitable • You'll have to customize the attack for each situation
- 9. 1. A Tag Attribute Value • Here are two ways to exploit it
- 11. 2. A JavaScript String • This attack works
- 12. 3. An Attribute Containing a URL • Use the javascript: handler to make your script into a URL • Or use the onclick event handler
- 13. Probing Defensive Filters • Three common types
- 14. Beating Signature-Based Filters • You may see an error message like this
- 15. Remove Parts of the String • Until the error goes away • Find the substring that triggered the error, usually something like <script> • Test bypass methods
- 16. Ways to Introduce Script Code
- 17. Script Tags • If <script> is blocked, try these
- 19. Event Handlers • All these run without user interaction
- 20. Event Handlers in HTML 5 • Autofocus • In closing tags • New tags
- 21. Script Pseudo-Protocols • Used where a URL is expected • IE allows the vbs: protocol • HTML 5 provides these new ways:
- 22. Dynamically Evaluated Styles • IE 7 and earlier allowed this: • Later IE versions allow this:
- 23. Bypassing Filters: HTML • Ways to obfuscate this attack
- 24. Inserted NULL Butes • Causes C code to terminate the string • Will bypass many filters • IE allows NULL bytes anywhere • Web App Firewalls (WAFs) are typically coded in C for performance and this trick fools them
- 25. Invalid Tags • Browser will let it run • Filter may not see it due to invalid tag "x"
- 26. Base Tag Hijacking • Set <base> and later relative-path URLs will be resolved relative to it
- 27. Space Following the Tag Name • Replace the space with other characters • Add extra characters when there's no space
- 28. NULL Byte in Attribute Name • Attribute delimiters • Backtick works in IE
- 29. Attribute Delimiters • If filter is unaware that backticks work as attribute delimiters, it treats this as a single attribute • Attack with no spaces
- 30. Attribute Values • Insert NULL, or HTML-encode characters
- 31. HTML Encoding • Can use decimal and hexadecimal format, add leading zeroes, omit trailing semicolon • Some browsers will accept these
- 32. Tag Brackets • Some applications perform URL decoding twice, so this input • becomes this, which has no < or > • and it's then decoded to this
- 33. • Some app frameworks translate unusual Unicode characters into their nearest ASCII equivalents, so double-angle quotation marks %u00AB and %u00BB work: Tag Brackets
- 34. • Browsers tolerate extra brackets • This strange format is accepted by Firefox, despite not having a valid <script> tag Tag Brackets
- 35. Web Developer Add-on • View Generated Source shows HTML after Firefox has tried to "fix" the code
- 36. Character Sets
- 37. Telling Browser the Character Set • Set it in the HTTP Content-Type header • Or an HTTP META tag • Or a CHARSET parameter, if one is used
- 38. Shift-JIS • Suppose two pieces of input are used in the app's response • input1 blocks quotes, input2 blocks < and > • This attack works, because %f0 starts a two-byte character, breaking the quotation mark
- 40. JavaScript Escaping • Unicode • Eval • Superfluous escape characters
- 41. Dynamically Constructing Strings • Third example works in Firefox • And in other browsers too, according to link Ch 12f
- 42. Alternatives • Alternatives to eval • Alternatives to dots
- 43. Combining Multiple Techniques • The "e" in "alert" uses Unicode escaping: u0065 • The backslash is URL-encoded: \ • With more HTML-encoding
- 44. VBScript • Skip this section • Microsoft abandoned VBScript with Edge • Link Ch 12g
- 45. Beating Sanitization • Encoding certain characters • < becomes < • > becomes > • Test to see what characters are sanitized • Try to make an attack string without those characters
- 46. Examples • Your injection may already be in a script, so you don't need <script> tag • Sneak in <script> using layers of encoding, null bytes, nonstandard syntax, or obfuscates scrip code
- 47. Mistakes in Sanitizing Code • Not removing all instances • Not acting recursively
- 48. Stages of Encoding • Filter first strips <script> recursively • Then strips <object> recursively • This attack succeeds
- 49. Injecting into an Event Handler • You control foo • This attack string • Turns into this, and executes in some browsers
- 50. Beating Length Limits 1. Short Attacks • This sends cookies to server with hostname a • This tag executes a script from the server with hostname a
- 51. JavaScript Packer • Link Ch 12h
- 52. • Use multiple injection points • Inject part of the code in each point • Consider this URL Beating Length Limits 2. Span Multiple Locations
- 53. • It returns three hidden fields • Inject this way Beating Length Limits 2. Span Multiple Locations
- 54. • Result Beating Length Limits 2. Span Multiple Locations
- 55. • Inject this JavaScript, which evaluates the fragment string from the URL • The part after # Beating Length Limits 3. Convert Reflected XSS to DOM
- 56. • First attack works in a straightforward manner • Second one works because http: is interpreted as a code label, // as a comment, and %0A terminates the comment Beating Length Limits 3. Convert Reflected XSS to DOM