<p>I'm thinking the reason antisammy will not work with. Net4 is the missing CSS parser. Less I'm crazy, I've been told that and that. Net4 lacks that function natively.</p>
<div class="gmail_quote">On Feb 4, 2013 5:40 PM, "Jim Manico" <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

<br>
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.<br>
<br>
Fair?<br>
<br>
Cheers Jason,<br>
- Jim<br>
<br>
<br>
> I think a .net CSS parser need to happen. I hope Microsoft is listening.<br>
> They have one but its not as policy packed. I'm not a .net genius but I<br>
> know a thing or two or three.<br>
><br>
> Jason<br>
> On Feb 4, 2013 5:31 PM, "Jim Manico" <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br>
><br>
>> Good thoughts, Dinis.<br>
>><br>
>> So SRE is not enough since it depends on the weak getSafeHTML and the<br>
>> Agility Pack work to you is not up to snuff, ok.<br>
>><br>
>> So that leaves a hole for OWASP AntiSamy for .NET to full then. So perhaps<br>
>> we do need someone to work on it.<br>
>><br>
>> Cheers,<br>
>> Jim<br>
>><br>
>>> What I like about the SRE (which I have used before) is that it is highly<br>
>>> configurable and allows the injection (via reflection) of 'encoding' (and<br>
>>> other security measures) directly into controllers. And yes it can take<br>
>>> into account the content of the encoding since we can set the encoding<br>
>>> context to Html, HtmlAttribute, Url, Xml XmlAttribute or SafeHtml.<br>
>>><br>
>>> Here are some good references:<br>
>>><br>
>>>    - <a href="http://www.codeproject.com/Articles/359058/SRE-with-Antixss-Module" target="_blank">http://www.codeproject.com/Articles/359058/SRE-with-Antixss-Module</a><br>
>>>    -<br>
>>><br>
>> <a href="http://blogs.msdn.com/b/cisg/archive/2008/12/16/how-the-anti-xss-3-0-sre-works.aspx" target="_blank">http://blogs.msdn.com/b/cisg/archive/2008/12/16/how-the-anti-xss-3-0-sre-works.aspx</a><br>
>>>    -<br>
>>><br>
>> <a href="http://blogs.msdn.com/b/cisg/archive/2008/10/24/a-sneak-peak-at-the-security-runtime-engine.aspx" target="_blank">http://blogs.msdn.com/b/cisg/archive/2008/10/24/a-sneak-peak-at-the-security-runtime-engine.aspx</a><br>

>>>    -<br>
>>><br>
>> <a href="https://antixss.svn.codeplex.com/svn/release/v4.0/Microsoft.Security.Application.SecurityRuntimeEngine.PlugIns/ControlEncodingContext.cs" target="_blank">https://antixss.svn.codeplex.com/svn/release/v4.0/Microsoft.Security.Application.SecurityRuntimeEngine.PlugIns/ControlEncodingContext.cs</a><br>

>>>    -<br>
>>><br>
>> <a href="http://blogs.msdn.com/b/syedab/archive/2009/07/08/preventing-cross-site-scripting-attacks-using-microsoft-anti-xss-security-runtime-engine.aspx" target="_blank">http://blogs.msdn.com/b/syedab/archive/2009/07/08/preventing-cross-site-scripting-attacks-using-microsoft-anti-xss-security-runtime-engine.aspx</a><br>

