[Owasp-leaders] AntiSamy

Jim Manico jim.manico at owasp.org
Tue Feb 5 00:50:37 UTC 2013


Dennis,

SRE has it's place in the world, but it has gaps that the smart security minded developer should be aware of. 

Or put a different way, SRE has gaps that the informed security consultant or advisor NEEDS to be aware of.

Aloha,
- Jim

> On 4 Feb 2013, at 23:32, Jim Manico 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.
> 
> Given that we spent around $3 million on SRE at the time; and it has
> mostly stood the test of time - perhaps you should consider it as a
> starting point for a good open source re-implementation that includes
> today's threats?
> 
> 
> 
>> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> 
> 



More information about the OWASP-Leaders mailing list