[Owasp-leaders] AntiSamy

Jim Manico jim.manico at owasp.org
Mon Feb 4 23:45:45 UTC 2013


> I think a .net CSS parser need to happen.

I think in general that CSS sanitation tools along the lines of projects and API's like ...

OWASP AntiSamy
OWASP Java HTML Sanitizer
OWASP Java JSON Sanitizer
.NET's getSafeHTML API
PHP's HTML Purifier
etc...

... is very appropriate, but I think it needs to be VERY restrictive because of CSS's broad attack surface.

OWASP CSS Sanitizer anyone?

Aloha 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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 



More information about the OWASP-Leaders mailing list