Skip to main content

Cross-site Scripting (XSS) Protection

  • Updated

Cross-site Scripting (XSS) Protection

Cross-site scripting (XSS) is a common form of security vulnerability affecting web applications. Attackers use XSS to inject client-side scripting into web pages via the URL, tricking the browser into trusting scripts run from malicious hosts. This topic describes how you can protect your Logi applications from XSS attacks.

These scripts usually access user and session information stored in cookies, and allow the hackers to forge trusted user behavior. Most modern browsers include a defense against this, the X-XSS-Protection header, which is enabled by default. However, this may not satisfy penetration testing and applications may be determined to be vulnerable. Beginning with early versions of Info v12, Logi applications can be configured to enable XSS Filtering at the web server, as follows:


Once copied, session variables are identified, in the Java app, using its session object's attribute ID and, in the Logi app, as the name used with a @ Session token. For example: Java JSP:session.getAttribute("userEmail")
Logi app:@Session.userEmail~
If circumstances demand it, it's possible to return to an earlier, "copy all" behavior by manually adding the following XML to your _Settings definition source code, as a child of the <Setting> tag:
<JavaSessionCopying CopyToJavaInclude="^" CopyToJavaExclude="DebugFile,-bUsesSort$,-tra$,-xmlDef$,
-Xsl$,-rdDef$" CopyFromJavaInclude="^" CopyFromJavaExclude="^rd,^dt" />

  1. Edit the <yourLogiApp>\WEB-INF\web.xml file and uncomment the code section that begins with:

    <filter>
    <filter-name>XssFilter</filter-name> Save the file.

  2. Edit the <yourLogiApp>\WEB-INF\XssFilter.properties file and provide appropriate filtering directives.

    As installed, the default XssFilter.properties file includes six directive examples. Delete them and add:

    filter1=,)<>!(@,GET
    filter2=,)<>!(@,POST The effect of the examples above is to throw an error and not execute any page requested with GET or POST using any URL that includes any of these characters: ()<>!@ . The format of a filter directive consists of three parts:

    filter#= urlPattern, forbiddenCharacters, requestType where: urlPattern = the URL, for example "rdReport=Default"; leave this blank to apply the filter to all URLs
    forbiddenCharacters     = the characters in the URL that will cause an error; leave this blank to allow all characters
    requestType     = HTTP request type: either GET or POST Here's another example:

    filter18=rdReport=yourCustomReport,,POST This example filters URLs requested using POST and containing "rdReport=yourCustomReport" and it allows all characters. Prior to v12.5 SP2, filters could require a large number of directives to cover all the possibilities, and these might have conflicted with URLs generated by super-elements such as the Analysis Grid. After that release, this is handled internally and one or two directives like the first two shown above are sufficient to provide broad, generic protection in most cases.

Related articles