>>><br>
>>> Now the HtmlAgilityPack is an interesting option (<br>
>>> <a href="http://htmlagilitypack.codeplex.com/" target="_blank">http://htmlagilitypack.codeplex.com/</a>), I actually already it and like<br>
>> it a<br>
>>> lot (for example TeamMentor uses HtmlAgilityPack to create well<br>
>>> formatted/normalized Html content)<br>
>>><br>
>>> But, the problem with the reference that you showed (<br>
>>><br>
>> <a href="http://stephenwalther.com/archive/2012/06/25/announcing-the-june-2012-release-of-the-ajax-control-toolkit.aspx" target="_blank">http://stephenwalther.com/archive/2012/06/25/announcing-the-june-2012-release-of-the-ajax-control-toolkit.aspx</a><br>

>> )<br>
>>> is that it depends on the <a href="http://AjaxControlToolkit.CodePlex.com" target="_blank">http://AjaxControlToolkit.CodePlex.com</a> (i.e.<br>
>> the<br>
>>> Sanitization Library that uses the HtmlAgilityPack is part of the<br>
>>> AjaxControlTookKit and has a hard dependency on it).<br>
>>><br>
>>> I actually spent some time today trying to see if I could use the<br>
>>> HtmlAgilityPack in TeamMentor, and I have to say that as a Developer,<br>
>> what<br>
>>> I saw was not very solid. Basically I'm not that confident (as a<br>
>> developer)<br>
>>>  to use the HtmlAgilityPack for Sanitization, because:<br>
>>><br>
>>>    - the issue I raised above (dependency on AjaxControlToolkit),<br>
>>>    - no code samples easily found,<br>
>>>    - questions like this Suitability for XSS<br>
>>> prevention<<a href="http://htmlagilitypack.codeplex.com/discussions/360758" target="_blank">http://htmlagilitypack.codeplex.com/discussions/360758</a>><br>
>>><br>
>>>    - the fact that the AjaxControlToolkit Sanitizer is a massive RegEx<br>
>> (had<br>
>>>    a look at the code), and<br>
>>>    - I don't want to write my own version of the Sanitizer<br>
>>><br>
>>> I actually think that there is a good opportunity for OWASP, namely the<br>
>>> OWASP-dotnet project, to be involved, since there is clearly a gap here.<br>
>>><br>
>>> The AntiXSS is currently to strict and there are no other easier to add<br>
>>> (and deploy) solutions (specially one available via NuGet).<br>
>>><br>
>>> I will see If we can do something about this at the OWASP-dotnet project,<br>
>>> maybe we could fork the AjaxControlToolkit Sanitizer and make it a stand<br>
>>> alone project.<br>
>>><br>
>>> Dinis Cruz<br>
>>><br>
>>> Blog: <a href="http://diniscruz.blogspot.com" target="_blank">http://diniscruz.blogspot.com</a><br>
>>> Twitter: <a href="http://twitter.com/DinisCruz" target="_blank">http://twitter.com/DinisCruz</a><br>
>>> Web: <a href="http://www.owasp.org/index.php/O2" target="_blank">http://www.owasp.org/index.php/O2</a><br>
>>><br>
>>><br>
>>> On 3 February 2013 22:39, Jim Manico <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br>
>>><br>
>>>> Dinis,<br>
>>>><br>
>>>> SRE only does encoding when it see's the context of display, this is<br>
>> cool.<br>
>>>> But we are talking about a different use case : HTML input from widgets<br>
>>>> like TinyMCE and CKEditor.<br>
>>>><br>
>>>> Take a look at the HtmlSanitizationLibrary assembly found in the 4.x<br>
>>>> AntiXss library.<br>
>>>><br>
>>>> content = Sanitizer.GetSafeHtml(userInput);<br>
>>>><br>
>>>> Now this API is decent, but it's not configurable and is currently *too*<br>
>>>> secure. It also has a history of bypasses<br>
>>>><br>
>> <a href="http://blog.watchfire.com/wfblog/2012/01/microsoft-anti-xss-library-bypass.html" target="_blank">http://blog.watchfire.com/wfblog/2012/01/microsoft-anti-xss-library-bypass.html</a><br>
>> .<br>
>>>> Those bypasses are fixed, but at the expense of being way to tight of a<br>
>>>> ruleset around HTML validation in the current version.<br>
>>>><br>
>>>> I would recommend considering Stephen Walthers work here:<br>
>>>> <a href="http://htmlagilitypack.codeplex.com/" target="_blank">http://htmlagilitypack.codeplex.com/</a><br>
>>>><br>
>>>> More information on why this is important is can be found here:<br>
>>>><br>
>>>><br>
>>>><br>
>> <a href="http://stephenwalther.com/archive/2012/06/25/announcing-the-june-2012-release-of-the-ajax-control-toolkit.aspx" target="_blank">http://stephenwalther.com/archive/2012/06/25/announcing-the-june-2012-release-of-the-ajax-control-toolkit.aspx</a><br>

