HTML cross-site scripting check

The HTML Cross-Site Scripting (XSS) check examines both the headers and the POST bodies of user requests for possible cross-site scripting attacks. If it finds a cross-site script, it either modifies (transforms) the request to render the attack harmless, or blocks the request.

Note:

The HTML Cross-Site Scripting (XSS) check works only for content type, content length, etc. It does not work for cookie. Also ensure to have the ‘checkRequestHeaders’ option enabled in your Web Application Firewall profile.

To prevent misuse of the scripts on your protected web sites to breach security on your web sites, the HTML Cross-Site Scripting check blocks scripts that violate the same origin rule, which states that scripts should not access or modify content on any server but the server on which they are located. Any script that violates the same origin rule is called a cross-site script, and the practice of using scripts to access or modify content on another server is called cross-site scripting. The reason cross-site scripting is a security issue is that a web server that allows cross-site scripting can be attacked with a script that is not on that web server, but on a different web server, such as one owned and controlled by the attacker.

Unfortunately, many companies have a large installed base of JavaScript-enhanced web content that violates the same origin rule. If you enable the HTML Cross-Site Scripting check on such a site, you have to generate the appropriate exceptions so that the check does not block legitimate activity.

The Web App Firewall offers various action options for implementing HTML Cross-Site Scripting protection. In addition to the Block, Log, Stats and Learn actions, you also have the option to Transform cross-site scripts to render an attack harmless by entity encoding the script tags in the submitted request. You can configure Check complete URL’s for cross-site scripting parameter to specify if you want to inspect not just the query parameters but the entire URL to detect XSS attack. You can configure InspectQueryContentTypes parameter to inspect request query portion for XSS attack for the specific content-types.

You can deploy relaxations to avoid false positives. The Web App Firewall learning engine can provide recommendations for configuring relaxation rules.

Following options are available for configuring an optimized HTML Cross-Site Scripting protection for your application:

• Block—If you enable block, the block action is triggered if the XSS tags are detected in the request.
• Log—If you enable the log feature, the HTML Cross-Site Scripting check generates log messages indicating the actions that it takes. If block is disabled, a separate log message is generated for each header or form field in which the XSS violation was detected.  However, only one message is generated when the request is blocked. Similarly, one log message per request is generated for the transform operation, even when XSS tags are transformed in multiple fields. You can monitor the logs to determine whether responses to legitimate requests are getting blocked. A large increase in the number of log messages can indicate attempts to launch an attack.
• Stats—If enabled, the stats feature gathers statistics about violations and logs. An unexpected surge in the stats counter might indicate that your application is under attack. If legitimate requests are getting blocked, you might have to revisit the configuration to see if you need to configure new relaxation rules or modify the existing ones.
• Learn—If you are not sure which relaxation rules might be ideally suited for your application, you can use the learn feature to generate HTML Cross-Site Scripting rule recommendations based on the learned data. The Web App Firewall learning engine monitors the traffic and provides learning recommendations based on the observed values. To get optimal benefit without compromising performance, you might want to enable the learn option for a short time to get a representative sample of the rules, and then deploy the rules and disable learning.
• Transform cross-site scripts—If enabled, the Web App Firewall makes the following changes to requests that match the HTML Cross-Site Scripting check:
  • Left angle bracket (<) to HTML character entity equivalent (<)
  • Right angle bracket (>) to HTML character entity equivalent (>)

This ensures that browsers do not interpret unsafe html tags, such as <script>, and thereby execute malicious code. If you enable both request-header checking and transformation, any special characters found in request headers are also modified as described above. If scripts on your protected web site contain cross-site scripting features, but your web site does not rely upon those scripts to operate correctly, you can safely disable blocking and enable transformation. This configuration ensures that no legitimate web traffic is blocked, while stopping any potential cross-site scripting attacks.

• Check complete URLs for cross-site scripting—If checking of complete URLs is enabled, the Web App Firewall examines entire URLs for HTML cross-site scripting attacks instead of checking just the query portions of URLs.
• InspectQueryContentTypes — If Request query inspection is configured, the App Firewall examines the query of requests for cross-site scripting attacks for the specific content-types. If you use the GUI, you can configure this parameter in the Settings tab of the App Firewall profile.

Important

