XML cross-site scripting check

The XML Cross-Site Scripting check examines the user requests for possible cross-site scripting attacks in the XML payload. If it finds a possible cross-site scripting attack, it blocks the request.

To prevent misuse of the scripts on your protected web services to breach security on your web services, the XML 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.

The Web App Firewall offers various action options for implementing XML Cross-Site Scripting protection. You have the option to configureBlock,Log, andStatsactions.

The Web App Firewall XML XSS check is performed on the payload of the incoming requests and attack strings are identified even if they are spread over multiple lines. The check looks for XSS attack strings in theelementand theattributevalues. You can apply relaxations to bypass security check inspection under specified conditions. The logs and statistics can help you identify needed relaxations.

The CDATA section of the XML payload might be an attractive area of focus for the hackers because the scripts are not executable outside the CDATA section. A CDATA section is used for content that is to be treated entirely as character data. HTML mark up tag delimiters “<”, “>”, and “/>” will not cause the parser to interpret the code as HTML elements. The following example shows a CDATA Section with XSS attack string:

alert ("Got you")rn ]]> 

Action Options

An action is applied when the XML Cross-Site Scripting check detects an XSS attack in the request. The following options are available for optimizing XML Cross-Site Scripting protection for your application:

• Block—Block action is triggered if the XSS tags are detected in the request.
• Log—Generate log messages indicating the actions taken by the XML Cross-Site Scripting check. If block is disabled, a separate log message is generated for each location (ELEMENT, ATTRIBUTE) in which the XSS violation is detected. However, only one message is generated when the request is blocked. 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—Gather 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.

Relaxation Rules

If your application requires you to bypass the Cross-Site Scripting check for a specific ELEMENT or ATTRIBUTE in the XML payload, you can configure a relaxation rule. The XML Cross-Site Scripting check relaxation rules have the following parameters:

• Name—You can use literal strings or regular expressions to configure the name of the ELEMENT or the Attribute. The following expression exempts all ELEMENTS beginning with the string name_ followed by a string of uppercase or lowercase letters, or numbers, that is at least two and no more than fifteen characters long:

^name_[0-9A-Za-z]{2,15}$

Note

名称是区分大小写的。重复的条目基于“增大化现实”技术e not allowed, but you can use capitalization of the names and differences in location to create similar entries. For example, each of the following relaxation rules is unique:

1) XMLXSS: ABC IsRegex: NOTREGEX Location: ATTRIBUTE State: ENABLED

2) XMLXSS: ABC IsRegex: NOTREGEX Location: ELEMENT State: ENABLED

3) XMLXSS: abc IsRegex: NOTREGEX Location: ELEMENT State: ENABLED

4) XMLXSS: abc IsRegex: NOTREGEX Location: ATTRIBUTE State: ENABLED

• Location—You can specify the Location of the Cross-site Scripting Check exception in your XML payload. The option ELEMENT is selected by default. You can change it to ATTRIBUTE.
• Comment—This is an optional field. You can use up to a 255 character string to describe the purpose of this relaxation Rule.

Warning

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 name that you want to add as an exception, and nothing else. Careless use of Regular Expressions 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 XML Cross-Site Scripting check would otherwise have blocked.

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

To configure XML 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 XML Cross-Site Scripting Check:

> set appfw profile -XMLXSSAction (([block] [log] [stats]) | [none])

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

You can add relaxation rules to bypass inspection of XSS script attack inspection in a specific location. Use the bind or unbind command to add or delete the relaxation rule binding, as follows:

> bind appfw profile -XMLXSS [isRegex (REGEX | NOTREGEX)] [-location ( ELEMENT | ATTRIBUTE )] –comment [-state ( ENABLED | DISABLED )]

> unbind appfw profile -XMLXSS

Example:

> bind appfw profile test_pr -XMLXSS ABC

After executing the above command, the following relaxation rule is configured. The rule is enabled, the name is treated as a literal (NOTREGEX), and ELEMENT is selected as the default location:

1) XMLXSS: ABC IsRegex: NOTREGEX Location: ELEMENT State: ENABLED `> unbind appfw profile test_pr -XMLXSS abc` ERROR: No such XMLXSS check `> unbind appfw profile test_pr -XMLXSS ABC` Done 

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

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

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

1. Navigate to我们b App Firewall>Profiles, highlight the target profile, and clickEdit.
2. In the Advanced Settings pane, clickSecurity 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 disableBlock,Log, andStatsactions for theXML Cross-Site Scripting check, you can select or clear check boxes in the table, clickOK, and then click Save and Close to close the Security Check pane.

b) You can double clickXML Cross-Site Scripting, or select the row and clickAction Settings, to display the action options. After changing any of the action settings, clickOKto save the changes and return to the Security Checks table.

