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.

Comments (15)

  1. 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?

  2. Stephen Rylander says:

    Awesome.  Thanks for sharing, we might need something like this.

  3. 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?

  4. M.Gad says:

    I could not download the library,

    Could you please add another working link,

    Thanks for your support,

  5. Seba says:

    Apparently I can’t download it. broken link?

  6. Spinelli says:

    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.

  7. There are no known issues with the HttpUtility version  – this Anti-Xss stuff is just more hardcore.

  8. Techjunkie2 says:

    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]

  9. Spinelli says:

    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.

  10. 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.

  11. booker_t says:

    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.

  12. Kevin Lam says:

    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

  13. Rui Quintino says:

    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.

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

    The first one is a biggie…the ASP.NET team…

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