Microsoft Anti-Cross Site Scripting Library V1.0 Available

Published 27 February 06 01:32 PM

I like this class library because it looks for "good things" and not "bad things."  

The most common method of mitigating XSS issues is to use functions like HtmlEncode that look for "bad things" and escape them. But this library does the right thing - it looks only for good things (a very small set), and escapes everything else.

There are only two methods:

AntiXSSLibrary.HtlmEncode and AntiXSSLibrary.UrlEncode

Very cool... and very simple.

Filed under:

Comments

# Bertrand Le Roy said on February 27, 2006 6:07 PM:
The link does not give any details on what the library is doing exactly. How is that different from the HtmlEncode and UrlEncode that are built-in ASP.NET?
# Stephen Rylander said on March 6, 2006 10:23 AM:
Awesome.  Thanks for sharing, we might need something like this.
# Milan Negovan said on March 6, 2006 10:42 AM:
Michael, ironically the install demands .NET 1.0 (!) while the download description says "Current MSI includes only 2.0 binaries".

Do you think someone can repackage the distro not to demand an old version of .NET? :)

Pardon my ignorance, but since when does Windows Installer expect a certain version of .NET?
# M.Gad said on March 7, 2006 12:45 AM:
I could not download the library,
Could you please add another working link,
Thanks for your support,
# Seba said on March 7, 2006 3:21 PM:
Apparently I can't download it. broken link?
# Spinelli said on March 10, 2006 8:36 AM:
Michael,

As described in the User Documentation about this library, the motivation for  creating it is that the classes included in the namespace System.Web.HttpUtility don’t implement the encode procedure using the best practices that would be searching for "good" characters and assumes everything else is invalid, encoding it.
But I couldn’t find any example of characteres that doesn’t apply to those (<, >, &, “, 160-255 chars) that justifies the threat on the "searching for bad chars" way to implement the encoding.

And always when I try to convince other people to use this library they ask me one handy (practical) example that could show the threat of using the System.Web.HttpUtility version...

I would be very gratefull if you could give me examples showing the issues involved when we use the System.Web.HttpUtility version.

Tks.
# michael_HOWARD said on March 10, 2006 2:45 PM:
There are no known issues with the HttpUtility version  - this Anti-Xss stuff is just more hardcore.
# techjunkie said on March 11, 2006 5:36 PM:
Thanks Michael for the post.  If you had trouble downloading, please try again, it should work fine.  For those who had questions, please watch our blog (http://blogs.msdn.com/ace_team)We'll be posting details on this library there in the next day or two along with some additional details.  

Ahmad [MSFT]
# Spinelli said on March 13, 2006 9:03 AM:
What do you mean with "this Anti-Xss stuff is just more hardcore." ? Is it "Just use it because it's better" ?

I understood the two ways to implement the enconding (search for bad or good chars), but if there is no issue about using the "search for bad" way, i think this is just different ways of doing the same thing, so why don't use one or other?

Could the argument be "one has more defensive implementation than the other" ?

Tks.

Bruno Spinelli.
# michael_HOWARD said on March 13, 2006 12:39 PM:
to be honest, "does it the way it should be done securely" is probably more accurate!

One of the course lessons about security is never "looking for bad things" and you could argue that's what HttpUtility does. It looks for bad things and escapes them. the Anti-Xss code looks only for good things, and escapes everything but the known good things.
# booker_t said on March 15, 2006 9:12 AM:
Everyone thinking of using this tool in a production or non-demo environment needs to read the EULA. To quote Section 1:

You may install and use any number of copies of the software on your devices.  You may use the software only to demonstrate and internally evaluate it.

You may not use the software in a live operating environment unless Microsoft permits you to do so under another agreement.


# Kevin Lam said on March 20, 2006 12:37 PM:
Regarding the EULA, that's the standard EULA we use for an 'unsupported' tool -- so that might bewhere the confusion is coming from.  That said, we'll still field questions about the tool if you email acetools@microsoft.com. Thanks,

Kevin
# Rui Quintino said on March 24, 2006 5:30 PM:

Interesting. Actually, there was a configuration specific issue with htmlencode detected (August 2004):

http://it-project.ru/andir/docs/aspxvuln/aspxvuln.en.xml

Probably not well known, and mostly ignored, due to its specific configuration to be exploitable. Still, it shows the advantages of  the new toolkit approach.


# .net DEvHammer (formerly .net DElirium) said on April 18, 2006 4:07 PM:
Time for another ASP.NET roundup post...so here goes:

The first one is a biggie...the ASP.NET team...
# Michael Howard's Web Log said on November 20, 2006 4:54 PM:

Earlier this year I wrote a blog post about Anti-XSS Library v1.0. Well, it's been updated with new methods

New Comments to this post are disabled
Page view tracker