Filed: .NET Developer Tools, ASP.NET Security
The other day I mentioned the release of Microsoft Anti-Cross Site Scripting Library 3.1 to help stop Javascript Injection Attacks.
After reading through the documentation and taking a peek at the included sample application, the Security Runtime Engine looks pretty darn cool. In fact, the Security Runtime Engine is a pretty fast way to patch an old ASP.NET application that may have javascript injection security holes all over it. Patch an insecure ASP.NET web application quickly with the Security Runtime Engine while you fix the security issues in development.
Security Runtime Engine
The Security Runtime Engine is nothing more than an HttpModule that hooks into the Pre-Render event of the page and encodes all server controls of your choice on a page before rendering it to the client. In an ideal situation this would require no code changes by you. Simply add a reference to the HttpModule in your web.config as such:
<httpModules>
<add name="AntiXssModule" type="Microsoft.Security.Application.SecurityRuntimeEngine.AntiXssModule"/>
</httpModules>
The server controls and properties that you want encoded are specified in a separate configuration file ( antixssmodule.config ) that you include in your web application. The sample included encodes the following controls:
<ControlEncodingContexts>
<ControlEncodingContext FullClassName="System.Web.UI.Page" PropertyName="Title" EncodingContext="Html" />
<ControlEncodingContext FullClassName="System.Web.UI.WebControls.Label" PropertyName="Text" EncodingContext="Html" />
<ControlEncodingContext FullClassName="System.Web.UI.WebControls.CheckBox" PropertyName="Text" EncodingContext="Html" />
</ControlEncodingContexts>
Now here is the kicker. In the example there is a summary comment form that allows you to add a comment to a web page. For demonstration purposes, the comment is not properly encoded before displaying it on the web page. When you add a simple Javascript Injection Attack as simple as
<script>alert("Hello World")</script>
into the comment form, this script gets embedded into the page and keeps popping up an alert window everytime the page comes up.
Now do the same thing but with the Security Runtime Engine HttpModule activated in the web.config. Because the comment is displayed via a Label Control and the text property of the Label Control is Html Encoded based on the configuration, you will no longer have the popup window but rather the following in the comments:
Nice first step! The Security Runtime Engine has made the application safe from this.
AntiXss.GetSafeHtmlFragment
However, now we need to sanitize the input so that javascript does not get injected into the comments. Let's use the new GetSafeHtmlFragment in AntiXss v3.1. Jump into the sample code and modify it so that script code is stripped from the comments as such:
dr["Comments"] = AntiXss.GetSafeHtmlFragment(txtComments.Text);
You would certainly do this for the name and email input as well.
Now when we add a comment that mixes a little text with script code as such:
upon submission only the Safe Html Fragment is included on the page:
I like this. A good combination of the Security Runtime Engine and the methods on AntiXss can help you with those folks who try to inject javascript for Cross-Site Security Attacks.
Download the new library here.
David Hayden