The Connected Information Security Group : Anti-XSS

This Blog URL Has Changed – Please Update Your Readers

cisg — Thu, 16 Apr 2009 17:52:32 GMT

Things have been quite on the blog for while. There is a LOT of code being cranked out at the moment as we work towards some deadlines in the summer on various projects.

Our team name has also changed from the Connected Information Security Group (CISG) to the Microsoft IT Information Security Tools Team. This reflects an increased scope of tools that we are building and areas that we are focusing on so we have updated the blog URL. Well leave all the content as is on this blog but all new content will be posted at the new URL.

As well as news about significant work on CAT.NET and a Beta for TAM 3.0 we plan to start sharing details of the development framework CISF that we are building and a Risk Tracker application; both of which we plan to release open source under an MS-PL license this summer. CISF is a set of reusable components and code from which you can assemble your own security management applications (including gluing various security tools and technology together). It’s built in C# and on the MSFT technology stack (.NET 3.5 (WWF, WCF. ASP.NET etc)), SQL Server 2008 and Windows Server. You can think of Risk Tracker as a “Security Starter Kit” using the CISF; it’s essentially a Risk Tracking application that we have built internally for the corporate information security team which we will generalize and share with the community. You will be able to run it as is or extend it with .NET and the CISF. We plan to extend both tools on a regular basis (quarterly updates) as we improve the tools and technology for internal use.

More news in a few weeks!

You can subscribe to the new blog at http://blogs.msdn.com/securitytools

Cheers!

Mark

Getting Help for CAT.NET and Anti-XSS

cisg — Mon, 23 Feb 2009 17:42:23 GMT

We now have a discussion forum for users of CAT.NET. There is no official support for these tools but you can ask questions and we will try to help wherever we can!

CAT.NET -

http://social.msdn.microsoft.com/Forums/en-US/catnet/threads/

Anti-XSS -

http://www.codeplex.com/AntiXSS/Thread/List.aspx

AntiXSS Library V3.0 - Test Harness

cisg — Mon, 19 Jan 2009 13:55:15 GMT

Hi, Anil Chintala here…

In this post I wanted to talk about the new Test Harness application which was released as part of the AntiXSS V3.0 Beta and is available as a free download on MSDN with source code available for download on CodePlex. Test Harness application is created to help the users to quickly get started and validate the successful blocking of XSS issues by the Library and also to measure the enhanced performance claims of the AntiXSS V 3.0 against Microsoft .NET encoding library.

AntiXSS Test Harness is a windows console application that automates the following two categories of tests - XSS validation and performance tests. When executed, AntiXSS Test Harness displays this console menu:

Performance Test Bench uses HtmlEncode() method as a benchmark for measuring performance of the AntiXSS library - AntiXss.HtmlEncoding(…) method against the .NET - HttpUtility.HtmlEncode(…) encoding method. Input strings with a combination of safe and un-safe characters are used as payload to run the automated performance tests.

Choosing Option#1, Performance Test Bench executes performance tests that analyze such metrics as:

Input string lengths
Encoded output strings
and the total time taken for its execution.

During its run, Performance Test Bench compares the execution times of .NET's HttpUtility.HtmlEncode and AntiXss.HtmlEncode and stores in an output file containing results as displayed in this illustration:

XSS Validation Test Bench demonstrates the successful blocking of cross-site scripts. These tests use a list of XSS exploits as payload for running the automated tests. XSS exploit list are read from a text file, each payload is run through HTMLEncode() method of the library and the encoded output is stored in an output file.

When Option 2 is selected from the above console screen, Test Harness application executes the XSS validation tests and produces the following output file:

Test Harness Application provides a framework for automating the XSS validation and performance evaluation. Primary objective is to help developers and testers to quickly get started and test AntiXSS library for XSS validation and performance. With the availability of source code on CodePlex it also allows advanced users to extend the automated testing capabilities as per your specific requirements.

Thanks and more later…

Free MSDN Webcast: Managing Cross-Site Scripting Using CAT.NET and AntiXSS (Level 200)

cisg — Sun, 04 Jan 2009 12:36:46 GMT

Language(s):
English.

Product(s):
Security.

Audience(s):
Developer.

Duration:
60 Minutes

Start Date:

Friday, January 09, 2009 12:00 PM Pacific Time (US & Canada)

CAT.NET CTP Links Are Live Again!

cisg — Thu, 18 Dec 2008 03:37:50 GMT

Download CAT.NET CTP (32 bit here and 64 bit here)

Anti-XSS was not affected but for completeness

Download Anti-XSS 3.0 Beta (here and source code here)

Our sincere apologies.

How the Anti-XSS 3.0 SRE Works

cisg — Tue, 16 Dec 2008 14:41:26 GMT

RV again...

Last time around we looked at SRE from a conceptual perspective, this time lets look at from a code perspective. Lets trace the program flow and understand in depth what SRE code does.

