[Owasp-leaders] AntiSamy

Dinis Cruz dinis.cruz at owasp.org
Mon Feb 4 23:11:54 UTC 2013


What I like about the SRE (which I have used before) is that it is highly
configurable and allows the injection (via reflection) of 'encoding' (and
other security measures) directly into controllers. And yes it can take
into account the content of the encoding since we can set the encoding
context to Html, HtmlAttribute, Url, Xml XmlAttribute or SafeHtml.

Here are some good references:

   - http://www.codeproject.com/Articles/359058/SRE-with-Antixss-Module
   -
   http://blogs.msdn.com/b/cisg/archive/2008/12/16/how-the-anti-xss-3-0-sre-works.aspx
   -
   http://blogs.msdn.com/b/cisg/archive/2008/10/24/a-sneak-peak-at-the-security-runtime-engine.aspx
   -
   https://antixss.svn.codeplex.com/svn/release/v4.0/Microsoft.Security.Application.SecurityRuntimeEngine.PlugIns/ControlEncodingContext.cs
   -
   http://blogs.msdn.com/b/syedab/archive/2009/07/08/preventing-cross-site-scripting-attacks-using-microsoft-anti-xss-security-runtime-engine.aspx

Now the HtmlAgilityPack is an interesting option (
http://htmlagilitypack.codeplex.com/), I actually already it and like it a
lot (for example TeamMentor uses HtmlAgilityPack to create well
formatted/normalized Html content)

But, the problem with the reference that you showed (
http://stephenwalther.com/archive/2012/06/25/announcing-the-june-2012-release-of-the-ajax-control-toolkit.aspx)
is that it depends on the http://AjaxControlToolkit.CodePlex.com (i.e. the
Sanitization Library that uses the HtmlAgilityPack is part of the
AjaxControlTookKit and has a hard dependency on it).

I actually spent some time today trying to see if I could use the
HtmlAgilityPack in TeamMentor, and I have to say that as a Developer, what
I saw was not very solid. Basically I'm not that confident (as a developer)
 to use the HtmlAgilityPack for Sanitization, because:

   - the issue I raised above (dependency on AjaxControlToolkit),
   - no code samples easily found,
   - questions like this Suitability for XSS
prevention<http://htmlagilitypack.codeplex.com/discussions/360758>

   - the fact that the AjaxControlToolkit Sanitizer is a massive RegEx (had
   a look at the code), and
   - I don't want to write my own version of the Sanitizer

I actually think that there is a good opportunity for OWASP, namely the
OWASP-dotnet project, to be involved, since there is clearly a gap here.

The AntiXSS is currently to strict and there are no other easier to add
(and deploy) solutions (specially one available via NuGet).

I will see If we can do something about this at the OWASP-dotnet project,
maybe we could fork the AjaxControlToolkit Sanitizer and make it a stand
alone project.

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2


On 3 February 2013 22:39, Jim Manico <jim.manico at owasp.org> wrote:

> Dinis,
>
> SRE only does encoding when it see's the context of display, this is cool.
> But we are talking about a different use case : HTML input from widgets
> like TinyMCE and CKEditor.
>
> Take a look at the HtmlSanitizationLibrary assembly found in the 4.x
> AntiXss library.
>
> content = Sanitizer.GetSafeHtml(userInput);
>
> Now this API is decent, but it's not configurable and is currently *too*
> secure. It also has a history of bypasses
> http://blog.watchfire.com/wfblog/2012/01/microsoft-anti-xss-library-bypass.html.
> Those bypasses are fixed, but at the expense of being way to tight of a
> ruleset around HTML validation in the current version.
>
> I would recommend considering Stephen Walthers work here:
> http://htmlagilitypack.codeplex.com/
>
> More information on why this is important is can be found here:
>
>
> http://stephenwalther.com/archive/2012/06/25/announcing-the-june-2012-release-of-the-ajax-control-toolkit.aspx
>
> SRE is not going to help you here.
>
> - Jim
> @Manicode
>
> > Actually on the .NET world we should be exploring the SRE - Security
> > Runtime Engine (part of the Anti-XSS world) which is a spectacular way to
> > inject 'auto-encoding' into .NET apps:
> >
> > see http://wpl.codeplex.com/
> >
> > Interestingly, the latest version of MS AntiXSS is so strong in its
> > secure-by-default, that it pissed of a lot of developers (including
> > yours truly)
> >
> > Dinis Cruz
> >
> > Blog: http://diniscruz.blogspot.com
> > Twitter: http://twitter.com/DinisCruz
> > Web: http://www.owasp.org/index.php/O2
> >
> >
> > On 3 February 2013 18:16, Jason Johnson <jason.johnson at owasp.org> wrote:
> >
> >> I noticed and I agree, most of the devs I know do not validate. Im think
> >> that if I can show the benefits of this it could be adopted as a
> standard
> >> federally. AntiSamy as a whole not just the .NET.
> >>
> >> Jason
> >> On Feb 3, 2013, at 12:12 PM, Jim Manico wrote:
> >>
> >>> The Microsoft AntiXSS .NET function that provides HTML validation does
> >> not provide advanced policy configuration like AntiSamy.
> >>>
> >>> So while I think most .NET coders will use the default API (at best), I
> >> do think a .NET AntiSamy is still important.
> >>>
> >>> My 2 cents,
> >>> Jim
> >>>
> >>>
> >>>
> >>>> I am aswell, is the .NET project still needing attention or is the MS
> >>>> version superseded. We could improve on it?
> >>>>
> >>>> Thoughts?
> >>>> On Feb 3, 2013 11:44 AM, "Jim Manico" <jim.manico at owasp.org> wrote:
> >>>>
> >>>>> I'm very excited to see the AntiSamy projects recent update! Nice
> work,
> >>>>> folks.
> >>>>>
> >>>>> https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project
> >>>>>
> >>>>> *****
> >>>>>
> >>>>> After over a year, version 1.5 is finally released!
> >>>>>
> >>>>> This version requires java 1.5.
> >>>>>
> >>>>> 1.5 promises to be significantly faster than previous releases; your
> >>>>> mileage will vary anything from just some percent to a full 5 times
> >> faster,
> >>>>> depending on use cases. A lot of attention has been put to typical
> >> "server"
> >>>>> validation cases in this release.
> >>>>>
> >>>>> The DOM parser is still the fastest by a clear margin if you do a lot
> >> of
> >>>>> parameter validation (short strings). If you additionally only use
> >> AntiSamy
> >>>>> to avoid malicious data the DOM parser will be even faster if you
> avoid
> >>>>> calling CleanResults#getCleanHTML
> >>>>>
> >>>>> We also fixed issue 133, 135, 147 & 121. Nekohtml has also been
> >> upgraded to
> >>>>> avoid all sorts of interesting OOME's and
> >>>>> stack overflows. Also, this version no longer depends on xercesImpl,
> >>>>> avoiding a whole bunch of interesting conflicts.
> >>>>>
> >>>>> The internal interfaces have changed quite significantly; the
> external
> >>>>> interfaces have very minor changes that should not affect most users.
> >>>>>
> >>>>> Enjoy !
> >>>>>
> >>>>> Kristian
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OWASP-Leaders mailing list
> >>>>> OWASP-Leaders at lists.owasp.org
> >>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> OWASP-Leaders mailing list
> >> OWASP-Leaders at lists.owasp.org
> >> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20130204/7e67a5dc/attachment.html>


More information about the OWASP-Leaders mailing list