The XSS FilesFind, Exploit, and Eliminate

2

Josh Little

• Security Engineer at global vertical market business intelligence company.

• 9 years in application support, developer relations, and application review.

• OWASP Detroit Chapter Leader & a #misec founding member

• GSEC, CISSP in limbo

3

What is a XSS flaw?

• XSS = ‘Cross Site Scripting’

• Injection of arbitrary code into a user’s browser session

• #2 on the 2010 OWASP Top 10 and has been on the list since the beginning

4

Causes of XSS Flaws

• Failure of the application to properly sanitize output to the user’s browser.

• Improper trust of of user supplied data.

$a = $_GET['search'];print 'Your search results '.$a;

5

Effects of XSS

• Theft of session cookies

• Arbitrary HTML or Javascript injection

• Exploit injection

• Keystroke Logging

• BeEF & Metasploit can be used to show effects of XSS

6

Reflective vs. Persistent

• Reflective – Payload tied to specific URL. Visit the link, hit the payload.

• Persistent – Embeds the payload into the page (think comments, forum posts, etc.)

7

DOM Based XSS

XSS based on the DOM's (Document Object Model) response to the incoming code and other page/request elements.

Does not require dynamic server-side code.

<script>document.write("Site is at: " + document.location.href + ".");</script>

8

Finding XSS Flaws

Basic test:

Determine how application handles 'special' characters such as " ' < >

If the application returns these characters unencoded, it's possibly (and probably) vulnerable.

9

Automated scanning – Can test a large number of test cases quickly. Not complete, but a good method to find low-hanging fruit quickly.

Source Code Review – Unsanitized use of input is fairly self evident in code review. Time consuming, however, and complex code can make it difficult to follow input paths.

As with other flaws, a multi-pronged approach is best.

10

Preventing XSS

• Input whitelisting

• Context sensitive output encoding

• Javascript, Actionscript, HTML, CSS, etc. must all be treated differently.

• Just encoding for HTML will not prevent all issues.

11

Context is Key

HTML Body

HTML Attribute

s

<STYLE> Context

<SCRIPT>

Context

URL Context

*courtesy of Jim Manico (@manicode)

12

Data Type Context Defense

Numeric, Type safe language Doesn’t Matter Cast to Numeric

String HTML Body HTML Entity Encode

String HTML Attribute, quoted Minimal Attribute Encoding

String HTML Attribute, unquoted Maximum Attribute Encoding

String GET Parameter URL Encoding

String Untrusted URL URL Validation, avoid javascript: URL’s, Attribute encoding, safe URL verification

String CSS Strict structural validation, CSS Hex encoding, good design

HTML HTML Body HTML Validation (JSoup, AntiSamy, HTML Sanitizer)

Any DOM DOM XSS Cheat sheet

Untrusted JavaScript Any Sandboxing

JSON Client parse time JSON.parse() or json2.js

*courtesy of Jim Manico (@manicode)

13

To be truly successful, sanitization should be part of the development framework and not optional.

Most successful when the decision on whether to apply sanitization is not up to the individual developer but enforced by the development environment.

14

Anti-XSS Frameworks

.NET – MS AntiXSS Libraryhttp://msdn.microsoft.com/en-us/security/aa973814

JAVA, .NET – OWASP AntiSAMYhttps://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

Javascript – Google CAJAhttp://code.google.com/p/google-caja/

15

Browser Based Defenses

• Most modern browsers have some form of XSS protection either built-in or via a 3rd party plugin (i.e. NoScript)

• Bad code is still bad code – don't rely on the browser for defense.

16

DEMOSBasic XSS Examples

17

Demos

All demos are available at http://xploit.zombietango.com/xss

Feel free to play with them and use them in additional demonstrations.

18

#1 Basic XSS & Mitigation Strategies

http://xploit.zombietango.com/xss/1/

Mitigation Strategies:

• Basic – Strips <script></script> tags

• Good – Encodes output within HTML context

• Textarea – Encloses error message in a <textarea> tag

19

#2 Attacking incomplete filtering

http://xploit.zombietango.com/xss/2/

No input written to page body, so we're safe, right?

Search term written to <title> tag without sanitization

20

#3 XSS with Style

http://xploit.zombietango.com/xss/3/

Don't confuse limited means of input with limited input

Some apps respond to multiple HTTP methods

Cookies can provide a method of persistence within a user's browser session.

21

#4 DOM Based XSS

http://xploit.zombietango.com/xss/4/

Site builds comment link with ref to current URL.

# tag in URL before payload prevents attack from showing up in server logs

22

#5 XSS through POST

http://xploit.zombietango.com/xss/5/

Apps using only the POST method are not immune to XSS

Requires the use of secondary page to build & submit the exploitable form

23

QUESTIONS?