As part of the streaming changes, the Web App Firewall processing of the Cross-site Scripting tags has changed. This change is applicable to 11.0 builds onwards. This change is also pertinent for the enhancement builds of 10.5.e that support request side streaming. In earlier releases, presence of either open bracket (<), or close bracket (>), or both open and close brackets (<>) was flagged as Cross-site Scripting Violation. The behavior has changed in the builds that include support for request side streaming. Only the close bracket character (>) is no longer considered as an attack.  Requests are blocked even when an open bracket character (<) is present, and is considered as an attack. The Cross-site scripting attack gets flagged.

XSS Fine grained Relaxations

The Web App Firewall gives you an option to exempt a specific form field, header, or Cookie from cross-site scripting inspection check. You can completely bypass the inspection for one or more of these fields by configuring relaxation rules.

The Web App Firewall allows you to implement tighter security by fine tuning the relaxation rules. An application might require the flexibility to allow specific patterns, but configuring a relaxation rule to bypass the security inspection might make the application vulnerable to attacks, because the target field is exempted from inspection for any cross-site scripting attack patterns. Cross-site scripting fine grained relaxation provides the option to allow specific attributes, tags, and patterns. The rest of the attributes, tags and patterns are blocked. For example, the Web App Firewall currently has a default set of more than 125 denied patterns. Because hackers can use these patterns in Cross-site script attacks, the Web App Firewall flags them as potential threats. You can relax one or more pattern(s) that are considered safe for the specific location. The rest of the potentially dangerous XSS patterns are still checked for the target location and continue to trigger the security check violations. You now have much tighter control.

The commands used in relaxations have optional parameters for Value Type and Value Expression. The value type can be left blank or you have an option to select Tag or Attribute or Pattern. If you leave the value type blank, the configured field of the specified URL is exempted from the Cross-Site Scripting check inspection.  If you select a value type, you must provide a value expression. You can specify whether the value expression is a regular expression or a literal string. When the input is matched against the allowed and denied list, only the specified expressions configured in the relaxation rules are exempted.

The Web App Firewall has the following XSS built-in lists:

1. XSS Allowed Attributes: There are 52 default allowed attributes, such as, abbr, accesskey, align, alt, axis, bgcolor, border, cellpadding, cellspacing, char, charoff, charset etc.
2. XSS Allowed Tags: There are 47 default allowed tags, such as, address, basefont, bgsound, big, blockquote, bg, br, caption, center, cite, dd, del etc.
3. XSS Denied Patterns: There are 129 default denied patterns, such as, FSCommand, javascript:, onAbort, onActivate etc.

Warning

Web App Firewall action URL’s are regular expressions. When configuring HTML cross-site scripting relaxation rules, you can specify Name, and Value Expression to be literal or RegEx. Regular expressions are powerful. Especially if you are not thoroughly familiar with PCRE-format regular expressions, double-check any regular expressions you write. Make sure that they define exactly the rule that you want to add as an exception, and nothing else. Careless use of wildcards, and especially of the dot-asterisk ( .*) metacharacter/wildcard combination, can have results that you do not want, such as blocking access to web content that you did not intend to block or allowing an attack that the HTML Cross-Site Scripting check would otherwise have blocked.

Points to Consider:

• Value expression is an optional argument. A field name might not have any value expression.
• A field name can be bound to multiple value expressions.
• Value expressions should be assigned a value type. The XSS value type can be: 1) Tag, 2) Attribute, or 3) Pattern.
• You can have multiple relaxation rules per field name/URL combination
• The form field names and the action URL’s are not case sensitive.

Using the Command Line to Configure the HTML Cross-Site Scripting check

To configure HTML Cross-Site Scripting check actions and other parameters by using the command line

If you use the command-line interface, you can enter the following commands to configure the HTML Cross-Site Scripting Check:

• set appfw profile “Parameter descriptions provided at bottom of the page.”)
• <name> -crossSiteScriptingAction (([block] [learn] [log] [stats]) | [**none**])
• set appfw profile “Parameter descriptions provided at bottom of the page.”)
• <name> **-crossSiteScriptingTransformUnsafeHTML** (ON | OFF)
• set appfw profile Parameter descriptions provided at bottom of the page.
• <name> -crossSiteScriptingCheckCompleteURLs (ON | OFF)
• set appfw profile Parameter descriptions provided at bottom of the page.
• <name> -checkRequestHeaders (ON | OFF) Parameter descriptions provided at bottom of the page.
• <name> -CheckRequestQueryNonHtml (ON | OFF) Parameter descriptions provided at bottom of the page.

