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