>>>><br>
>>>> SRE is not going to help you here.<br>
>>>><br>
>>>> - Jim<br>
>>>> @Manicode<br>
>>>><br>
>>>>> Actually on the .NET world we should be exploring the SRE - Security<br>
>>>>> Runtime Engine (part of the Anti-XSS world) which is a spectacular way<br>
>> to<br>
>>>>> inject 'auto-encoding' into .NET apps:<br>
>>>>><br>
>>>>> see <a href="http://wpl.codeplex.com/" target="_blank">http://wpl.codeplex.com/</a><br>
>>>>><br>
>>>>> Interestingly, the latest version of MS AntiXSS is so strong in its<br>
>>>>> secure-by-default, that it pissed of a lot of developers (including<br>
>>>>> yours truly)<br>
>>>>><br>
>>>>> Dinis Cruz<br>
>>>>><br>
>>>>> Blog: <a href="http://diniscruz.blogspot.com" target="_blank">http://diniscruz.blogspot.com</a><br>
>>>>> Twitter: <a href="http://twitter.com/DinisCruz" target="_blank">http://twitter.com/DinisCruz</a><br>
>>>>> Web: <a href="http://www.owasp.org/index.php/O2" target="_blank">http://www.owasp.org/index.php/O2</a><br>
>>>>><br>
>>>>><br>
>>>>> On 3 February 2013 18:16, Jason Johnson <<a href="mailto:jason.johnson@owasp.org">jason.johnson@owasp.org</a>><br>
>> wrote:<br>
>>>>><br>
>>>>>> I noticed and I agree, most of the devs I know do not validate. Im<br>
>> think<br>
>>>>>> that if I can show the benefits of this it could be adopted as a<br>
>>>> standard<br>
>>>>>> federally. AntiSamy as a whole not just the .NET.<br>
>>>>>><br>
>>>>>> Jason<br>
>>>>>> On Feb 3, 2013, at 12:12 PM, Jim Manico wrote:<br>
>>>>>><br>
>>>>>>> The Microsoft AntiXSS .NET function that provides HTML validation<br>
>> does<br>
>>>>>> not provide advanced policy configuration like AntiSamy.<br>
>>>>>>><br>
>>>>>>> So while I think most .NET coders will use the default API (at<br>
>> best), I<br>
>>>>>> do think a .NET AntiSamy is still important.<br>
>>>>>>><br>
>>>>>>> My 2 cents,<br>
>>>>>>> Jim<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>> I am aswell, is the .NET project still needing attention or is the<br>
>> MS<br>
>>>>>>>> version superseded. We could improve on it?<br>
>>>>>>>><br>
>>>>>>>> Thoughts?<br>
>>>>>>>> On Feb 3, 2013 11:44 AM, "Jim Manico" <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>>> I'm very excited to see the AntiSamy projects recent update! Nice<br>
>>>> work,<br>
>>>>>>>>> folks.<br>
>>>>>>>>><br>
>>>>>>>>> <a href="https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project" target="_blank">https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project</a><br>
>>>>>>>>><br>
>>>>>>>>> *****<br>
>>>>>>>>><br>
>>>>>>>>> After over a year, version 1.5 is finally released!<br>
>>>>>>>>><br>
>>>>>>>>> This version requires java 1.5.<br>
>>>>>>>>><br>
>>>>>>>>> 1.5 promises to be significantly faster than previous releases;<br>
>> your<br>
>>>>>>>>> mileage will vary anything from just some percent to a full 5 times<br>
>>>>>> faster,<br>
>>>>>>>>> depending on use cases. A lot of attention has been put to typical<br>
>>>>>> "server"<br>
>>>>>>>>> validation cases in this release.<br>
>>>>>>>>><br>
>>>>>>>>> The DOM parser is still the fastest by a clear margin if you do a<br>
>> lot<br>
>>>>>> of<br>
>>>>>>>>> parameter validation (short strings). If you additionally only use<br>
>>>>>> AntiSamy<br>
>>>>>>>>> to avoid malicious data the DOM parser will be even faster if you<br>
>>>> avoid<br>
>>>>>>>>> calling CleanResults#getCleanHTML<br>
>>>>>>>>><br>
>>>>>>>>> We also fixed issue 133, 135, 147 & 121. Nekohtml has also been<br>
>>>>>> upgraded to<br>
>>>>>>>>> avoid all sorts of interesting OOME's and<br>
>>>>>>>>> stack overflows. Also, this version no longer depends on<br>
>> xercesImpl,<br>
>>>>>>>>> avoiding a whole bunch of interesting conflicts.<br>
>>>>>>>>><br>
>>>>>>>>> The internal interfaces have changed quite significantly; the<br>
>>>> external<br>
>>>>>>>>> interfaces have very minor changes that should not affect most<br>
>> users.<br>
>>>>>>>>><br>
>>>>>>>>> Enjoy !<br>
>>>>>>>>><br>
>>>>>>>>> Kristian<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> OWASP-Leaders mailing list<br>
>>>>>>>>> <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>>>>>>>>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>><br>
>>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OWASP-Leaders mailing list<br>
>>>>>> <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>>>>>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
>>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>><br>
>><br>
>><br>
><br>
<br>
</blockquote></div>