Mitigating Cross-Site Scripting (XSS) Attacks

Web applications or Web services are vulnerable to cross-site scripting attacks. This topic covers the following:

• Introduction to Cross-Site Scripting

• How Input Validation Mitigates XSS Attacks

• How to Implement the Anti-XSS Component

Introduction to Cross-Site Scripting

Cross-site scripting (XSS) is a computer security vulnerability found in Web applications that insert input from the user into the dynamic pages sent back to the user’s browser without filtering special characters often used in software programming. In such cases, malicious code called scripts can be inserted into the dynamic page of a targeted site. The malicious script runs in the user’s browser as if the script came from the trusted Web site. As a result, the attacker gains access to the same information and privileges as the user on the targeted site.

For this attack to occur, the attacker targets a Web site and the people who visit it. The attacker initiates the attack by enticing a Web user to click on a hyperlink. The hyperlink contains a request for the targeted Web site and the malicious script. The targeted Web site sends the user’s browser a dynamic page in response to the request that includes the malicious script. The user’s browser reads the dynamic page and runs malicious script as if it came from the trusted site. The malicious script can read, alter, and send any sensitive information accessible to the user’s browser. The attacker gains access to private user information.

This type of attack exploits the trust a user has in a particular Web site. E-commerce sites are candidates for cross-site scripting attacks.

How Input Validation Mitigates Cross-Site Scripting (XSS) Attacks

Microsoft Commerce Server 2009 R2 introduces an anti-XSS component called the AntiXssRequestEncoder to mitigate the risk of cross-site scripting (XSS) attacks on rich Internet applications (RIAs) in the external zone.

The anti-XSS component must be configured in Commerce Foundation because user supplied inputs from the RIA in the external zone are not validated by the routing service. The anti-XSS component provides request encoding to ensure that inbound data to the commerce server is not corrupted with malicious scripts.

The anti-XSS component must be implemented for any operation sequence where user inputs are coming from an untrusted source and the user inputs are displayed back to the user. For example, use the anti-XSS component for Create and Update operations.

To avoid performance slowdowns, only use the anti-XSS component on those operation sequences that require input validation. If you are not exposing the WCF Routing Service in the external zone, you would not need to use the anti-XSS components in the internal zone as the Solution Storefront already performs validation against the user input it receives.

How to Implement the Anti-XSS Component to Mitigate XSS Attacks

The anti-XSS component called the AntiXssRequestEncoder uses the Microsoft Anti-Cross Site Scripting Library (AntiXssLibrary.dll) to encode input. The anti-XSS component can be used with any operation sequence. Since operation sequences can contain nested, related operations with numerous entities and properties, the anti-XSS component must be configured to specify exactly what parts of the request should be encoded. Typically, the anti-XSS component is used for Create and Update operations because changes are written to the database.

To implement the anti-XSS component:

1. Add the anti-XSS component to an operation sequence.

2. Configure the anti-XSS component to specify what operation, entities, and properties to encode and the type of encoding

You must complete these two steps for each operation sequence you want to encode. You can specify the configuration at either the operation sequence component level or globally in the ComponentConfigurations section of the ChannelConfiguration.config settings.

When you add the anti-XSS component to an operation sequence, consider where the anti-XSS component appears in the operation sequence hierarchy. The anti-XSS component must be high in the operation sequence hierarchy and must appear before any data processing occurs. For example, you may want the anti-XSS component to be the next operation after an Authorization operation.

You can customize the following anti-XSS component configuration properties:

Configuration Property	Type	Description	Value
operation	String	The CommerceOperation.OperationName of the operation that should be encoded	The operation name or '*' to indicate all operations.
entity	String	The CommerceEntity.ModelName of the entity (or entities) to be encoded in the above specified operation	The entity model name or '*' to indicate all models.
entityProperties	String	The CommerceEntity.Properties of the above mentioned entity to be encoded	The property name or names, or '*' to indicate all properties.
encoding	String	Type of encoding to be done on the operation, entity, and properties	HTML, HTMLAttribute, JavaScript, Url, or XmlAttribute. Choose the encoding to use based on how the encoded data is used on the page. For more information, see the Encoding Methods table.

Encoding Methods
Encoding Name	Encoding Method	Description	Conditions for Use
Html	HtmlEncode	Converts all input strings as text for display in a browser. Special characters, such as ampersand, opening and closing brackets, and double quotes, are converted to their text equivalents so the browser does not interpret these special characters as HTML code.	Input string is used in HTML output except HTML attributes
HtmlAttribute	HtmlAttributeEncode	Converts only quotation marks, ampersands, and left angle brackets to their text equivalents.	Input string is used as an HTML attribute
JavaScript	JavaScriptEncode	Converts input text containing special characters, such as backslash, double quote, apostrophe, Tab, Return, and Spaces, to text equivalents for use in JavaScript and HTML	Input string is used in a JavaScript environment
Url	UrlEncode	Converts input strings containing special characters for use in universal resource locators (URLs).	Input string is used in a Universal Resource Locator. For example, a value in a query string.
Xml	XmlEncode	Converts all input strings as text for display in a browser. Special characters, such as ampersands, angle brackets, double quotes, and single quotes, are converted to their text equivalents so the browser does not interpret these special characters as XML code.	Input string is used in XML output except XML attributes
XmlAttribute	XmlAttributeEncode	Converts input strings as text. Backslashes, ampersands, angle brackets are converted to their text equivalents.	Input string is used as an XML attribute

The following example shows how to apply the anti-XSS component to an operation in ChannelConfiguration.config settings. In the example, the anti-XSS component is added to the [CommerceCreateOperation] and [CommerceCreateRelatedItem] operations. The entity properties user ID and display name are encoded using HtmlEncode. All properties associated with the related profile address are also encoded using HtmlEncode.

<Component name="AntiXss" type="Microsoft.Commerce.SequenceComponents.Components.AntiXssRequestEncoder, Microsoft.Commerce.SequenceComponents, Version=9.0.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35">
  <Configuration customElementName="antiXssConfigurationUpdate"
customElementType="Microsoft.Commerce.SequenceComponents.Components.AntiXssElement, Microsoft.Commerce.SequenceComponents, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
    <antiXssConfigurationUpdate>
      <antiXssEncoding>
           <add operation="CommerceCreateOperation" 
                  entity="Profile" 
                  encoding="Html"
                  entityProperties="Id,DisplayName" 
                  />
           <add operation="CommerceCreateRelatedItem" 
                  entity="Address" 
                  encoding="Html"
                  entityProperties="*" 
                  />
      </antiXssEncoding>
    </antiXssConfigurationUpdate>
  </Configuration>
</Component>

See Also

Other Resources

Considerations for Secure Deployment of Rich Internet Applications (RIAs)

Considerations Prior to Supporting RIAs

Mitigating Cross-Site Request Forgery (CSRF) Attacks

Reducing the Attack Surface Area

Protecting User Anonymity