To configure a HTML Cross-Site Scripting check relaxation rule by using the command line

Use the bind or unbind command to add or delete binding, as follows:

• bind appfw profile <name> -crossSiteScripting <String> [isRegex (REGEX | NOTREGEX)] <formActionURL> [-location <location>] [-valueType (Tag|Attribute|Pattern) [<valueExpression>]    [-isValueRegex (REGEX | NOTREGEX) ]]
• unbind appfw profile <name> -crossSiteScripting <String> <formActionURL> [-location <location>] [-valueType (Tag |Attribute|Pattern) [<valueExpression>]]

Using the GUI to configure the HTML Cross-Site scripting check

In the GUI, you can configure the HTML Cross-Site Scripting check in the pane for the profile associated with your application.

To configure or modify the HTML Cross-Site Scripting check by using the GUI

1. Navigate to Application Firewall > Profiles, highlight the target profile, and click Edit.
2. In the Advanced Settings pane, click Security Checks.

The security check table displays the currently configured action settings for all the security checks. You have 2 options for configuration:

a. If you just want to enable or disable Block, Log, Stats, and Learn actions for the HTML Cross-Site Scripting, you can select or clear check boxes in the table, click OK, and then click Save and Close to close the Security Check pane.

b. If you want to configure additional options for this security check, double click HTML Cross-Site Scripting, or select the row and click Action Settings, to display the following options:

Transform cross-site scripts—Transform unsafe script tags.

Check complete URLs for Cross-site scripting—Instead of checking just the query part of the URL, check the complete URL for cross-site script violations.

After changing any of the above settings, click OK to save the changes and return to the Security Checks table. You can proceed to configure other security checks if needed. Click OK to save all the changes you have made in the Security Checks section, and then click Save and Close to close the Security Check pane.

To enable or disable the Check request Header setting, in the Advanced Settings pane, click Profile Settings. In Common Settings, Select or clear the Check Request Headers check box. Click OK.  You can either use the X icon at the top right hand side of the Profile Settings pane to close this section or, if you have finished configuring this profile, you can click Done to return to the Application Firewall > Profile.

To enable or disable the InspectQueryContentTypes setting, in the Advanced Settings pane, click Profile Settings. In Common Settings, Select or clear the InspectQueryContentTypes check box. Click OK. You can either use the X icon at the top right hand side of the Profile Settings pane to close this section or, if you have finished configuring this profile, you can click Done to return to the App Firewall > Profile.

To configure a HTML Cross-Site Scripting relaxation rule by using the GUI

1. Navigate to Application Firewall > Profiles, highlight the target profile, and click Edit.
2. In the Advanced Settings pane, click Relaxation Rules.
3. In the Relaxation Rules table, double-click the HTML Cross-Site Scripting entry, or select it and click Edit.
4. In the HTML Cross-Site Scripting Relaxation Rules dialogue box, perform Add, Edit, Delete, Enable, or Disable operations for relaxation rules.

Note

When you add a new rule, the Value Expression field is not displayed unless you select Tag or Attribute or Pattern option in the Value Type Field.

To manage HTML Cross-Site Scripting relaxation rules by using the visualizer

For a consolidated view of all the relaxation rules, you can highlight the HTML Cross-Site Scripting row in the Relaxation Rules table, and click Visualizer. The visualizer for deployed relaxations offers you the option to Add a new rule or Edit an existing one. You can also Enable or Disable a group of rules by selecting a node and clicking the corresponding buttons in the relaxation visualizer.

To view or customize the Cross-Site Scripting patterns by using the GUI

You can use the GUI to view or customize the default list of XSS allowed attributes or allowed tags. You can also view or customize the default list of XSS denied Patterns.

The default lists are specified in Application Firewall > Signatures > Default Signatures.  If you do not bind any signature object to your profile, the default XSS allowed and denied list specified in the Default Signatures object will be used by the profile for the Cross-Site Scripting security check processing. The Tags, Attributes, and Patterns, specified in the default signatures object, are read-only. You cannot edit or modify them.  If you want to modify or change these, make a copy of the Default Signatures object to create a User-Defined signature object. Make changes in the allowed or denied lists in the new User-defined signature object and use this signature object in your profile that is processing the traffic for which you want to use these customized allowed and denied lists.

