The XML Cross-Site Scripting check examines both the headers and the bodies of user requests for possible cross-site scripting attacks. 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.
Unfortunately, many companies have a large installed base of Javascript-enhanced web content that violates the same origin rule. If you enable the XML Cross-Site Scripting check on such a site, you have to generate the appropriate exceptions so that the check does not block legitimate activity. In addition, to prevent blocking of legitimate requests, this check ignores cookies that were set by the server, even if they contain elements that the Cookie Consistency check would otherwise block. You should keep that in mind when configuring this check.
If you use the wizard or the configuration utility, in the Modify Cookie Consistency Check dialog box, on the General tab you can enable or disable the Block, Log, and Statistics actions, and the following parameters:
w Transform. Make the following changes to requests that match the XML Cross-Site Scripting check:
• Left angle bracket (<) to HTML character entity equivalent (<) • Right angle bracket (>) to HTML character entity equivalent (>) These changes prevent browsers from interpreting unsafe html tags, such as <script>, and thereby executing 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.
w Check complete URLs. If checking of complete URLs is enabled, the application firewall examines entire URLs for XML Cross-Site Scripting attacks instead of checking just the query portions of URLs.
w Check Request headers. If Request header checking is enabled, the application firewall examines request headers for XML Cross-Site Scripting attacks, instead of examining just URLs.
If you use the command-line interface, you can enter the following commands to configure the XML Cross-Site Scripting Check:
w set appfw profile <profileName> -crossSiteScriptingAction [block] [learn] [log] [stats] [none]
w set appfw profile <profileName> -crossSiteScriptingTransformUnsafeHTML ([ON] | [OFF])
w set appfw profile <profileName> -crossSiteScriptingCheckCompleteURLs ([ON] | [OFF])
To specify relaxations for the XML Cross-Site Scripting check, you must use the
configuration utility. On the Checks tab of the Modify XML Cross-Site Scripting Check dialog box, click Add to open the Add XML Cross-Site Scripting Check Relaxation dialog box, or select an existing relaxation and click Open to open the Modify XML Cross- Site Scripting Check Relaxationdialog box. Either dialog box provides the same options for configuring a relaxation, as described in Manual Configuration By Using the
Configuration Utility on page 33.
Following are examples of XML Cross-Site Scripting check relaxations:
w Name element or attribute. The following expression exempts all elements beginning with the string name_ followed by a string of upper- and lower-case letters or numbers that is at least two characters long and no more than fifteen characters long:
w URL element or attribute. The following expression exempts URLs with hostnames of web.example.com, with a path up to four levels deep followed by an optional filename and extension, but no HTML or query symbols :
^https?://web[.]example[.]com(/[^<>?]{1,30}){0,4}(/[^<>?] {1,30})*$
w URL element or attribute (special characters). The following expression exempts URLs with hostnames of web.türkçe-example.com, with the same path and file restrictions as above:
^https?://web[.]t\xC3\xBCrk\xC3\xA7e-example[.]com(/[^<>?] {1,30}){0,4}(/[^<>?]{1,30})*$
Note: See PCRE Character Encoding Format on page 43 for a complete description of supported special characters and how to encode them properly.
Caution: 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 URL 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 XML Cross-Site Scripting check would otherwise have blocked.