What is the Microsoft Anti-XSS Library?
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 https://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 = "https://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 https://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!