For more information about Signatures, see the following topic..

1. To view default XSS patterns:

a.  Navigate to Application Firewall > Signatures, select *Default Signatures, and click Edit. Then click Manage SQL/XSS Patterns.

The Manage SQL/XSS Paths table shows following three rows pertaining to XSS :

xss/allowed/attribute

xss/allowed/tag

xss/denied/pattern

b.  Select a row and click Manage Elements to display the corresponding XSS Elements (Tag, Attribute, Pattern) used by the Web App Firewall Cross-Site Scripting check.

1.  To customize XSS Elements: You can edit the User-Defined signature object to customize the allowed Tag, allowed Attributes and denied Patterns. You can add new entries or remove the existing ones.

a.  Navigate to Application Firewall > Signatures, highlight the target User-defined signature, and click Edit.  Click Manage SQL/XSS Patterns to display the Manage SQL/XSS paths table.

b.  Select the target XSS row.

 i.  Click Manage Elements, to Add, Edit or Remove the corresponding XSS element.

ii.  Click Remove to remove the selected row.

Warning

You must be very careful before you remove or modify any default XSS element, or delete the XSS path to remove the entire row. The signature rules as well as the Cross-Site Scripting security check rely on these elements for detecting attacks to protect your applications. Customizing the XSS Elements can make your application vulnerable to Cross-Site Scripting attacks if the required pattern is removed during editing.

Using the Learn Feature with the HTML Cross-Site Scripting Check

When the learn action is enabled, the Web App Firewall learning engine monitors the traffic and learns the triggered violations. You can periodically inspect these learned rules. After due consideration, you can deploy the learned rule as a HTML Cross-Site Scripting relaxation rule.

HTML Cross-Site Scripting Learning enhancement—An Web App Firewall learning enhancement was introduced in release 11.0 of the Citrix ADC software.  To deploy fine grained HTML Cross-Site Scripting relaxation, the Web App Firewall offers fine grained HTML Cross-Site Scripting learning.  The learning engine makes recommendations regarding the observed Value Type (Tag, Attribute, Pattern) and the corresponding Value expression observed in the input fields. In addition to checking the blocked requests to determine whether the current rule is too restrictive and needs to be relaxed, you can review the rules generated by the learning engine to determine which value type and value expressions are triggering violations and need to be addressed in relaxation rules.

Note

The Web App Firewall’s learning engine can distinguish only the first 128 bytes of the name. If a form has multiple fields with names that match for the first 128 bytes, the learning engine might not be able to distinguish between them. Similarly, the deployed relaxation rule might inadvertently relax all such fields from HTML Cross-Site Scripting inspection. Tip

XSS tags which are longer than 12 characters are not learned or logged correctly.

If you need a larger taglength for learning, you can add a large non-appearing tag in the AS_XSS_ALLOWED_TAGS_LIST for length ‘x’.

To view or use learned data by using the command line interface

At the command prompt, type one of the following commands:

• show appfw learningdata <profilename> crossSiteScripting
• rm appfw learningdata <profilename> -crossSiteScripting <string>  <formActionURL>  [<location>]  [<valueType>  <valueExpression>]
• export appfw learningdata <profilename> **crossSiteScripting*

To view or use learned data by using the GUI

1. Navigate to Application Firewall > Profiles, highlight the target profile, and click Edit.
2. In the Advanced Settings pane, click Learned Rules. You can select the HTML Cross-Site Scripting entry in the Learned Rules table and double-click it to access the learned rules. The table displays the Field Name, Action URL, Value Type, Value and Hits columns. You can deploy the learned rules or edit a rule before deploying it as a relaxation rule. To discard a rule, you can select it and click the Skip button. You can edit only one rule at a time, but you can select multiple rules to deploy or skip.