SRE is a HttpModule, the main class file is AntiXssModule.cs which inherits from IHttpModule. In the Init() event of HttpModule we hook on to HttpApplication.PostMapRequestHandler() event which gets raised when an ASP.NET handler is processing the current user request. In this case we are trying to find out when the ASP.NET Page handler is processing the page. As System.Web.UI.Page is both a HttpHandler and Page class that an ASP.NET page represents, we can use it to hook on to the PreRender event. Additional checks are performed to determine whether the page is excluded or whether the class is marked with SupressAntiXssEncodingAttribute.

   1: public void Init(HttpApplication context)

   2: {

   3:     this.LoadConfig(context, AppDomain.CurrentDomain.BaseDirectory +

   4:                                             "antixssmodule.config");

   5:     if (objConfig != null)

   6:     {

   7:         objApp = context;

   8:         objApp.PostMapRequestHandler += new

   9:                             EventHandler(objApp_PostMapRequestHandler);

  10:     }

  11: }

LoadConfig uses the Configuration/ModuleConfiguration.cs class to load and parse the XML to create an object of ModuleConfiguration class and stores it in Application state variable for which can be reused through out the lifetime of the application. There is a drawback with using this approach whenever you make a change to antixssmodule.config file, the application needs to be restarted for those changes to be applied.

   1: void objApp_PostMapRequestHandler(object sender, EventArgs e)

   2: {

   3:     //...validations & exclusion checks

   4:     if (objConfig != null)

   5:     {

   6:         string strVirPath = objApp.Context.Request.FilePath;

   7:         if (objConfig.IsPageExcluded(strVirPath.ToLower()))

   8:         {

   9:             return;

  10:         }

  11:     }

12:

  13:     //attribute checks

  14:     object[] attributes = ((Page)pageHandler).GetType().GetCustomAttributes
                                     (typeof(SupressAntiXssEncodingAttribute), true);

  15:     if (attributes.Length > 0)

  16:         return;

  17:     Page page = (Page)pageHandler;

18:

  19:     //Calling the static class to do the rest of the job

  20:     XssProtection.Protect(page, objConfig);

21:

  22: }

In the PostMapRequestHandler after the checks we call the XssProtection.Protect method which hooks on to the Page.PreRender event. This way we wait till page gets processed, all properties and controls are built by ASP.NET. During prerender we iterate through the control collection of the page and find controls which need to be encoded. Specified properties in the configuration file are then encoded based on the encoding type using the AntiXss library. As the properties are dynamically defined in the XML configuration file, property values are set using reflection. In essence XssProtection class is the main class responsible for encoding the page controls properties.

The following is a screenshot of Visio sequence diagram of the above things.

For more information and insight into code please check http://www.codeplex.com/antixss.

Thanks
RV

A Sneak Peak at the Security Runtime Engine

cisg — Fri, 24 Oct 2008 11:14:54 GMT

RV here again...

Traditionally security fixes are applied to specific pieces of code where a vulnerability exists which usually involves some development and testing effort. Imagine a system where an application is instantly secured by simple configuration. I am specifically talking about ASP.NET applications where Cross site scripting and SQL injection are some of the most common vulnerabilities found. This is exactly what the Security Runtime Engine (SRE) does, allows you to instantly turn on and protect applications which are already developed and deployed. This is very important for legacy applications which are already developed and usually don't have resources for any new development.

We have been working on a runtime engine specially for ASP.NET applications which could provide blanket protection to some of the common web application vulnerabilities. When I say blanket protection I mean single point of deployment and protection for the entire application. Thus we designed the SRE as an HTTP module which works at the IIS/ASP.NET layer providing protection against certain attacks. This is different from a web application firewall, it hooks the CLR and so doesn't operate on network protocol stream as it passes the network. As such it's tightly coupled to the application; an important and significant difference. Currently it provides protection against Cross Site Scripting by automatically encoding the controls.

It does this by walking the controls in the requested page and automatically encoding data in specific properties for example Label.Text. It can be customized to walk and encode (override) only specific controls such as Label, HyperLink, CheckBox etc. and additionally the type of encoding used can also specified for each individual property of a control. This customization enabled using a configuration file in the web root. SRE leverages the upcoming Anti-XSS library to ensure ultimate XSS protection.

Apart from simple encoding, SRE also contains some advanced features for better usability and adoption. Notably the following 3 features standout;

Double Encoding Protection
Encode Derived Controls
Suppressions

The double encoding protection feature ensures that there is no double encoding possibility. Double encoding problem occurs if you encode data twice. SRE would make sure that it's encoding does not double encode the data. The encoding derived controls feature allows the derived controls to be automatically encoded if the base controls are already configured, for example if you create your own label control using the System.Web.UI.WebControls.Label then you control will automatically be secured without any additional configuration. The suppressions feature allows you to suppress encoding for specific pages or controls. If you want to encode programmatically or your page does not use any input, you could suppress encoding in that page. Ultimate flexibility! This can be done by adding the specific page path to the configuration file. Note that SRE encoding performance is similar to Anti-XSS library. We have had the ACE Performance testing team do an analysis and it runs at near native speed. We will be shipping both tools wit a performance test and a test harness. So enabling SRE is similar to implementing AntiXSS library but with added bonus of not having to implement any code changes and yet get protection across the entire application. You can think of it as the ability to have secure encoding out of the box. Of course this will break many existing applications which is one reason why the .NET framework couldn't implement this by default.

SRE also includes a configuration utility which reflects on the compiled ASP.NET application binary and creates a custom configuration file based on the controls in the binary. The configuration utility includes a master file which contains the list of all the controls, their properties and encoding type needed. This custom configuration file is very useful in making sure the proper configuration is applied to the web application.

