[Owasp-antisamy] dotNet - Some suggestions

Ricardo Lopes rjlopes at gmail.com
Fri Mar 20 20:40:48 EDT 2009


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


More information about the Owasp-antisamy mailing list