XSS Remediation

Cross-Site Scripting (XSS) Remediation
Guerilla Training Camp
Security BSides Austin

Dan Cornell

© Copyright 2011 Denim Group - All Rights Reserved

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

© Copyright 2011 Denim Group - All Rights Reserved 1

Agenda
• What is Cross-Site Scripting (XSS)?

• How Do You Remediate XSS Vulnerabilities?

• Questions


Vulnerability: Cross-Site Scripting

#2 in the OWASP Top 10

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


Let's look at a simple application
Web Application

Web Browser Administrative
Pages
Administrator

Database

Web Browser User Pages

Attacker


A standard user can update the name and email address on their profile:
NormalGuy
normalguy@normalmail.com

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="normalguy@normalmail.com">


With normal input

<input type=”text” name=”name” value=”NormalGuy”><br>
<input type=”text” name=”email” value=” normalguy@normalmail.com”>

Pages
Administrator

Database


NormalGuy
User normalguy@normalmail.com


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" />">


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

Pages
Administrator

Database


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


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


Impact of Cross-Site Scripting
What can an attacker accomplish with a malicious script?


Cross-Site Scripting Attacks
• Attackers may have different means to have their code to execute on
another user’s browser

• Reflected
• Stored
• DOM Based


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


Reflected Cross-Site Scripting
Malicious Web
Attacker User Web Application
Server

Send e-mail to user with link

Link makes request to website

Response includes malicious content

Malicious content sends authentication information to attacker’s resources

or
Malicious content redirects user to malicious website


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)


Stored Cross-Site Scripting
Attacker Web Application User

Submit field with malicious content

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)


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><'


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')">


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'))">


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)


Mitigation
• Positively validate inputs
– Length, type, syntax, business rules
• Encode application outputs
– HTML or XML
– < becomes < and so on


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


.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/


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


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.


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()


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


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" %>


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 SecurityAntiXSS 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…


Exercise: Fixing XSS Vulnerabilities
• Java
– Reflected XSS
– Stored XSS
• ASP.NET
– Reflected XSS
– Stored XSS


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


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


Questions?
Dan Cornell
dan@denimgroup.com
Twitter: @danielcornell

www.denimgroup.com
(210) 572-4400


XSS Remediation

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a XSS Remediation

Similar a XSS Remediation (20)

Más de Denim Group

Más de Denim Group (20)

Último

Último (20)

XSS Remediation