Dot Net Dragon: AntiXSS Module

In the earlier post we learnt about the AntiXSS Library. Which was very usefull for us to stop any Crosssite scripting attack XSS.
But we cannot mannually go in every field of the project and check it with Antixss Library.
Also it might happen that Some new developer comes in and forgets to encode the new fields he introduced with the Anti XSS Library. Microsoft has also come up with a solution where we can do it Globally.

Introduction

SRE protects applications from Cross-Site Scripting (XSS) attacks by leveraging the Anti-XSS library to encode data. It works by inspecting each control that is being reflected by ASP.NET and then automatically encodes data of vulnerable controls in their appropriate context. Data to be encoded for a specific control is mentioned in the antixssmodule.config file. This is useful for applications which are already deployed in production and when we don't want to rewrite code.

SRE Configuration for Web Applications

To download the SRE MSI file, use this link: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=325.
Install SRE and use these DLLs installed (while installation, setup will ask whether to install SRE or AntiXss module or both): AntiXSSLibrary.dll and AntiXssModule.dll.
The DLLs will be present in the path (default path): C:\Program Files\Microsoft Information Security\Microsoft Anti-Cross Site Scripting Library v3.1\Security Runtime Engine\Module.
Add reference to both DLLs to the web application project, i.e., RxOfficeLegal.
Add the below configuration element into the Web config file under the httpmodules section.

After adding the above patch, use ConfigGen.exe to generate the config file for the controls.
The most important point is, if ConfigGen.exe is not generating the configuration for the controls then use manual configuration for the controls that are are needed with the respective properties (e.g. for Label control, Text property should be configured). Generally the name of the configuration file is antixssmodule.config. (By default the standard antixssmodule.config is generated with the EncodingControls.xml file).
Rebuild the solution and see the result on the page rendered.
For GridView, and data source controls, we have to manually encode in the code. For GridView, it is mandatory to have the Rowdatabound event present in the .cs file, it is OK even if it is empty.

How SRE Works

SRE works using Reflection, it takes controls from the antimodule.config file and encodes the controls according to the encoding type. There are mainly the following types of encoding in AntiXssModule:

GetsafeHtmlMathod
HtmlAttributeEncode
HtmlEncode
JavaScriptEncode
UrlEncode
GetSafeHtmlFragment(String)

The above encoding types have overloaded methods. Three overloaded methods are listed below:
Example:

GetSafeHtmlFragment(String)
GetSafeHtml( TextReader sourceReader,Stream destinationStream)
GetSafeHtml( TextReader sourceReader,TextWriter destinationWriter)

Note: For manual encoding, we have to add the namespace refernce: "using Microsoft.Security.Application".

AntiXssModule Configuration File and Deployment

The AntiXssModule configuration file contains the following attributes. These attributes are useful to configure the application according to your requirement. The attributes and their description are given below.

<ControlEncodingContexts>

This section lists the controls and encoding contexts supported by SRE. Example:

<ControlEncodingContexts> 
<ControlEncodingContext FullClassName="System.Web.UI.WebControls.Label" PropertyName="Text" 
EncodingContext="Html" /> 
<ControlEncodingContext FullClassName="System.Web.UI.WebControls.HyperLink" PropertyName="Text" 
EncodingContext="Html" /> 
</ControlEncodingContexts>

PropertyName

The name of the property which needs to be encoded.

EncodingContext

The type of encoding which needs to be applied. Valid attribute values are Html, HtmlAttribute.

ControlEncodingContext

This node defines a control and its encoding context. Multiple nodes may exist for different controls; the same class name and property name must not exist twice. With each control, the full class name, property name, and encoding context must be defined. Other attributes are ignored.

<DoubleEncodingFilter Enabled="True" />

This section can be used to configure double encoding support.

<EncodeDerivedControls Enabled="True" />

This section can be used to configure encoding for derived controls.

<MarkAntiXssOutput Enabled="False" Color="Blue"/>

This section can be used to configure color coding of the output.

<Suppressions><Exclude Path="/Page_1.aspx" />

