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 thesame 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 theBlock,Log,StatsandLearnactions, you also have the option toTransform cross-site scriptsto 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 configureInspectQueryContentTypes parameterto 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如果你启用日志特性,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, 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
作为流变化的一部分,Web应用程序wall 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 forValue TypeandValue Expression. The value type can be left blank or you have an option to selectTagorAttributeorPattern. 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:
- XSS Allowed Attributes: There are 52 default allowed attributes, such as,abbr,accesskey,align,alt,axis,bgcolor,border,cellpadding,cellspacing,char,charoff,charsetetc.
- XSS Allowed Tags: There are 47 default allowed tags, such as,address,basefont,bgsound,big,blockquote,bg,br,caption,center,cite,dd,deletc.
- XSS Denied Patterns: There are 129 default denied patterns, such as,FSCommand,javascript:,onAbort,onActivateetc.
Warning
我们b App Firewall action URL’s are regular expressions. When configuring HTML cross-site scripting relaxation rules, you can specifyName, andValue Expressionto 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.”)
-crossSiteScriptingAction (([block] [learn] [log] [stats]) | [**none**]) - set appfw profile“Parameter descriptions provided at bottom of the page.”)
**-crossSiteScriptingTransformUnsafeHTML** (ON | OFF) - set appfw profileParameter descriptions provided at bottom of the page.
-crossSiteScriptingCheckCompleteURLs (ON | OFF) - set appfw profileParameter descriptions provided at bottom of the page.
Parameter descriptions provided at bottom of the page.-checkRequestHeaders (ON | OFF)
Parameter descriptions provided at bottom of the page.-CheckRequestQueryNonHtml (ON | OFF)
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
-crossSiteScripting [isRegex (REGEX | NOTREGEX)] [-location ] [-valueType (Tag|Attribute|Pattern) [ ] [-isValueRegex (REGEX | NOTREGEX) ]] unbind appfw profile
-crossSiteScripting [-location ] [-valueType (Tag |Attribute|Pattern) [ ]]
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
- Navigate toApplication Firewall>Profiles, highlight the target profile, and clickEdit.
- 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,Stats, andLearnactions for the HTML Cross-Site Scripting, you can select or clear check boxes in the table, clickOK, and then clickSave and Closeto close the Security Check pane.
b. If you want to configure additional options for this security check, double clickHTML Cross-Site Scripting, or select the row and clickAction 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, 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 enable or disable theCheck request Headersetting, in theAdvanced Settingspane, clickProfile Settings. InCommon Settings, Select or clear theCheck Request Headerscheck box. ClickOK. 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 clickDoneto return to theApplication Firewall>Profile.
To enable or disable theInspectQueryContentTypessetting, in theAdvanced Settingspane, clickProfile Settings. InCommon Settings, Select or clear theInspectQueryContentTypescheck box. ClickOK. You can either use the X icon at the top right hand side of theProfile Settingspane to close this section or, if you have finished configuring this profile, you can clickDoneto return to theApp Firewall > Profile.
To configure a HTML Cross-Site Scripting relaxation rule by using the GUI
- Navigate toApplication Firewall>Profiles, highlight the target profile, and clickEdit.
- In theAdvanced Settingspane, clickRelaxation Rules.
- In the Relaxation Rules table, double-click theHTML Cross-Site Scriptingentry, or select it and clickEdit.
- In theHTML Cross-Site Scripting Relaxation Rulesdialogue box, performAdd,Edit,删除,Enable, orDisableoperations for relaxation rules.
Note
When you add a new rule, theValue Expressionfield is not displayed unless you selectTagorAttributeorPatternoption in theValue TypeField.
To manage HTML Cross-Site Scripting relaxation rules by using the visualizer
For a consolidated view of all the relaxation rules, you can highlight theHTML 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
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 inApplication 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 aboutSignatures, see the following topic..
- To view default XSS patterns:
a. Navigate toApplication Firewall>Signatures, select*Default Signatures, and clickEdit. Then clickManage SQL/XSS Patterns.
The Manage SQL/XSS Pathstable shows following three rows pertaining to XSS :
xss/allowed/attribute
xss/allowed/tag
xss/denied/pattern
b. 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.
a. Navigate toApplication Firewall>Signatures, highlight the target User-defined signature, and clickEdit. ClickManage SQL/XSS Patternsto display theManage SQL/XSS pathstable.
b. Select the target XSS row.
i. Click Manage Elements, to Add, Edit or Remove the corresponding XSS element.
ii. ClickRemoveto 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 enhancementintr——Web应用防火墙学习增强oduced 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 theAS_XSS_ALLOWED_TAGS_LISTfor 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
crossSiteScripting rm appfw learningdata
-crossSiteScripting [ ] [ ] export appfw learningdata
**crossSiteScripting*
To view or use learned data by using the GUI
- Navigate toApplication Firewall>Profiles, highlight the target profile, and clickEdit.
- In theAdvanced Settingspane, clickLearned Rules. You can select theHTML Cross-Site Scriptingentry in the Learned Rules table and double-click it to access the learned rules. The table displays theField Name, Action URL,Value Type,ValueandHitscolumns. 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 theSkipbutton. 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 theHTML Cross-Site Scriptingentry in the Learned Rules table and clickingVisualizerto 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 asAPPFW_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 HTML Cross-Site Scripting violations:
Shell tail -f /var/log/ns.log | grep APPFW_XSS
跨站点脚本编制安全检查v的例子iolation log message in CEF log format
7月11日00:45:51 <轨迹l0.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**
跨站点脚本编制安全检查v的例子iolation log message in Native log format showing transform action
Jul 11 01:00:28 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 **
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 theApplication Firewall>Profiles, select the target profile, and clickSecurity Checks. Highlight theHTML Cross-Site Scriptingrow and clickLogs. 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 toCitrix ADC>System>Auditing. In the Audit Messages section, click theSyslog messageslink 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 toApplication Firewall>policies>Auditing. In the Audit Messages section, click theSyslog messageslink 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 theHTML 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_XSScheck box and click theApplybutton, 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 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.
Click to Deployfunctionality 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 theActionlist to deploy the relaxation rule.Edit & Deploy,Deploy, andDeploy Allare available asActionoptions.
The HTML Cross-Site Scripting rules that are deployed by using theClick to Deployoption do not include the fine grain relaxation recommendations.
To use Click to Deploy functionality in the GUI
- In the Syslog Viewer, selectAPPFWin theModuleoptions.
- Select theAPP_XSSas theEvent Typeto filter corresponding log messages.
- Select the check box to identify the rule to deploy.
- Use theActiondrop-down list of options to deploy the relaxation rule.
- 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
To display stats for a specific profile, use the following command:
stat appfw profile**
To display HTML Cross-Site Scripting statistics by using the GUI
- Navigate toSecurity>Application Firewall > Profiles > Statistics.
- In the right pane, access theStatisticsLink.
- 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——在调优规则放松放松啊一个子集f 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.
In this article
- XSS Fine grained Relaxations
- Using the Command Line to Configure the HTML Cross-Site Scripting check
- Using the GUI to configure the HTML Cross-Site scripting check
- Using the Learn Feature with the HTML Cross-Site Scripting Check
- Using the Log Feature with the HTML Cross-Site Scripting Check
- Statistics for the HTML Cross-Site Scripting violations
- Highlights