In future SRE could be able to provide protection against certain other classes of web application attacks (in fact we already have work happening on that). SRE is code complete and in the final stages of testing. We will have an internal beta soon and a public one within the next few months.

Check our blog for the beta announcement!

Thanks

Anil RV

ASP.NET Data Binding and AntiXss Encoding

cisg — Wed, 01 Oct 2008 12:50:42 GMT

Hi RV here again...

Last time I looked at ASP.NET controls and few common scenarios where you need to use encoding. Couple of weeks back we looked at a sample data binding scenario. This time lets exclusively look at various ASP.NET data binding techniques and how to use AntiXss to encode the output.

Scenario #1: Eval()

Most common way of data binding in ASP.NET is by using Eval() method. Here is an ASP.NET label control bound to the "Comments" field of the data source.

   1: <!--Usage #1-->

   2: <asp:Label runat="server" ID="CommentsLabel" Text='<%# Eval("Comments") %>' />

   3: <!--Usage #2-->

   4: <asp:Label runat="server" ID="CommentsLabel"

   5:                 Text='<%#DataBinder.Eval(Container.DataItem,"Comments") %>'/>

By definition Eval() method uses reflection to bind the column at runtime this may affect performance of the application. Apart from the performance, as Eval() uses reflection it is generally inadvisable. Instead you should use Container.DataItem directly for binding and wrap it with AntiXss.HtmlEncode method to protect from XSS as shown below.

   1: <asp:Label runat="server" ID="CommentsLabel"

   2: Text='<%#Microsoft.Security.Application.AntiXss.HtmlEncode

   3: (((System.Data.DataRowView)Container.DataItem)["Comments"].ToString()) %>'/>

By using Container.DataItem directly we improve performance and can use AntiXss with it. Note that you can still use AntiXss.HtmlEncode on just the Eval() method.

Scenario #2: Bind()

Bind() is another way of data binding in ASP.NET. Here is the same ASP.NET label control bound to the "Comments" field using Bind().

   1: <asp:Label runat="server" ID="CommentsLabel" Text='<%#Bind("Comments") %>'/>

Bind() is a very special way of data binding in ASP.NET. Unlike Eval() Bind() is not a method call so when ASP.NET compiler encounters Bind() statements, it will generate additional code for data binding. If you look at the code created in the ASP.NET Temporary Files Folder, it in fact has DataBinder.Eval statement. Unfortunately due to this there are limitations on what you can do with a Bind() statement. One limitation is that you cannot wrap Bind() statements with any other method calls.

   1: //Code generated in the temporary file for the Bind() statement

   2: dataBindingExpressionBuilderTarget.Text =

   3: System.Convert.ToString(this.Eval("Comments"),

   4:     System.Globalization.CultureInfo.CurrentCulture);

For more information on this behavior check this blog post. In essence if you use Bind() statements, you should convert the code to use Eval() statements and wrap them with AntiXss library as shown in scenario #1 above.

Scenario #3: <%# %>

In some cases you might want to just bind some data to a control or a html element. This can be achieved by using <%# variable %> and Page.DataBind(). Here is some sample code.

   1: //variable declaration in the code behind file

   2: public string hyperLink="http://www.microsoft.com";

   3: Page.DataBind();

4:

   5: <!--In the ASP.NET page-->

   6: <a href="<%# this.hyperLink %>">Microsoft Corporation</a>

Although this is somewhat a strange way to do this, it sure illustrates the point of data binding. In this case, by simply wrapping the this.hyperLink in AntiXss.HtmlEncode would fix the problem.

   1: <%# Microsoft.Security.Application.AntiXss.HtmlEncode(this.strLocation) %>

As we have seen in the above scenarios Bind() is the only case where you will not be able to protect from XSS using encoding, so the best option is to change the ASP.NET code to use Eval() statement.

Which ASP.NET Controls Need HTML Encoding?

cisg — Wed, 17 Sep 2008 11:42:46 GMT

RV here...

Last time we saw some some real world XSS examples. This time we will look at which common ASP.NET controls require encoding. Some controls in ASP.NET automatically encode certain properties when rendered, not all the controls do the same. We looked at ASP.NET controls during AntiXss development and here are some common controls which need HTML encoding.

Control Name	Property Name	Encoding Type
System.Web.UI.Page	Title	HTML
System.Web.UI.WebControls.CheckBox	Text	HTML
System.Web.UI.WebControls.CompareValidator	Text	HTML
System.Web.UI.WebControls.CustomValidator	Text	HTML
System.Web.UI.WebControls.DropDownList	Text	HTML
System.Web.UI.WebControls.HyperLink	Text	HTML
System.Web.UI.WebControls.Label	Text	HTML
System.Web.UI.WebControls.LinkButton	Text	HTML
System.Web.UI.WebControls.ListBox	Text	HTML
System.Web.UI.WebControls.ListControl	Text	HTML
System.Web.UI.WebControls.Literal	Text	HTML
System.Web.UI.WebControls.RadioButton	Text	HTML
System.Web.UI.WebControls.RadioButtonList	Text	HTML
System.Web.UI.WebControls.RangeValidator	Text	HTML
System.Web.UI.WebControls.RegularExpressionValidator	Text	HTML
System.Web.UI.WebControls.RequiredFieldValidator	Text	HTML

