HTMLAttributeEncode Framework differences

Posted by on January 20, 2010

I have done a few posts regarding Cross Site Scripting and how to protect against it.  I came across an interesting item today comparing the output of HTMLAttributeEncode between .Net 1.1 and 2.0+.  I thought it would be a good idea to dig a little deeper into how the encoding really works.  The .Net 1.1 framework only encodes the quote (“) and ampersand (&) symbols when it renders them.  In the .Net 2.0 framework, Microsoft decided to add the less-than (<) symbol as well. 

Scripts do not appear to run when they are within the quotes so doing a simple <script>alert(‘hello’)</script> doesn’t cause an alert box to appear when it is within quotes in an attribute.  So why add the (<) symbol?  It could be that by blocking this, it blocks the ability to start a script tag.   Even if you are able to break out of the attribute, you could close the current element, but not start a new one.

Anything Missed?

What about the single quote, or apostrophe (‘).  Not every item that is sent to the output goes through a server control.  Many times, attributes are wrapped single quotes, rather than double quotes.  The single quote can be used to break out of the attribute and perform an attack. 

The issue here is that the HTTPUtility.HTMLAttributeEncode uses blacklisting to determine what characters to encode.  The list was displayed in the first paragraph.   I discussed this in this recent post “Protecting against Cross Site Scripting.”   That post mentions using Microsoft’s Anti-XSS library instead of the HTTPUtility library for encoding data.  You can read more about those at the previously mentioned link.  I do want to take just a moment to give an example of the difference in output between the two methods.  I output the following text to each method—> <script>alert(‘hello’);</script>

The Results





Results of Single Quoted Values (‘ onblur=alert(‘java’); t=’)


value=’’ onblur=alert(‘java’); t=’’




A quick glance at the outputs and it is clear that the Anti-XSS library encodes much more than the built in routine.  In the second set of results, we se that the HTTPUtility.HTMLAttributeEncode creates a new attribute for “onBlur”.  This exposes a vulnerability in the application.  The Anti-XSS version, however, does not create the new attribute, but encodes so the whole string is part of the Value attribute.  This approach provides much more coverage and is just as easy to implement.  It is important to understand the differences in the .Net Framework versions, as well as the external libraries that are provided.   These subtle differences are what can give an attacker an opening to your application.  Encode, but encode correctly.


Comments are closed.