OWASP Top Ten Project 2013 No 3 – Cross-Site Scripting (XSS)

As the base for XSS vulnerability is the non-encoded integration of untrusted input into dynamically created web pages, it is necessary to make sure that any input is encoded when being displayed. With Intershop Commerce Management (ICM) this is being achieved by using the <isprint> tag or the stringToHtml() function:

<isprint value="#Product:Name#">
#stringToHtml(Product:Name)#
<istext key="welcome.message" param0="#stringToHtml(User:Name)#" encoding="on">

By default encoding is enabled for <isprint> and can be disabled with the attribute value encoding="off". The encoding of the <istext> tag can be disabled too. Please make sure that all injected parameter are encoded in that case.

Several encoding providers are delivered with ICM, that can be used for different encoding requirements. The following encoding types exist:

Identifier Functionality description
xml encoding for xml content – the encoding replaces characters like <>
html encoding for html pages – the encoding replaces characters like <> and all between \u00a0 and \u00ff.
javascript encoding for JavaScript inside html pages – the encoding replaces characters like \t\b\r\n
json encoding for JSon inside html pages – the encoding replaces characters like \t\b\r\n, \
wml encoding like html and the $ sign.
url encoding using java.net.URLEncoder
off disables encoding – useful to deactivate the default encoding.
nl2br replaces new lines characters ( \n\r,\n,\r) with <br>

So for example encoding for JavaScript in a <script> block would look like this:

<script type="text/javascript">
window.parent.location.href = '<isprint value="#URL(Action('ViewDashboard-Show'), Parameter('DashboardID', DashboardBO:ID))#" encoding="javascript">';
</script>

 

Also multiple encodings can be applied by passing a list of encoding identifiers (e.g. <isprint value"#SomeContent# encoding="xml,javascript">). Even own encoding handlers can be registered and used for custom encoding requirements.

Sanitizing Untrusted Input

An additional countermeasure for preventing XSS vulnerability is the sanitizing of untrusted input, which means that input is validated and/or HTML formatted text cleaned. Since Intershop 7.4 a webform validator is available for XSS.

Persistent XSS Protection – XSS Form Validator

A new webform validator has been introduced for preventing XSS attacks. It uses a library provided by The Open Web Application Security Project. XSS validation can be used specifically per parameter by referring to the respective validator, GlobalValidators-xss. Additionally, it is possible to have all webform parameters/fields of type string validated automatically at application level by setting the configuration parameter webform.validation.xss

Template API Checker

ICM includes a template API checker at $IS_HOME/tools/api_checker which is capable of identifying potential XSS vulnerabilities.

Co-Authors: Thomas Bergmann, Nils Breitmann and Intershop Consulting Stuttgart

OWASP Top Ten Project 2013 No 3 – Cross-Site Scripting (XSS)

Leave a Reply

Your email address will not be published. Required fields are marked *