- HTML Cross-Site Scripting Check
- HTML SQL Injection Check
- Buffer Overflow Check
- Cookie Consistency Check
- Application Firewall Support for Google Web Toolkit
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.
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.
The application 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 deploy relaxations to avoid false positives. The application 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:
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.
As part of the streaming changes, the application 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. Presence of only the open bracket character (<), or only the close bracket character (>) is no longer considered as an attack. It is when an open bracket character (<) is followed by a close bracket character (>), the Cross-site scripting attack gets flagged. Both characters must be present in the right order (< followed by >) to trigger Cross-site scripting violation.
The application 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 application 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 application firewall currently has a default set of more than 125 denied patterns. Because hackers can use these patterns in Cross-site script attacks, the application 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 application firewall has the following XSS built-in lists:
Application 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:
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:
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:
In the configuration utility, 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 configuration utility
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 configure a HTML Cross-Site Scripting relaxation rule by using the configuration utility
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 configuration utility
You can use the configuration utility 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:
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 :
b. Select a row and click Manage Elements to display the corresponding XSS Elements (Tag, Attribute, Pattern) used by the application firewall Cross-Site Scripting check.
2. 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.
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.
When the learn action is enabled, the application 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 application firewall learning enhancement was introduced in release 11.0 of the NetScaler software. To deploy fine grained HTML Cross-Site Scripting relaxation, the application 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.
The application 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.
To view or use learned data by using the command line interface
At the command prompt, type one of the following commands:
To view or use learned data by using the configuration utility
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.
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 application 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:
> tail -f /var/log/ns.log | grep APPFW_XSS
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|NetScaler|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
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>
To access the log messages by using the configuration utility
The Citrix configuration utility includes a useful tool (Syslog Viewer) for analyzing the log messages. You have multiple options for accessing the Syslog Viewer:
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 configuration utility. 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 application 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 configuration utility
When the stats action is enabled, the counter for the HTML Cross-Site Scripting check is incremented when the application 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 <profile name>
To display HTML Cross-Site Scripting statistics by using the configuration utility
Note the following points about the HTML Cross-Site Scripting check:
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.