You also have the option to show a summarized view of the learned relaxations by selecting the HTML Cross-Site Scripting entry in the Learned Rules table and clicking Visualizer to get a consolidated view of all the learned violations. The visualizer makes it very easy to manage the learned rules. It presents a comprehensive view of the data on one screen and facilitates taking action on a group of rules with one click. The biggest advantage of the visualizer is that it recommends regular expressions to consolidate multiple rules. You can select a subset of these rules, based on the delimiter and Action URL. You can display 25, 50, or 75 rules in the visualizer, by selecting the number from a drop-down list. The visualizer for learned rules offers the option to edit the rules and deploy them as relaxations. Or you can skip the rules to ignore them.

Using the Log Feature with the HTML Cross-Site Scripting Check

When the log action is enabled, the HTML Cross-Site Scripting security check violations are logged in the audit log as APPFW_XSS violations. The Web App Firewall supports both Native and CEF log formats. You can also send the logs to a remote syslog server.

To access the log messages by using the command line

Switch to the shell and tail the ns.logs in the /var/log/ folder to access the log messages pertaining to the HTML Cross-Site Scripting violations:

Shell
tail -f /var/log/ns.log | grep APPFW_XSS
<!--NeedCopy-->

Example of a Cross-Site Scripting security check violation log message in CEF log format

Jul 11 00:45:51 <local0.info> 10.217.31.98 CEF:0|Citrix|Citrix ADC|NS11.0|APPFW|**APPFW_XSS**|6|src=10.217.253.62 geolocation=Unknown spt=4840 method=GET request=http://aaron.stratum8.net/FFC/CreditCardMind.html?abc\=%3Cdef%3E msg=**Cross-site script check failed for field abc=\"Bad tag: def"** cn1=133 cn2=294 cs1=pr_ffc cs2=PPE1 cs3=eUljypvLa0BbabwfGVE52Sewg9U0001 cs4=ALERT cs5=2015 act=**not blocked**
<!--NeedCopy-->

Example of a Cross-Site Scripting security check violation log message in Native log format showing transform action

Jul 11 01:00:28 <local0.info> 10.217.31.98 07/11/2015:01:00:28 GMT ns 0-PPE-0 : default APPFW **APPFW_XSS** 132 0 :  10.217.253.62 392-PPE0 eUljypvLa0BbabwfGVE52Sewg9U0001 pr_ffc http://aaron.stratum8.net/FFC/login.php?login_name=%3CBOB%3E&passwd=&drinking_pref=on &text_area=&loginButton=ClickToLogin&as_sfid=AAAAAAVFqmYL68IGvkrcn2pzehjfIkm5E6EZ9FL8YLvIW_41AvAATuKYe9N7uGThSpEAxbb0iBx55jyvqOZNiVK_XwEPstMYvWHxfUWl62WINwRMrKsEDil-FC4llF **Cross-site script special characters seen in fields <transformed>**
<!--NeedCopy-->

To access the log messages by using the GUI

The Citrix GUI includes a useful tool (Syslog Viewer) for analyzing the log messages. You have multiple options for accessing the Syslog Viewer:

• Navigate to the Application Firewall > Profiles, select the target profile, and click Security Checks. Highlight the HTML Cross-Site Scripting row and click Logs.  When you access the logs directly from the HTML Cross-Site Scripting check of the profile, the GUI filters out the log messages and displays only the logs pertaining to these security check violations.
• You can also access the Syslog Viewer by navigating to Citrix ADC > System > Auditing.  In the Audit Messages section, click the Syslog messages link to display the Syslog Viewer, which displays all log messages, including other security check violation logs. This is useful for debugging when multiple security check violations might be triggered during request processing.
• Navigate to Application Firewall > policies > Auditing. In the Audit Messages section, click the Syslog messages link to display the Syslog Viewer, which displays all log messages, including other security check violation logs.

The HTML based Syslog Viewer provides various filter options for selecting only the log messages that are of interest to you.  To select log messages for the HTML Cross-Site Scripting check, filter by selecting APPFW in the dropdown options for Module. The Event Type list offers a rich set of options to further refine your selection. For example, if you select the APPFW_XSS check box and click the Apply button, only log messages pertaining to the HTML Cross-Site Scripting security check violations appear in the Syslog Viewer.

If you place the cursor in the row for a specific log message, multiple options, such as Module, Event Type, Event ID, Client IP etc. appear below the log message. You can select any of these options to highlight the corresponding information in the log message.

