[Owasp-leaders] AntiSamy

Jason Johnson jason.johnson at owasp.org
Mon Feb 4 23:46:11 UTC 2013


I'm worried that when Bob fills out a page that the un sanitized version of
things leaves less to be desired. I'm still thinking about this....

Jason
On Feb 4, 2013 5:40 PM, "Jim Manico" <jim.manico at owasp.org> wrote:

> CSS has a dangerously broad attack surface, especially when you think of
> some of the strange quirks in older versions of IE (expressions,etc). I try
> to recommend keeping away from untrusted CSS when at all possible, except
> for basic things that come from TinyMCE, CK editor and the like.
>
> These tools are really made to validate the safely of user-generated HTML
> from these widgets (TinyMCE/CK Editor), not validating the safely of entire
> pages of HTML.
>
> Fair?
>
> Cheers Jason,
> - Jim
>
>
> > I think a .net CSS parser need to happen. I hope Microsoft is listening.
> > They have one but its not as policy packed. I'm not a .net genius but I
> > know a thing or two or three.
> >
> > Jason
> > On Feb 4, 2013 5:31 PM, "Jim Manico" <jim.manico at owasp.org> wrote:
> >
> >> Good thoughts, Dinis.
> >>
> >> So SRE is not enough since it depends on the weak getSafeHTML and the
> >> Agility Pack work to you is not up to snuff, ok.
> >>
> >> So that leaves a hole for OWASP AntiSamy for .NET to full then. So
> perhaps
> >> we do need someone to work on it.
> >>
> >> Cheers,
> >> Jim
> >>
> >>> 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/d7098736/attachment-0001.html>


More information about the OWASP-Leaders mailing list