Skip to main content
Version: 2.8

XSS Security Feature

Overview​

Cross-site Scripting (XSS) is one of the most dangerous and commonly found vulnerabilities in web applications. XSS attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites.

Cross-site Scripting vulnerabilities are covered by CWE-79.

The XSS security feature can be used to enable protection against XSS attacks.

Only reflected XSS and stored XSS for HTML is currently supported.

It is important to state that this rule provides protection only when user input is received via an API that is enabled in the taint sources of the rule.

On a small number of J9 JVMs, the application may need to be launched with the following property: com.waratek.FastStringLexing=false.

Given (Condition)​

The XSS security feature is enabled using the ARMR http rule. With this rule the user specifies the two declarations - input and response.

inputThis allows the user to specify the source of the untrusted data. The following three sources are supported:- http data introduced via HTTP/HTTPS requests

  • database data introduced via JDBC connections

  • deserialization data introduced via Java or XML deserializationThe rule will trigger if the source of the untrusted data matches that specified in the rule.If no value is specified then a default value of http is used.An exception will be thrown if an unsupported value is provided. | | response | This determines the HTTP endpoints for which protection is enabled. An optional key value pair can be supplied to this declaration where the key is paths and the value can be one of the following (indicating specifically targeted HTTP endpoints) :-- a quoted string

  • a list of one or more quoted-stringsIf no value is specified then protection will be applied to all HTTP endpoints by default.If a string value is specified then it must:- not be empty

  • be a valid relative URI |

When (Event)​

xssThis declaration switches on the XSS security feature and must be declared with the mandatory parameter html.The following options may also be specified: - exclude

  • disable protection for any specific URIs

  • if this option is not specified the default value is an empty exclusion list, therefore enabling protection for all web-pages

  • specific URIs can be specified as a single string literal, or a non-empty array of one or more string literals

  • the wildcard character (*) is supported to cover multiple URIs. The wildcard character can be used as:

    • a prefix */safe.jsp

    • a suffix /myApplication/*

    • both a prefix and a suffix */safe*

  • policy

    • this allows the user to determine how conservative to configure the XSS security feature

    • this can be set to either:

      • loose - enable protection for user controlled changes to the HTML response that actively exploit the application

      • strict - enable protection for injection of untrusted data into HTML response

    • if this option is not specified the default value is set to loose. In this configuration, the XSS security feature supports the ability to allow certain HTML tags to be injected into an HTML document from an untrusted source. Allowed tags are generally defined as text formatting and layout elements and, as such, do not alter the behaviour of an application. The full list of allowed tags is defined in sections 4.4, 4.5 and 4.9 of the HTML5 specification. A tag deemed safe can also be blocked if it contains an attribute that is deemed malicious. All JavaScript event handlers are considered dangerous. The full list of these are defined as part of the section 3.2.5 of the HTML5 specification.

    • in addition to the JavaScript handlers, the following attributes have also been deemed dangerous due to their capacity to instruct a browser to load an external resource, disable security policies or potentially load personally sensitive details.

      • async

      • autocomplete

      • autoplay

      • crossorigin

      • href

      • integrity

      • src

      • srcset

      • target

      • text

      • type |

Then (Action)​

protectXSS attacks are blocked by the agent and the HTTP response is truncated up to the point where the XSS attack occurs.If configured, a log message is generated with details of the event.
detectMonitoring mode: the application behaves as normal. XSS attacks are allowed by the agent and no change is made to the HTTP response.If configured, a log message is generated with details of the event.A log message must be specified with this action.

As part of the action statement, the user may optionally specify the parameter stacktrace: “full”. When this parameter is specified, the stacktrace of the location of the attempted exploit is included in the security log entry.

Examples​

The following example shows how the user may configure the XSS security feature to enable protection for all HTTP endpoints. This rule uses the default configuration to protect against reflected XSS attacks and use a policy of loose to allow safe tags to be injected into the HTML response:

app("XSS Mod"):
  requires(version: ARMR/2.8)
  http("XSS"):
    response()
    xss(html)
    protect(message: "XSS attacked identified and blocked", severity: Very-High)
  endhttp
endapp

Logging​

A log entry similar to the following is generated when above http rules identify an XSS attack:

<9>1 2021-03-29T11:54:42.817+01:00 userX_system java 15891 - - CEF:0|ARMR:XSS Mod|XSS Mod|2.8|XSS|Execute Rule|Very-High|rt=Mar 29 2021 11:54:42.817 +0100 dvchost=userX_system procid=15891 appVersion=1 ruleType=http securityFeature=http html xss act=protect msg=XSS attacked identified and blocked payload=<script>alert(1)</script> httpSessionId=E654F722AAFA3BF44F0D0BD4FB91134C taintSource=HTTP_SERVLET httpRequestUri=/spiracle/xss.jsp internalHttpRequestUri=/spiracle/xss.jsp httpCookies=JSESSIONID\=E654F722AAFA3BF44F0D0BD4FB91134C remoteIpAddress=0:0:0:0:0:0:0:1