Click to Deploy functionality is available only in the GUI. You can use the Syslog Viewer to not only view the logs but also to deploy HTML Cross-Site Scripting relaxation rules based on the log messages for the Web App Firewall security check violations. The log messages must be in CEF log format for this operation. Click to deploy functionality is available only for log messages that are generated by the block (or not block) action. You cannot deploy a relaxation rule for a log message about the transform operation.

To deploy a relaxation rule from the Syslog Viewer, select the log message. A check box appears in the upper right corner of the Syslog Viewer box of the selected row. Select the check box, and then select an option from the Action list to deploy the relaxation rule. Edit & Deploy, Deploy, and Deploy All are available as Action options.

The HTML Cross-Site Scripting rules that are deployed by using the Click to Deploy option do not include the fine grain relaxation recommendations.

To use Click to Deploy functionality in the GUI

1. In the Syslog Viewer, select APPFW in the Module options.
2. Select the APP_XSS as the Event Type to filter corresponding log messages.
3. Select the check box to identify the rule to deploy.
4. Use the Action drop-down list of options to deploy the relaxation rule.
5. Verify that the rule appears in the corresponding relaxation rule section.

Statistics for the HTML Cross-Site Scripting violations

When the stats action is enabled, the counter for the HTML Cross-Site Scripting check is incremented when the Web App Firewall takes any action for this security check. The statistics are collected for Rate and Total count for Traffic, Violations, and Logs. The size of an increment of the log counter can vary depending on the configured settings. For example, if the block action is enabled, the request for a page that contains 3 HTML Cross-Site Scripting violations increments the stats counter by one, because the page is blocked as soon as the first violation is detected. However, if block is disabled, processing the same request increments the statistics counter for violations and the logs by three, because each violation generates a separate log message.

To display HTML Cross-Site Scripting check statistics by using the command line

At the command prompt, type:

sh appfw stats
<!--NeedCopy-->

To display stats for a specific profile, use the following command:

stat appfw profile** <profile name>
<!--NeedCopy-->

To display HTML Cross-Site Scripting statistics by using the GUI

1. Navigate to Security > Application Firewall > Profiles > Statistics.
2. In the right pane, access the Statistics Link.
3. Use the scroll bar to view the statistics about HTML Cross-Site Scripting violations and logs. The statistics table provides real-time data and is updated every 7 seconds.

Highlights

Note the following points about the HTML Cross-Site Scripting check:

• Built-in Support for HTML Cross-Site Scripting attack Protection—The Citrix Web App Firewall protects against Cross-Site Scripting attacks by monitoring a combination of allowed attributes and tags, as well as denied patterns in the received payload. All the built-in default allowed tags, allowed attributes and denied patterns used by the XSS check are specified in the /netscaler/default_custom_settings.xml file.
• Customization—You can change the default list of tags, attributes, and patterns to customize the Cross-Site Scripting security check inspection for the specific needs of your application. Make a copy of the default signature object, modify existing entries, or add new ones. Bind this signature object to your profile to make use of the customized configuration.
• Hybrid Security Model—Both signatures and deep security protections use the SQL/XSS patterns specified in the signature object that is bound to the profile. If no signature object is bound to the profile, the SQL/XSS patterns present in the default signature object are used.
• Transform—Note the following about the transform operation:

The transform operation works independently of the other Cross-Site Scripting action settings. If transform is enabled and block, log, stats, and learn are all disabled, XSS tags will be transformed.

If the block action is enabled, it takes precedence over the transform action.

• Fine Grained Relaxation and Learning—Fine tune the relaxation rule to relax a subset of XSS elements from security check inspection but detect the rest. The learning engine recommends a specific value type and value expressions based on the observed data.
• Click to Deploy—Select one, or multiple XSS violation log messages in the syslog viewer and deploy them as relaxation rules.
• Charset—The default charset for the profile should be set based on the need of the application. By default, the profile charset is set to English US (ISO-8859-1). If a request is received without the specified charset, the Web App Firewall processes the request as if it is ISO-8859-1. The open bracket character (<) or the close bracket character (>) will not get interpreted as XSS tags if these characters are encoded in other charsets. For example, if a request contains a UTF-8 character string “%uff1cscript%uff1e” but the charset is not specified on the request page, the XSS violation might not get triggered unless the default charset for the profile is specified as Unicode.