Welcome to MSDN Blogs Sign in | Join | Help

Michael Howard's Web Log

A Simple Software Security Guy at Microsoft!
Microsoft Anti-Cross Site Scripting Library V1.0 Available

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.

Posted: Monday, February 27, 2006 1:32 PM by michael_HOWARD
Filed under:

Comments

Bertrand Le Roy said:

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?
# February 27, 2006 6:07 PM

Stephen Rylander said:

Awesome.  Thanks for sharing, we might need something like this.
# March 6, 2006 10:23 AM

Milan Negovan said:

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?
# March 6, 2006 10:42 AM

M.Gad said:

I could not download the library,
Could you please add another working link,
Thanks for your support,
# March 7, 2006 12:45 AM

Seba said:

Apparently I can't download it. broken link?
# March 7, 2006 3:21 PM

Spinelli said:

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.
# March 10, 2006 8:36 AM

michael_HOWARD said:

There are no known issues with the HttpUtility version  - this Anti-Xss stuff is just more hardcore.
# March 10, 2006 2:45 PM

techjunkie said:

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]
# March 11, 2006 5:36 PM

Spinelli said:

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.
# March 13, 2006 9:03 AM

michael_HOWARD said:

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.
# March 13, 2006 12:39 PM

booker_t said:

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.


# March 15, 2006 9:12 AM

Kevin Lam said:

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
# March 20, 2006 12:37 PM

Rui Quintino said:


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.


# March 24, 2006 5:30 PM

.net DEvHammer (formerly .net DElirium) said:

Time for another ASP.NET roundup post...so here goes:

The first one is a biggie...the ASP.NET team...
# April 18, 2006 4:07 PM

Michael Howard's Web Log said:

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

# November 20, 2006 4:54 PM
New Comments to this post are disabled
Page view tracker