Any time use pass data to these properties it should be encoded with AntiXss.HtmlEncode method. Note that the above table has Encoding type listed as HTML, not all properties need html encoding. For example, HyperLink.Text would need HTML encoding whereas HyperLink.NavigateUrl would need URL encoding. AntiXss is available as free download on MSDN. There are many other controls which need encoding. Sacha in his blog post attaches the list of all controls which need encoding. Check out the blog post attachments.

Real World XSS Vulnerabilities in ASP.NET Code

cisg — Wed, 10 Sep 2008 09:00:55 GMT

RV here again...

From couple of weeks we have been seeing some XSS vulnerabilities in asp.net code. Today I wanted to show you guys some real world examples ranging from property assignments, data binding and JavaScript building. For each example, I will offer both the vulnerability and mitigation which is very useful in self reviews. Before I say anything further, I want to caution you by saying that the following code examples must never be used in any application.

Example #1

In this case, we are simply using the user input directly in a label. The following is the vulnerable code.

   1: string strUsername =  txtUsername.Text;

   2: string strPassword =  txtPassword.Text;

   3: if (AuthenticationClass.Authenticate(strUsername, strPassword))

   4: {

   5:     //Set auth cookie and redirect, always use FormsAuthentication.SetAuthCookie

   6: }

   7: else

   8:     lblMessage.Text = string.Format("{0} is not found, click here to register!",

   9:                      strUsername);

Line 8, the username is directly being used to output the message. The following code fixes the vulnerability.

   1: lblMessage.Text = string.Format("{0} is not found, click here to register!",

   2:                   AntiXss.HtmlEncode(strUsername))

Example #2

In this case, we are data binding data from a database.

   1: //Probably the most common code that is vulnerable to XSS

   2: //This is persistent XSS vuln, a very dangerous as one

   3: //user attacks and many users will get exploited.

4:

   5: <asp:Repeater ID="repFeedback" runat="server" >

   6: <ItemTemplate>

   7: <p><asp:Label runat="server" ID="CommentsLabel" Text='<%# Eval("Comments") %>'/>

   8: <br /> - <i><asp:Label runat="server" ID="NameLabel" Text='<%# Eval("Name") %>'/>

   9: (<asp:Label runat="server" ID="EmailLabel" Text='<%# Eval("Email") %>'/>)</i></p>

  10: </ItemTemplate>

  11: </asp:Repeater>

Line 7-9 are vulnerable to XSS. Fortunately there is a very simple way to fix, which is shown below.

   1: <asp:Repeater ID="repFeedback" runat="server" >

   2: <ItemTemplate>

   3: <p><asp:Label runat="server" ID="CommentsLabel"

   4: Text='<%# AntiXss.HtmlEncode(DataBinder.Eval(Container.DataItem, Eval("Comments"))) %>'/>

   5: <br /> - <i><asp:Label runat="server" ID="NameLabel"

   6: Text='<%# AntiXss.HtmlEncode(DataBinder.Eval(Container.DataItem, Eval("Name"))) %>'/>

   7: (<asp:Label runat="server" ID="EmailLabel"

   8: Text='<%# AntiXss.HtmlEncode(DataBinder.Eval(Container.DataItem, Eval("Email"))) %>'/>)

   9: </i></p>

  10: </ItemTemplate>

  11: </asp:Repeater>

Also, please note that DataBinder.Eval and Eval are slow as they use reflection to parse the expression. A better option is to use the Container.DataItem directly as it is a DataRowView object.

   1: <%#Microsoft.Security.Application.AntiXss.HtmlEncode

   2: ((((System.Data.DataRowView)Container.DataItem)["Comments"]).ToString()) %>

Example #3

In this case, we are using a ASP.NET value in the JavaScript.

   1: <script language="javascript">

   2: function showMessage()

   3: {

   4:     var message='<%=this.strMessage%>';

   5:     var div = document.getElementById('messageLabel');

   6:     div.innerHTML=message;

   7: }

   8: </script>

Line 4 has the vulnerability. Anytime you use .NET variables or data directly into java script, that is a perfect recipe for a disaster. In fact, this vulnerability is so dangerous that neither ASP.NET Request Validation nor Server.HtmlEncode cannot protect you. Only AntiXss has native java script encoding.

   1: var message=<%=AntiXss.JavaScriptEncode(this.strMessage)%>;

Please note that AntiXss.JavaScriptEncode automatically surrounds the input with single quotes to make it a valid string.

We have seen three most common examples but there are many other vulnerable ways. The following is the small list of properties which could return untrusted input. By no means these values should be trusted, they should be validated and encoded during output.

Class name and property

Request.Params

Request.QueryString

Request.Form

Request.Headers

Request.ServerVariables

Request.Cookies

TextBox.Text

HiddenField.Value

Please note that there are other ways in which you can get user input and could result in a XSS attack. The best strategy is to identify user inputs and encode them before sending back to the browser.

How To: Detect Cross Site Scripting Vulnerabilities using XSSDetect

cisg — Tue, 02 Sep 2008 00:50:07 GMT

RV again...

Last time we saw how to fix a cross site scripting (XSS) vulnerability. This time we look at how we can detect cross site scripting vulnerabilities using automated tools. Being the most common vulnerability found in web applications, it is very important to detect and mitigate XSS vulnerabilities early in development cycle. Arming developers with the right tools to develop application security is a big problem in every enterprise. Here at Microsoft, we have developed a static analysis tool specifically aimed at developers to detect cross site scripting. It was released a while ago as Microsoft XSSDetect.