This section includes the configuration for suppressing SRE for the listed files and folders.

Deployment

Follow these steps to deploy the SRE:

Use the ConfigGen.exe utility to create an antixssmodule.config file. Alternatively, you copy the default antixssmodule.config from the Security Runtime Engine\Module folder to your web application's root folder.
Copy the DLLs from the Security Runtime Engine\Module folder to your web application's \bin folder.
Enable the SRE module by modifying your web.config file according to these examples. In IIS 6.0 and IIS 7.0 in Classic .NET Application Pool:

<system.web> 
<httpModules> 
<add name="AntiXssModule" type="Microsoft.Security.Application.SecurityRuntimeEngine.AntiXssModule"/>
</httpModules> 
</system.web>

<system.webServer> 
<modules> 
<add name="AntiXssModule" type="Microsoft.Security.Application.SecurityRuntimeEngine.AntiXssModule"/> 
</modules> 
</system.webServer>

MarkAntiXssOutput Enabled="True"

http://www.foosite.com/default.aspx?MarkAntiXSSOutput=true

Limitations

For GridView and other datasource controls, we have to manually add code for encoding.
SRE ConfigGen not picking up child controls inside DataGrid or DataList: SRE ConfigGen identifies controls that need to be encoded by reflecting controls in the web application binary. Due to the limitations of its implementation, ConfigGen cannot reflect what controls are present in an <ItemTemplate>. You can work around this by manually adding the control detail in antixssmodule.config, or by using the default configuration file from <Installation Folder>\SRE\Module.
SRE encodes data on the server side. That means any ASP.NET control which is configured in the AntiXssModule.config file and which has the runat="server" attribute set can be encoded by SRE.

SRE Success Screenshots

Some testing screenshots of SRE Module testing with Anti-Xss library:
If we use SRE module with the XSS library and set the Label control Text property with malicious content, then it will not execute the malicious content, it will encode the malicious content and prevent its execution.

Example 1

If the text of the Label is populated with a script tag which is not expected as a value of the label as below:

<asp:Label ID="lblUser" CssClass="LastLogin" runat="server" Text="<script>alert('Test')</script>"></asp:Label>

then it will encode the above label on the screen as shown:

<script>alert('Test')</script>

but if the SRE module with XSS library is not used, then it will execute malicious content, which might be harmful to the application. For example:

Example 2

If we try to inject malicious content using an input control in the UI as below:

<script>test</script>

If SRE is used, then it will redirect to an error page:

A potentially dangerous Request.Form value was detected from the client 
(ctl00$mainContentPlaceHolder$txtAddress2="<script>alert('Testi...").

If we don't use the SRE tool, it will show an alert message due to the malicious content executed. If we set the MarkAntiXssOutput tag in the SRE config file antixssmodule.config, then you can see which part (controls) in the page are encoded with a specific color. For example, set in config:

<MarkAntiXssOutput Enabled="true" Color="Yellow"/>

and pass MarkAntiXssOutput=true in request URL: http://testpage.aspx?MarkAntiXssOutput=true, then output will be colorful in yellow color.

Other findings

The SRE tool does not encode child controls, for which we have to manually change the code to encode. Like GridView, DataGrid, and other controls. For that we need to add a Rowbound event prototype in the code. For example:

protected void GridView_RowDataBound(object sender, GridViewRowEventArgs e) 
{ 
}

References

Security Runtime Engine download site: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=325
How to use the AntiXss library: http://msdn.microsoft.com/en-us/library/aa973813.aspx
Demo for the AntiXss library: http://channel9.msdn.com/Blogs/Jossie/Anti-XSS-Library-v31-Find-Fix-and-Verify-Errors
For databound controls and data control limitation: http://msdn.microsoft.com/en-us/library/ff648635.aspx
http://blogs.msdn.com/b/syedab/archive/2009/07/08/preventing-cross-site-scripting-attacks-using-microsoft-anti-xss-securityruntime-engine.aspx

Dot Net Dragon

Tuesday, June 12, 2012

AntiXSS Module