You can proceed to configure other security checks if needed. ClickOKto save all the changes you have made in the Security Checks section, and then clickSave and Closeto close the Security Check pane.

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

1. Navigate to我们b App Firewall>Profiles, highlight the target profile, and clickEdit.
2. In theAdvanced Settingspane, clickRelaxation Rules.
3. In the Relaxation Rules table, double-click theXML Cross-Site Scriptingentry, or select it and clickEdit.
4. In theXML Cross-Site Scripting Relaxation Rulesdialogue box, performAdd,Edit,删除,Enable, orDisable放松规则操作。

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

For a consolidated view of all the relaxation rules, you can highlight theXML Cross-Site Scriptingrow in the Relaxation Rules table, and clickVisualizer. The visualizer for deployed relaxations offers you the option toAdda new rule orEditan existing one. You can alsoEnableorDisablea 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

您可以使用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我们b App 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 the profile that is processing the traffic for which you want to use these customized allowed and denied lists.

For more information about signatures, seehttp://support.citrix.com/proddocs/topic/ns-security-10-map/appfw-signatures-con.html.

To view default XSS patterns:

1. Navigate to我们b App Firewall>Signatures, select*Default Signatures, and clickEdit. Then clickManage SQL/XSS Patterns.

TheManage SQL/XSS Pathstable shows following three rows pertaining to XSS :

xss/allowed/attribute xss/allowed/tag xss/denied/pattern 

Select a row and clickManage Elementsto display the corresponding XSS Elements (Tag, Attribute, Pattern) used by the Web App FirewallCross-Site Scriptingcheck.

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.

1. Navigate to Web App Firewall>Signatures, highlight the target user-defined signature, and clickEdit. ClickManage SQL/XSS Patternsto display theManage SQL/XSS pathstable.
2. Select the target XSS row.

a) ClickManage Elements, toAdd,EditorRemovethe corresponding XSS element.

b) ClickRemoveto remove the selected row.

Warning

Be very careful when you remove or modify any default XSS element, or delete the XSS path to remove the entire row. The signatures, HTML Cross-Site Scripting security check, and XML 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 log feature with the XML cross-site scripting check

When the log action is enabled, the XML Cross-Site Scripting security check violations are logged in the audit log asAPPFW_XML_XSSviolations. 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 XML Cross-Site Scripting violations:

> **Shell** > **tail -f /var/log/ns.log | grep APPFW_XML_XSS** 

Example of a XML Cross-Site Scripting security check violation log message in Native log format showingaction

Oct 7 01:44:34  10.217.31.98 10/07/2015:01:44:34 GMT ns 0-PPE-1 : default APPFW APPFW_XML_XSS 1154 0 : 10.217.253.69 3466-PPE1 - owa_profile http://10.217.31.101/FFC/login.html Cross-site script check failed for field script="Bad tag: script" <**blocked**> 

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

Oct 7 01:46:52  10.217.31.98 CEF:0|Citrix|Citrix ADC|NS11.0|APPFW|APPFW_XML_XSS|4|src=10.217.30.17 geolocation=Unknown spt=33141 method=GET request=http://10.217.31.101/FFC/login.html msg=Cross-site script check failed for field script="Bad tag: script" cn1=1607 cn2=3538 cs1=owa_profile cs2=PPE0 cs4=ERROR cs5=2015 act=**not blocked** 

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我们b App Firewall>Profiles, select the target profile, and clickSecurity Checks. Highlight theXML Cross-Site Scriptingrow and clickLogs. When you access the logs directly from the XML 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 toCitrix 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我们b App Firewall>政策>Auditing. In theAudit Messagessection, click theSyslog messageslink to display the Syslog Viewer, which displays all log messages, including other security check violation logs.

The XML based Syslog Viewer provides various filter options for selecting only the log messages that are of interest to you. To select log messages for theXML Cross-Site Scriptingcheck, filter by selectingAPPFWin the dropdown options forModule. TheEvent Typelist offers a rich set of options to further refine your selection. For example, if you select theAPPFW_XML_XSScheck box and click theApplybutton, only log messages pertaining to the XML 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 asModule,Event Type,Event ID,Client IPetc. appear below the log message. You can select any of these options to highlight the corresponding information in the log message.

Statistics for the XML cross-site scripting violations

When the stats action is enabled, the counter for the XML 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, a request for a page that contains three XML 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 XML Cross-Site Scripting check statistics by using the command line

At the command prompt, type:

> **sh appfw stats**

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

> **stat appfw profile**

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

1. Navigate toSystem>Security>我们b App Firewall.
2. In the right pane, access theStatisticsLink.
3. 使用滚动条来查看关于XM的统计数据L Cross-Site Scripting violations and logs. The statistics table provides real-time data and is updated every 7 seconds.