HTML cross-site scripting check 编辑

The HTML Cross-Site Scripting (cross-site scripting) 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 (cross-site scripting) check works only for content type, content length, and so forth. Also ensure to have the ‘checkRequestHeaders’ option enabled in your Web Application Firewall profile.

You can prevent misuse of the scripts on your protected websites by using the HTML Cross-Site Scripting scripts that violate the same origin rule, which states that scripts must 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 the entity encoding the script tags in the submitted request. You can configure Check complete URLs for cross-site scripting parameter to specify if you want to inspect not just the query parameters but the entire URL to detect cross-site scripting attack. You can configure the InspectQueryContentTypes parameter to inspect the request query portion for the cross-site scripting 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.

To configure an optimized HTML Cross-Site Scripting protection for your application, configure one of the actions:

• Block—If you enable block, the block action is triggered if the cross-site scripting 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 cross-site scripting violation was detected. However, only one message is generated when the request is blocked. Similarly, 1 log message per request is generated for the transform operation, even when cross-site scripting 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 must configure the 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 run malicious code. If you enable both request-header checking and transformation, any special characters found in request headers are also modified. If the scripts on your protected website contain cross-site scripting features, but your website 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.
• Check Request headers. If Request header checking is enabled, the Web App Firewall examines the headers of requests for HTML cross-site scripting attacks, instead of just URLs. If you use the GUI, you can enable this parameter in the Settings tab of the Web App Firewall profile.
• 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, the 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.

Cross-site scripting Fine grained Relaxations

The Web App Firewall gives you an option to exempt a specific form field, header, or Cookie from the cross-site scripting inspection check. You can completely bypass the inspection for one or more of these fields by configuring the 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 patterns that are considered safe for the specific location. The rest of the potentially dangerous cross-site scripting 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 cross-site scripting built-in lists:

1. cross-site scripting Allowed Attributes: There are 52 defaults allowed attributes, such as, abbr, accesskey, align, alt, axis, bgcolor, border, cell padding, cell spacing, char, charoff, charset and so forth
2. cross-site scripting Allowed Tags: There are 47 defaults allowed tags, such as, address, basefont, bgsound, big, blockquote, bg, br, caption, center, cite, dd, del and so forth
3. cross-site scripting Denied Patterns: There are 129 defaults denied patterns, such as, FSCommand, javascript:, onAbort, onActivate and so forth

Warning

Web App Firewall action URLs 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 or the 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 must be assigned a value type. The cross-site scripting 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 URLs 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 topic.
• <name> -crossSiteScriptingAction (([block] [learn] [log] [stats]) | [**none**])
• [set appfw profile topic.
• <name> **-crossSiteScriptingTransformUnsafeHTML** (ON | OFF)
• set appfw profile topic.
• <name> -crossSiteScriptingCheckCompleteURLs (ON | OFF)
• set appfw profile topic.
• `- checkRequestHeaders (ON | OFF)
• <name> - CheckRequestQueryNonHtml (ON | OFF)

To configure an 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 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 more 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 Check request Query Non HTML setting, in the Advanced Settings pane, click Profile Settings. In Common Settings, Select or clear the Check request Query Non HTML 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 an 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 cross-site scripting allowed attributes or allowed tags. You can also view or customize the default list of cross-site scripting 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 cross-site scripting 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.

1. To view default cross-site scripting patterns:

a. Navigate to Application Firewall > Signatures, select Default Signatures, and click Edit. Then click Manage SQL/cross-site scripting Patterns.

The Manage SQL/cross-site scripting Paths table shows the following three rows pertaining to cross-site scripting:

xss/allowed/attribute

xss/allowed/tag

xss/denied/pattern

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

1. To customize cross-site scripting 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/cross-site scripting Patterns to display the Manage SQL/cross-site scripting paths table.

b. Select the target cross-site scripting row.

i. Click Manage Elements, to Add, Edit or Remove the corresponding cross-site scripting element.

ii. Click Remove to remove the selected row.

Warning:

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

Learn HTML Cross-Site Scripting (cross-site scripting) violations

With learning enabled, the Citrix Web App Firewall learning engine monitors the traffic and learns the cross-site scripting URL violations. You can periodically inspect cross-site scripting URL rules and deploy it for false positive scenarios.

Note:

In a cluster configuration, all nodes must be of the same version to deploy the cross-site scripting URL rules.

As part of the learning configuration, 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 the 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:

Cross-site scripting tags which are longer than 12 characters are not learned or logged correctly.

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

The HTML Cross-Site Scripting learning process reduces false positives in cross-site scripting attacks. With learning enabled, you can learn all violations in a request and potentially apply relaxation to multiple tags, attributes, or patterns without the need of repetition.

For example, if there are 15 custom tags in a payload each resulting in a violation, you can apply the fine grain relaxation for all tags that are flagged as a violation, instead of repeating the process to apply relaxation for one tag at a time.

Scenario 1: Learning enabled, and block enabled: In this scenario, the Citrix ADC appliance learns all the violations in custom tags/attributes/patterns, and the request is blocked and each violation is logged. The behavior is consistent for violations identified in form field, header, or cookie.

Scenario 2: Learning enabled and block disabled: In this scenario, the Citrix ADC appliance learns the violations in custom tags/attributes/patterns and each of the violations is logged. The request is not blocked. The behavior is consistent for violations identified in form field, header, or cookie.

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*

Configure cross-site scripting fine grain relaxation to bypass custom tags

You can configure cross-site scripting relaxation in the web app firewall profile to bypass custom tags/attributes/patterns not present in the allow list. At the command prompt, type:

bind appfw profile p1 -crossSiteScripting <string> <formActionURL> -valueType <valueType> <value expression>

Example:

bind appfw profile profile1 -crossSiteScripting formfield1 http://1.1.1.1 -valueType Tag tag1

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 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_cross-site scripting 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_cross-site scripting

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_cross-site scripting**|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-->