Further Examples​

The following mod is the same as the previous example, with the stacktrace also logged:

app("XSS Mod - with stacktrace"):
  requires(version: ARMR/2.8)
  http("XSS"):
    response()
    xss(html)
    protect(message: "XSS attacked identified and blocked", severity: Very-High, stacktrace: "full")
  endhttp
endapp

Logging​

When the above ARMR http rule is triggered a log entry similar to the following is generated:

<9>1 2021-03-29T10:36:49.592+01:00 userX_system java 12043 - - CEF:0|ARMR:XSS Mod - with stacktrace|XSS Mod - with stacktrace|2.8|XSS|Execute Rule|Very-High|rt=Mar 29 2021 10:36:49.591 +0100 dvchost=userX_system procid=12043 appVersion=1 ruleType=http securityFeature=http html xss act=protect msg=XSS attacked identified and blocked stacktrace=org.apache.jsp.xss_jsp._jspx_meth_c_005fforEach_005f0(xss_jsp.java:305)\norg.apache.jsp.xss_jsp._jspService(xss_jsp.java:159)\norg.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)\njavax.servlet.http.HttpServlet.service(HttpServlet.java:731)\nsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\nsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\nsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\njava.lang.reflect.Method.invoke(Method.java:498)\norg.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)\norg.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)\norg.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)\njavax.servlet.http.HttpServlet.service(HttpServlet.java:731)\nsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\nsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\nsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\njava.lang.reflect.Method.invoke(Method.java:498)\norg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)\norg.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)\norg.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)\nsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\nsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\nsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\njava.lang.reflect.Method.invoke(Method.java:498)\norg.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)\norg.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)\norg.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218)\norg.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)\norg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)\norg.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)\norg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)\norg.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)\norg.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)\norg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:442)\norg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1082)\norg.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:623)\norg.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)\njava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\njava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\norg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\njava.lang.Thread.run(Thread.java:748) payload=<script>alert(1)</script> httpSessionId=5D7CE07F605C3A6ABCFDB35D065A95E5 taintSource=HTTP_SERVLET httpRequestUri=/spiracle/xss.jsp internalHttpRequestUri=/spiracle/xss.jsp httpCookies=JSESSIONID\=5D7CE07F605C3A6ABCFDB35D065A95E5 remoteIpAddress=0:0:0:0:0:0:0:1

The following mod configures XSS protection for stored XSS attacks against all HTTP endpoints. The mod applies a strict policy.

app("XSS Mod 2"):
  requires(version: ARMR/2.8)
  http("XSS"):
    input(database)
    response()
    xss(html, options: {policy: strict})
    protect(message: "XSS attacked identified and blocked", severity: 7)
  endhttp
endapp

The following mod detects XSS attacks that originate from various untrusted sources. This mod explicitly sets a loose policy.

app("XSS Mod 3"):
  requires(version: ARMR/2.8)
  http("XSS"):
    xss(html, options: {policy: loose})
    response()
    input(http, database, deserialization)
    protect(message: "XSS attacked identified", severity: Medium)
  endhttp
endapp

The following mod protects against reflected XSS attacks. Validation is applied to all HTTP endpoints, except for /myApplication/safe.jsp.

app("XSS Mod 4"):
  requires(version: ARMR/2.8)
  http("XSS"):
    response()
    xss(html, options: {exclude: ["/myApplication/safe.jsp"]})
    input(http)
    protect(message: "XSS attacked identified and blocked", severity: 7)
  endhttp
endapp

The following mod detects reflected XSS attacks. This mod explicitly sets a strict policy. Validation is applied to all HTTP endpoints, except for both /myApplication/safe.jsp and /myApplication/safeTwo.jsp.

app("XSS Mod 5"):
  requires(version: ARMR/2.8)
  http("XSS"):
    xss(html, options:
              {policy: strict,
               exclude: ["/myApplication/safe.jsp", "/myApplication/safeTwo.jsp"]})
    response()
    detect(message: "XSS ARMR rule triggered", severity: Very-High)
  endhttp
endapp

The following mod protects against reflected XSS attacks. Protection is applied to all HTTP endpoints, except for those ending with /safe.jsp.

app("XSS Mod 6"):
  requires(version: ARMR/2.8)
  http("XSS"):
    response()
    xss(html, options: {exclude: ["*/safe.jsp"]})
    input(http)
    protect(message: "XSS attacked identified and blocked", severity: 7)
  endhttp
endapp