XSSDetect is stripped down version of the Code Analysis Tool for .NET used by the ACE team to help find security vulnerabilities in software applications. It has been made available for free on Microsoft downloads. XSSDetect comes as a Visual Studio Add-in that can identify non-persistent XSS vulnerabilities in ASP.NET web-applications. XSSDetect is a type of static analysis tool, which uses Microsoft CCI libraries for analysis. CCI libraries are the same libraries used by FxCop. XSSDetect is a bit more than a FxCop plugin, as XSSDetect uses interprocedural analysis to detect XSS vulnerabilities. It uses the notion of Sources (input entry point) and Sinks (output method) to detect data paths which could lead to a XSS vulnerability.

The following are some examples of Sources and Sinks.

Sources	Sinks
System.Web.HttpRequest.get_QueryString	System.Web.HttpResponse.Write
System.Web.HttpRequest.get_Form	System.IO.TextWriter.Write
System.Web.HttpRequest.get_Params	System.Web.UI.WebControls.Label.set_Text
System.Web.HttpRequest.get_Cookies	System.Web.UI.WebControls.HyperLink.set_Text
System.Web.UI.WebControls.TextBox.Text	System.Web.UI.WebControls.LinkButton.set_Text

XSSDetect builds a huge data graph of the binary and identifies the data paths containing these sources and sinks. If any of these data paths use a encoding library such as AntiXss library it will be excluded from the results. You can find more information on the Sources, Sinks and Encoding rules in the %PROGRAMFILES%\Microsoft\XSSDetect\Config. Lets look at some vulnerable code that will be detected by XSSDetect.

   1: //Code in .aspx page

   2: <%=Request.QueryString["message"];%>

3:

   4: //Writing hidden field value back on to the page

   5: Response.Write(hidHiddenInput.Value);

6:

   7: //Setting the link button text

   8: LinkButton1.Text = String.Format(txtInput.Text, "LinkButton1.Text");

9:

  10: //HTML table object

  11: Table1.Caption = String.Format(txtInput.Text, "Table1.Caption");

  12: Table1.Rows[0].Cells[0].Text =

  13:     String.Format(txtInput.Text, "Table1.Rows[0].Cells[0].Text");

14:

  15: //Literal object text

  16: Literal1.Text = String.Format(txtInput.Text, "Literal.Text");

17:

  18: //Checkbox and Label text assignments

  19: CheckBox1.Text = String.Format(txtInput.Text, "CheckBox1.Text");

  20: Label1.Text = String.Format(txtInput.Text, "Label1.Text")

21:

  22: //Indirect XSS

  23: string strInput;

  24: protected void Page_Load(object sender, EventArgs e)

  25: {

  26:     strInput = Request.QueryString["message"];

  27:     this.SetMessage(strInput);

  28: }

29:

  30: private void SetMessage(string input)

  31: {

  32:     Label1.Text = input;

  33: }

XSSDetect can detect many more variants of XSS vulnerabilities possible in ASP.NET Code. XSSDetect is currently available for Visual Studio 2005, we are working on a release to make it compatible with Visual Studio 2008. After installation go to Tools -> XSS Detect. It should open up a window as shown below.

Click the green "Play"/"Run" button (first button in the toolbar) to start the analysis. Please make sure that the solution is loaded and has all the needed references because XSSDetect will compile the source code to analyze the binary. Click on the Help Icon to open up the help file to find more information on the other features of XSSDetect. You can download XSS detect from MSDN downloads at http://www.microsoft.com/Downloads/details.aspx?FamilyID=19a9e348-bdb9-45b3-a1b7-44ccdcb7cfbe&displaylang=en. You can also see a FAQ for the tool at http://blogs.msdn.com/ace_team/archive/2007/12/11/xssdetect-faq.aspx.

Keep checking our blog for more exciting posts on Cross Site Scripting vulnerabilities and mitigation's.

Introduction to Dennis Groves

cisg — Fri, 29 Aug 2008 22:00:11 GMT

Dennis Groves here.....

Hello, my name is Dennis Groves and I am a Program Manager in the CISG (Connected Information Security Group) at Microsoft.

Before joining Microsoft I was a Security Consultant with IBM Security and Privacy Services. At IBM my roles was an IT Security Architect and Consultant in assessing and developing secure solutions addressing the security and privacy concerns of clients, both internal and external to IBM. I further specialized in Service Oriented Architectures (SOA); Identity Management and integrating security into infrastructure and application design. While there I contributed to an IBM Redbook on Security and Service Oriented Architectures.

