Hitachi Vantara Pentaho Community Wiki

A3 Cross-site Scripting (XSS)

Skip to end of metadata
Go to start of metadata

A3 Cross-Site Scripting (XSS)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

A 3.1 Defenses:

Encode untrusted data:

Data Type Context Code Sample Defense
String HTML Body <span>UNTRUSTED DATA</span>
String Safe HTML Attributes <input value="UNTRUSTED DATA">
  • Aggressive HTML Entity Encoding
  • Only place untrusted data into a whitelist of safe attributes (listed below).
  • Strictly validate unsafe attributes such as background, id and name.
String GET Parameter <a href="/site/search?value=UNTRUSTED DATA">clickme</a>
String Untrusted URL in a SRC or HREF attribute <a href="UNTRUSTED URL">clickme</a>
<iframe src="UNTRUSTED URL" />
String CSS Value <div style="width:UNTRUSTED DATA">Selection</div>
String JavaScript Variable <script>var currentValue='UNTRUSTED DATA'</script>
<script>someFunction('UNTRUSTED DATA')</script>
  • Ensure JavaScript variables are quoted
  • JavaScript Hex Encoding
  • JavaScript Unicode Encoding
  • Avoid backslash encoding (\" or \' or
String DOM XSS <script>document.write("UNTRUSTED INPUT: " + document.location.hash);<script/>

A 3.2. Sanitizers:

A 3.2.1 OWASP Java HTML Sanitizer Project


If you are using Maven then follow the maven directions to add a dependency. Otherwise, download prebuilt jars;or;git clone;and build the latest source.

Unless maven is managing your CLASSPATH for you, you need to add both owasp-java-html-sanitizer.jar and the Guava JAR.

Once you have your CLASSPATH set up correctly with the relevant JARs you should be able to addimport org.owasp.html.HtmlPolicyBuilder;to one of your project's;.java;files and compile it.

Unless maven is managing your CLASSPATH for you, you need to add both owasp-java-html-sanitizer.jar;and the Guava JAR.

A 3.2.2 OWASP Java Encoder

HTML Content Context
<textarea><%= Encode.forHtmlContent(UNTRUSTED)%></textarea>
HTML Attribute context
<input value="<%= Encode.forHtmlAttribute(UNTRUSTED)%>"

Generally Encode.forHtml(UNTRUSTED) is also safe but slightly less efficient for the above two contexts (for textarea content and input value text) since it encodes more characters than necessary but might be easier for developers to use.

CSS contexts
<div style="width:<= Encode.forCssString(UNTRUSTED)%>">
<div style="background:<= Encode.forCssUrl(UNTRUSTED)%>">
*Javascript Block context;
var msg = "<%= Encode.forJavaScriptBlock(UNTRUSTED)%>";
*Javascript Variable context
<button onclick="alert('<%= Encode.forJavaScriptAttribute(UNTRUSTED)%>');">click me
JavaScript Content Notes:

Is safe for the above two contexts, but encodes more characters and is less efficient.

Encode URL parameter values
<a href="/search?value=<%= Encode.forUriComponent(UNTRUSTED)%>&order=1#top">
Encode REST URL parameters
<a href="/page/<%= Encode.forUriComponent(UNTRUSTED)%>">
Handling an Full Untrusted URL

When handling a full url with the OWASP Java encoder, first verify the URL is a legal URL.

String url = validateURL(untrustedInput);

Then encode the URL as an HTML attribute when outputting to the page. Note the linkable text needs to be encoded in a different context.

<a href="<%= Encode.forHtmlAttribute(untrustedUrl)%>">
<%= Encode.forHtmlContent(untrustedLinkName);%>
To use in a JSP with EL
<%@page contentType="text/html" pageEncoding="UTF-8"%>

<\!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""">
<%@taglib prefix="e" uri=""%>
<title><e:forHtml value="${param.title}" /></title>

Other contexts can be found in the org.owasp.Encode class methods, including CSS strings, CSS urls, XML contexts, URIs and URI components.

A 3.2.3 DOMPurify

A 3.2.4 MentalJS

MentalJS is a JavaScript parser and sandbox. It whitelists JavaScript code by adding a "$" suffix to variables and accessors.

A 3.2.5 OWASP JSON Sanitizer

A 3.2.6 Third Party Javascript Management Cheat Sheet

A 3.3 AJAX Security Best Practices:

A 3.4 HTTP Response Splitting


Major form of attacks can result from HTTP Response Splitting:

  • Phishing
  • Cross-site Scripting
  • Web Cache Poisoning
  • Hijacking pages
  • Browser cache Poisoning
  • Cross User attacks (single user, single page, temporary defacement)

Best Practices:

Investigate all uses of HTTP headers, such as:

  • setting cookies
  • using location (or redirect() functions)
  • setting mime-types, content-type, file size, etc.
  • or setting custom headers

If these contain unvalidated user input, the application is vulnerable when used with application frameworks that cannot detect this issue.
If the application has to use user-supplied input in HTTP headers, it should check for double “\n” or “\r\n” values in the input data and eliminate it.
Many application servers and frameworks have basic protection against HTTP response splitting, but it is not adequate to task, and you should not allow unvalidated user input in HTTP headers.

A 3.5. General Recommedations:

A 3.5.1 Avoid nested context

But if you must have it the right order to encode is as follows:

  • JS encode first
  • HTML attribute encode second

A 3.5.2 Encode every variable before showing to user

a href=”%=Encode.forHTMLAttribute(UNTRUSTED_URL)%>”>

3.5.3. Safe way to populate DOM


3.5.4 Safe JSON parsing


Do not use eval()

3.5.5 jQuery most unsafe ways to populate data.html


3.5.6 jQuery safe ways to populate data


3.5.7 Sandboxing

Object.seal ( O )

When the seal function is called, the following steps are taken:
1. If Type(O) is not Object, return O.
2. Let status be Set Integrity Level( O, "sealed").
3. Return IfAbrupt(status).
4. If status is false, throw a TypeError exception.
5. Return O.


iFrame Sandboxing (HTML5)
<iframe src="demo_iframe_sandbox.jsp sandbox="">

Allow-same-origin, allow-top-navigation, allow-forms, allow-scripts

3.5.8. HTML Response Headersx-xss-protection:0-1 (mode=block1; 1; mode=block)*

DENY (prevent any domain from framing your page),
SAMEORIGIN (only allows the current site to frame your page)*** ALLOW FROM X
Set X-Frame-Options to SAMEORIGIN to stop framing and limit clickjacking. Must be added to response header because x-frame-option http request headers does nothing.
x-content-type-options: nosniffTo stop guessing of mime type, applies to IE and Chrome
Implement x-content-security-policyx-content-security-policy
Powerful mechanism for controlling which sites can execute JS, current standard.
Implement secure headers:
allow-control-allow-origin, xdomain use image
strict-transport-security, forces browser to use https, critical
cache-control: no-store, no-cache, must-revalidate, expiresz; -1 (expire in the past)


3.5.9 Output encoding

JSF output components filter output and escape dangerous characters as XHTML entities

<h:outputText Value=”#{}”/>

3.5.10 XXE prevention


XMLInputFactory factory = XMLInputFactory.newInstance(); factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, Boolean.FALSE);

Set the IS_SUPPORT_DTD property in xalan to FALSE:

XMLInputFactory factory = XMLInputFactory.newInstance();
factory.setProperty(XMLInputFactory.SUPPORT_DTD, Boolean.FALSE);

Learn More 

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.