[Owasp-antisamy] dotNet - Some suggestions

Ricardo Lopes rjlopes at gmail.com
Tue Mar 24 06:09:57 EDT 2009


Hi,

I will look for a CSS grammar file and try to generate a C# parser
from it, I am not experienced at this but I think it shouldn't be that
hard.

I will let you know if I make it work.

Best Regards,
Ricardo Lopes.

2009/3/24 Jerry Hoff <jerry.hoff at aspectsecurity.com>:
> Hi Ricardo,
>
> I agree with you, but the csharpcc project uses IKVM, and the CSJavaCC
> project doesn't seem to be what we would need for antisamy.net.
>
> I'd like to take out the vjslib requirement so it's compatible with Mono,
> but I'd need a replacement for flute that doesn't require it.  I'll
> definitely keep looking, and if you find one let me know.
>
> Thanks,
> Jerry
>
>
> -----Original Message-----
> From: Ricardo Lopes [mailto:rjlopes at gmail.com]
> Sent: Fri 3/20/2009 8:40 PM
> To: Jerry Hoff
> Cc: Jason Li; Steve Sheldon; owasp-antisamy at lists.owasp.org
> Subject: Re: [Owasp-antisamy] dotNet - Some suggestions
>
> Hi,
>
> The fluent interface looks nice.
>
> I would add a request to drop the vjslib requirement introduced on the
> last version when css support was added using Flute. I have problems
> with this because I'm targeting the Mono Runtime and everything worked
> in the previous release and i was waiting for css support, but J#
> won't be supported on Mono and using IKVM adds too much overhead.
>
> For what I could read today, Flute was created using JavaCC, I don't
> known much about this but from a fast search i could find 2 projects
> that do this that uses JavaCC grammar files to output C# code:
>
> http://sourceforge.net/projects/csharpcc
> http://www.ccs.neu.edu/research/demeter/DemeterF/csharp/csjavacc.html
>
> What do you think?
>
>
>
> 2009/3/20 Jerry Hoff <jerry.hoff at aspectsecurity.com>:
>> Hi Steve,
>>
>> Thank you for your suggestions.
>>
>> #1 - Agreed
>> #2 - Agreed
>> #3 - at first I didn't agree, but the more I thought about it, the more I
>> like the idea. Would make it much faster, and better for situations where
>> the config file doesn't change much.  If you'd like to contrib some code
>> to
>> that, i'd appreciate it.  Otherwise, I'll put it on my todo list.
>> #4 - Agreed
>>
>> Thanks for the feedback!
>>
>> Jerry
>>
>>
>>
>> -----Original Message-----
>> From: owasp-antisamy-bounces at lists.owasp.org on behalf of Jason Li
>> Sent: Sun 3/15/2009 11:30 PM
>> To: Steve Sheldon
>> Cc: owasp-antisamy at lists.owasp.org
>> Subject: Re: [Owasp-antisamy] dotNet - Some suggestions
>>
>> Steve,
>>
>> Thanks for the suggestions!
>>
>> I'll let Jerry and Arshan speak to the .NET comments as I'm more familiar
>> with Java, but in terms of the XML-based policy file, I don't think that
>> will go away.
>>
>> An XML-based policy file allows users to easily customize the policy
>> without
>> recompiling code (which is extremely desirable). It also allows us
>> maintain
>> a single white-list of HTML/CSS that can be used by both the Java and .NET
>> versions of AntiSamy whithout any additional work.
>>
>> That's not to say that we can't come up with a programmatic way to modify
>> the policy. In fact, one of the many things we would like to do for future
>> versions of AntiSamy is to create a policy editor GUI. In doing so, it
>> would
>> be a good design  to abstract out the functionality of creating/modifying
>> the policy so that the functionality can be exposed to anyone that wants
>> to
>> access it programmatically. But even with this potential feature, I
>> imagine
>> that the base policy behavior will remain XML-based.
>>
>> --
>> -Jason Li-
>> -jason.li at owasp.org-
>>
>>
>> On Sun, Mar 15, 2009 at 2:55 PM, Steve Sheldon <steve at sodablue.org> wrote:
>>
>>> I've been digging through the AntiSamy code, and have a couple of
>>> suggestions.
>>>
>>> 1. Make Action on Tag and OnInvalid on Attribute into enums.  Rather then
>>> doing string matches, I think it'd be better to have Enums... this would
>>> make it more clear what are acceptable values.
>>>
>>> 2. I would break up recursiveValidateTag into sub methods. for filter,
>>> validate and truncate actions.  Similarly validate should call sub
>>> methods
>>> for attribute validation.  The method is just too long and this would
>>> improve readibility.  Try to keep methods under 25 lines so they fit on
>>> the
>>> screen.  In combination with the enum in #1, it'd mean the use of a
>>> switch()
>>> instead of multiple if/then statements.
>>>
>>> 3. While I really like the use of Dependency Injection on the scanner
>>> with
>>> the Policy object, I'd suggest taking this one more step and use
>>> interfaces:
>>>
>>>   public interface IPolicy
>>>>   {
>>>>     string getDirective(string name);
>>>>     IAttribute getGlobalAttributeByName(string name);
>>>>     IProperty getPropertyByName(string propertyName);
>>>>     string getRegularExpression(string name);
>>>>     ITag getTagByName(string tagName);
>>>>   }
>>>
>>>
>>>   public interface IAttribute : ICloneable
>>>>   {
>>>>     IList AllowedValues { get; }
>>>>     IList AllowedRegExp { get; }
>>>>     string Description { get; set; }
>>>>     string Name { get; set; }
>>>>     string OnInvalid { get; set; }
>>>>   }
>>>>
>>>
>>>   public interface IProperty
>>>>   {
>>>>     string Description { get; set; }
>>>>     string Name { get; set; }
>>>>     string OnInvalid { get; set; }
>>>>   }
>>>>
>>>
>>>   public interface ITag
>>>>   {
>>>>     string Action { get; set; }
>>>>     Attribute getAttributeByName(string name);
>>>>     string Name { get; set; }
>>>>   }
>>>
>>>
>>> Using the interfaces would make it easier to extend the implementation of
>>> Policy with a custom implementation.
>>>
>>> Why? I'm just not a big fan of XML configuration.  So I am trying to
>>> implement a Fluent interface that looks something like this when used:
>>>
>>>     public static IPolicy GetFluentPolicy()
>>>>     {
>>>>         const string c_reghtmlTitle =
>>>> @"^([a-zA-Z0-9\s-_',:\[\]!\./\\\(\)]*)$";
>>>>         const string c_regonsiteURL = @"^^((\s)*((ht|f)tp(s?)://|mailto:
>>>> )[A-Za-z0-9]+[~a-zA-Z0-9-_\[email protected]#$%&;:,\?=/\+!]*(\s)*)$";
>>>>         const string c_regoffsiteURL = @"^((\s)*((ht|f)tp(s?)://|mailto:
>>>> )[A-Za-z0-9]+[~a-zA-Z0-9-_\[email protected]#$%&;:,\?=/\+!]*(\s)*)$";
>>>>
>>>>         FluentPolicy policy = new FluentPolicy()
>>>>           .AddDirective("maxInputSize", "500000")
>>>>           .AddCommonAttributes(new FluentAttribute("lang")
>>>>                                 .addAllowedRegExp(@"[a-zA-Z]{2,20}"))
>>>>           .AddCommonAttributes(new FluentAttribute("title")
>>>>                                 .addAllowedRegExp(c_reghtmlTitle))
>>>>           .AddCommonAttributes(new FluentAttribute("href")
>>>>                                 .addAllowedRegExp(c_regonsiteURL)
>>>>                                 .addAllowedRegExp(c_regoffsiteURL))
>>>>           .AddCommonAttributes(new FluentAttribute("align")
>>>>                                 .addAllowedValue("center")
>>>>                                 .addAllowedValue("left")
>>>>                                 .addAllowedValue("right")
>>>>                                 .addAllowedValue("justify")
>>>>                                 .addAllowedValue("char"))
>>>>           .AddGlobalAttribute("title")
>>>>           .AddGlobalAttribute("lang");
>>>>
>>>>       return policy;
>>>>     }
>>>
>>>
>>> While I'd probably keep an instance of IPolicy in my inversion of control
>>> container, I also suspect(but haven't verified) that instantiation of a
>>> policy using this interface would be faster than from an xml
>>> configuration
>>> file.
>>>
>>> 4. Also, I'd build AntiSamy as a class assembly, and place the unit tests
>>> and the console application logic in their own projects.  I just see no
>>> reason for them to be in the core implementation.
>>>
>>> I'll probably have some more thoughts as I dig in further.  It seems to
>>> me
>>> some of the logic in terms of global and tag specific interfaces could be
>>> better represented through the Policy class instead of having to be in
>>> the
>>> domscanner, as this is kind of logic specific to the policy... the notion
>>> that a tag attribute is implemented by tag specific attribute, or global
>>> attributes if they exist.
>>>
>>> Anyway, just some thoughts.
>>>
>>>
>>> _______________________________________________
>>> Owasp-antisamy mailing list
>>> Owasp-antisamy at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-antisamy
>>>
>>>
>>
>>
>> _______________________________________________
>> Owasp-antisamy mailing list
>> Owasp-antisamy at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-antisamy
>>
>>
>
>
>
> --
>
> Ricardo Lopes
>
>



-- 

Ricardo Lopes


More information about the Owasp-antisamy mailing list