I discovered web application security back in 1999 when I was hired by a company known as Perfecto Technologies, at the time we were working on the worlds first web application firewall; AppShield (obviously we couldn't sell them...) where I had the fortunate opportunity to go overseas for the first time and live in Israel, (I have also lived in Mexico, Thailand, the USA and I currently reside in England) and work on their second product "Appscan" that was eventually sold to IBM for a small fortune. After leaving Perfecto/Sanctum; I started OWASP with Mark Curphey. One of my early contributions to OWASP include the "OWASP Guide" downloaded over 2 million times; now a reference document in the PCI DSS standard, and the de-facto standard for securing web applications.

I have played a number of roles oven the years including:

Ethical Hacker
Web Application Security Consultant
IT Security Consultant
System Administrator
Network Administrator
Software Engineer

I was destined to be a Security professional, ever since I was young boy my father was constantly telling me if I would spend half my time doing what I was supposed to instead of gaming the system I could go twice as far.

Bibliophile

I am an autodidact with a ravenous appetite for knowledge and books. My love of books is matched only by my love of exercise; but I will save that for another post. I just completed reading "Little Brother" last night, it is a modern retelling of George Orwell's "1984" set in San Francisco, and although its target demographic is adolescence; and thus an easy read; it is a rare book about our occupation and the main character is definitely a security thinker. Some of the other books I have recently read are Brain Rules, Living the 80/20 way, & Do It Tomorrow. I am planning on completing Keeping Found Things Found next and then reading Making things happen, mastering project management. I am also keen to read Motion Mountain.

However, every once in a while a book comes a long that really stays with you. For me it is the The Medici Effect. The Medici Effect describes exactly how to reproduce the creativity that leads to world-changing insights. Not surprisingly one of the important mechanisms is diversity, we have long known that diversity strengthens species through evolution; this is after the cornerstone of Darwin's Theory. And in fact Dan Geer wrote a great article looking at what evolution tells us about managing risk. Diversity is what allows you to take fresh perspective to difficult problems and solve them in unexpected was. This is but one of the eight keys to locating the intersection where creativity happens.

Another book I read recently about Marketing is "The Pirate's Dilemma". This is a fantastic book about what happens when you don't give customers what they want and how to spot market opportunities that your customers are dying for. A marketing opportunity exists when customers start creating solutions for themselves.

Anti-XSS

"Secure web servers are the equivalent of heavy armored cars. The problem is, they are being used to transfer rolls of coins and checks written in crayon by people on park benches to merchants doing business in cardboard boxes from beneath highway bridges. Further, the roads are subject to random detours, anyone with a screwdriver can control the traffic lights, and there are no police." -- Gene Spafford

Back in 2002 I spoke at BlackHat about Cross Site Scripting (XSS). So interestingly enough, you could say my career is coming full circle. Here at Microsoft my role is program manager for the Anti-XSS library. This is a server side library that filters http data according to a whitelist sanitizing the output; so that cross site scripting attacks are not possible. This library was written around the time of Samy. Samy was a wake up call; like the Morris Worm of the two decades prior. Two years later in 1988 the first packet filters were arrived and the 'firewall' industry was born. Interestingly enough I used to write packet filters back then for companies around the Puget Sound. Interestingly the litmus test of security as set forth by Stephen Northcutt; is the recognition of the Morris worm; not a single firewall product; nor network device and even most Humans would be able to recognize or mitigate the risks of this attack today! Indeed, the mechanisms were different, but Samy demonstrated that little has changed in terms of security; in fact Samy marched right on through the firewalls unnoticed as predicted by Northcutt. Ken Thompson; wrote papers about IT security in 1984 - “Reflections on Trusting Trust“; in it he identified the problem of "Data Validation" the cause of both of the above worms and most Dancing Pigs.

Anti-XSS remains the leading solution to solving cross-site scripting in .NET applications. I am excited because I am working alongside some of the most amazing people I have ever had the fortune to work with, and we are working on a very difficult historical problem that has been lingering around for at least 24 years, and I have been chartered with updating the library - and let me tell you we have some very exciting stuff up our sleeves - so watch this blog.

With some hard work; cross site scripting will become a footnote in the history books, instead of a continuation of a theme.

UTF-8 Encoding

cisg — Thu, 28 Aug 2008 15:53:59 GMT

Hello there!

My name is Andreas Fuchsberger, I am a developer in the CISG team based in Germany. I joined CISG after a short stint with Assessment, Consulting and Engineering (ACE) Team part of the InfoSec in Microsoft IT. I am a relatively new to Microsoft having joined only 6 months ago coming from academia where I was full-time academic in the internationally renowned Information Security Group at Royal Holloway, University of London. In fact I still teach there on the excellent Masters (MSc) degree programme in Information Security, I teach the optional modules on Software Security.

The Software Security module was developed in response to the industry need to develop more secure software and is strongly based Michael Howard‘s must-read book Writing Secure Code 2^nd Edition and its update Writing Secure Code for Windows Vista®. It received part-funding from the Microsoft Research and the syllabus was constructed in consultation with Fabien Peticolas who headed the then university relations programme and Dieter Gollmann, who was also Microsoft Research at the time. Since designing and teaching the course I have become quite passionate about secure coding and the need to educate all kinds of software developers to learn to code securely from early on their careers. I am a true believer that security is not just a bolt-on that can be added at the end of a project. Expect to see more this one of my favorite topics in the future.

Speaking of secure coding, I note from a recent entry from Michael’s blog that Apache Tomcat has a UTF-8 encoding security bug and its related to the implementation of a standard (RFC 3629). Security standards are another of my favourite topics as I actively participate in a number of SC27 working groups (home of the ISO 27000 series) covering IT Security Technique for the International Organisation for Standardisation (ISO) and the International Electrotechnical Commission (IEC). I will be posting updates to the happenings of the working groups in the future.

Just in case you are interested, the Tomcat vulnerability comes about from using an invalid but possible UTF-8 encoding of ‘.’ character, this bug is often called “overlong UTF-8 escape". BTW the definitive place for UTF-8 encoding is Section 2.5 “Encoding Forms” and Section 3.9 “ Unicode Encoding Forms ” in the Unicode Standard, a great read if you interested in typesetting, character sets, encoding an similar. This particular problem comes about through the desire create a solution that provides some form of compatibility for legacy systems, a source of many security problems. It also goes to show that using blacklists is not the safest way to check for invalid input. Hackers always seem to be able to find new ways around blacklists that the original designers could not envisage. This is one the many things we are currently contemplating in the design of our new Anti-XSS library. Watch this space for an announcement.

What Does ANTI-XSS Offer for HTML Sanitization?

cisg — Wed, 27 Aug 2008 22:41:00 GMT

Hi Vineet here.....

My name is Vineet Batta and in keeping with the other introductions here are a few words about myself. I have an engineering degree in Electronics & Communication and have spent quite a lot of time doing security reviews in the application space. Before joining Microsoft as an FTE I worked as a consultant to different teams including TWC and MSN operations. As an FTE I have worked extensively on the Threat Modeling and Analysis Enterprise tool since 2007. I have always enjoyed breaking applications to expose security vulnerabilities and then designing creative solutions to fix them.

My favourite phrase of the moment is;

"Social engineering bypasses all technologies, including firewalls"

To support rich user experiences, increasingly web applications are required to input data in a rich text format. That means the ability to apply formatting basics like bold, color, embedding hyperlinked URL's etc. This can however lead to potential XSS exploits from vulnerabilities, if a malicious payload is embedded in this rich text.

Content filtering is one of the most important steps we can take to protect our customers and this filtering must apply to all user content which will be displayed in the software client. Items stored in a user’s data store can sometimes inadvertently contain nasty attack vectors, referred to as Persistent Cross Site Scripting. It is the client’s responsibility to protect the user and the users system from these attacks.

The Anti-XSS library also sanitizes tainted/unsafe HTML and emits "safe HTML". In its processing it makes formatting changes that means if the HTML document is not well formed (unbalanced tags or missing tags), it will correct it. To output safe HTM a white list based approach is used. The Anti-XSS library addresses these issues by exposing SafeHtml and SafeHtmlFragment methods.

~~Example 1: Usage of SafeHtml method.~~

~~If the input HTML stream is~~

   1: <html>   2: <head>   3:     <title>CISG test page</title>   4: </head>   5: <body>   6:     <table>   7:         <tr>   8:             <td>   9:                 XSS TEST <a> My mail box <script>   1:  type='text/javascript' > alert("BAD CODE");" </script> </a>  10:                 <!-- There is a script injection as above. -->  11:                 <!-- The closing <td> element is missing. -->  12:         </tr>  13:     </table>  14: </body>  15: </html>

~~Note the following:~~
1. The html has closing<td> element missing.
2. The already injected script is part of the input stream
<script type="text/javascript" > alert("BAD CODE"); </script>

Call one of the GetSafeHtml() methods from overloaded list as below:

AntiXss.GetSafeHtml(stringReader, stringWriter);
//stringWriter will hold the output.

~~The output will be well formed HTML and that is (X)HTML compliant~~

   1: <html>   2: <head>   3:     <title>CISG test page</title>   4: </head>   5: <body>   6:     <table>   7:         <tr>   8:             <td>   9:                 XSS TEST <a> My mail box </a>  10: <!-- There was script that is purged from the output. -->  11: <!-- The closing <td> element is NOT missing. -->  12:             </td>  13:         </tr>  14:     </table>  15: </body>  16: </html>

That's it , so easy to use and useful . :-). Note that even if <html><body> were to be missing from input stream, call to this method would have added these to form a well form HTML document.

~~Example 2: Usage of SafeHtmlFragment method.~~

As the name suggest SafeHtmlFragment is used if you must output only a fragment of the HTML body content and not the entire HTML document.The method will not output any <html><body> elements if they are missing.

~~Consider the unsafe input as below:~~

<a href="http://www.contoso.com"> You won the lottery <script language="javascript" > var a = document.cookie;
</script> </a>

~~Call one of the GetSafeHtmlFragment methods from overloaded list as below:~~

AntiXss.GetSafeHtmlFragment(stringReader, stringWriter);
//stringWriter will hold the output.

~~The output will be:~~

~~<div> <a href="http://www.contoso.com"> You won the lottery </a> </div>~~

~~As you can see the output is rendered harmless and valid.~~

It is worth nothing that this approach is different from HTMLEncoding. In encoding all unsafe characters are encoded to be rendered as harmless characters in the users browser. Using SafeHtmlFragment you actually purge the dangerous/unsafe script and replace it with white spaces.

More from me next week when we start to explore the next generation of Anti- XSS technology we are working on.

What is the Microsoft Anti-XSS Library?

cisg — Tue, 26 Aug 2008 11:05:53 GMT

RV here.....

My full name is Anil Kumar Venkata Revuru but people call me RV around here. I am a Senior Software Development Engineer (SDE in MSFT speak) for CISG where I am responsible for architecting security tools. In my past life at Microsoft I conducted security design reviews, threat modeling, application and source-code assessments. I hold a Diploma in Mechanical Engineering from JNTU Hyderabad and I made significant contribution to the security development of products at V-Empower Inc. I am also the author of Microsoft Threat Analysis and Modeling Tool used for application threat modeling. You can find my personal blog at http://blogs.msdn.com/codejunkie.

For my first post I thought I would provide an overview of the Anti-XSS library as it stands today. As Mark mentioned in the first post we have a team working on the next generation of this technology and well be blogging about that in the coming weeks. The Microsoft Anti Cross Site Scripting Library (AntiXSS) is an encoding library, designed and developed by CISG team at Microsoft in conjunction with the ACE Team. It is designed to help developers protect their Web-based applications from XSS attacks. This library is very different from most encoding libraries, it uses the principle-of-inclusions technique to provide protection against XSS attacks. This approach works by defining a valid or allowable set of characters, and encoding anything outside this set (invalid characters or potential attacks). It offers several advantages over other encoding schemes.

AntiXSS library encoding scheme uses the following white list for passing the safe characters and will encode all other characters.

a-z, A-Z, 0-9
space, period, comma, hyphen and underscore

Before we look at how AntiXSS works, lets look at a potential cross site scripting defect and understand how it works. Cross site scripting (XSS) is the most common web application vulnerability and is listed in the Top 10 web application vulnerabilities on OWASP. XSS can also be called HTML injection attack, it occurs when un-validated user input is inserted into HTML output. This allows the attacker to construct a URL with HTML input and get it executed on the browser in the user's context. This attack can be used to extract cookie information, steal sessions, write new html tags, invoke ActiveX controls, etc. Essentially, anything that can be done with a browser can be done with this attack without the user's knowledge.

Many of ASP.NET controls don't encode the input natively, which makes it more important for the developer to encode or validate the input. The following are some examples of this vulnerability.

   1: //This is the classic XSS vulnerability.

   2: Response.Write(Request.Params["input"]);

3:

   4: //Here is another vulnerability using ASP.NET controls

   5: Label1.Text = Request.QueryString["message"];

In the above examples, the input is being direct passed back to output stream. If any HTML such as <script>alert('Hello')</script> will be executed the browser and you will see a message box. Most probably this exploit may be stopped by request validation feature of .NET. There are other exploits which will bypass request validation feature, this feature should be used for defense in depth.

Proper output encoding and good input validation will fix the XSS issue. For output encoding use AntiXSS Library for its comprehensive encoding capabilities. AntiXSS works by looking at all the characters in the input and encoding characters not in the whitelist using standard html entity notation (&#num;). The above script would get encoded as <script>alert('hello');</script>. The following code is the correct implementation of AntiXSS for the above vulnerabilities.

   1: //This is the classic XSS vulnerability.

   2: Response.Write(AntiXss.HtmlEncode(Request.Params["input"]));

3:

   4: //Here is another vulnerability using ASP.NET controls

   5: Label1.Text = AntiXss.HtmlEncode(Request.QueryString["message"]);

Also there are different encoding methods for different context's. For example, if you constructing a URL from user input you should use AntiXss.UrlEncode. The following are different context's and examples.

   1: //HTML Attribute Context

   2: Literal1.Text = "<hr noshade size=" +

   3:         AntiXss.HtmlAttributeEncode(TextBox1.Text) + ">";

4:

   5: //URL Context

   6: String SearchUrl = "http://search.live.com/results.aspx?q=";

   7: Literal1.Text = "<a href=\"" + SearchUrl + AntiXss.UrlEncode(TextBox1.Text) +

   8:                 "\">Example Link</a>";

9:

  10: //JavaScript Context

  11: StringBuilder Str = new StringBuilder();

  12: Str.Append("<script type=\"text/javascript\">\n");

  13: StringArrayConverter StrArrayConv = new StringArrayConverter();

  14: string[] ItemsArray = (string[])StrArrayConv.ConvertFrom(TextBox1.Text);

  15: foreach (string item in ItemsArray)

  16: {

  17:     // Note that JavaScriptEncode adds the starting and end '

  18:     //so we don't need to include them in the code

  19:     Str.Append("listboxItems.push(" +

  20:     Microsoft.Security.Application.AntiXss.JavaScriptEncode(item) + ");\n");

  21: }

  22: Str.Append("FillListBox();\n");

  23: Str.Append("</script>");

  24: Literal1.Text = Str.ToString();

25:

  26: //XML context

  27: // Create XML template

  28: String Xml = "<xml id=\"data\">\n<data>\n<name>{0}</name>\n" +

  29:      "<company>{1}</company>\n<email>{2}</email>\n" +

  30:      "</data>\n</xml>\n";

  31: // Fill template with data provided by user

  32: Literal1.Text = String.Format(Xml, new string[]

  33: {

  34:     Microsoft.Security.Application.AntiXss.XmlEncode(TextBox1.Text),

  35:     Microsoft.Security.Application.AntiXss.XmlEncode(TextBox2.Text),

  36:     Microsoft.Security.Application.AntiXss.XmlEncode(TextBox3.Text)

  37: });

As you see, for specific context you should use that method as each context defines specific encoding pattern. Further information on the usage of AntiXSS is available on MSDN at http://msdn.microsoft.com/en-us/library/aa973813.aspx.

We are working on some significant updates to the library and building some complimentary technology. More from me on that in the coming weeks!