[Owasp-antisamy] strip ALL html tags,js,css with antisamy?

Sam Gendler sgendler at gmail.com
Thu Mar 19 22:18:35 EDT 2009


Thanks.  That's really helpful.  I'm using it in a web app that uses
spring for inversion of control.  Currently, I inject one instance of
each policy (1 slashdot, 1 strip everything) and an instance of
AntiSamy into any code which needs to process user input.  Then I just
feed the content and the policy to the AS object, so I sure hope
everything works as expected when used as a singleton.

--sam


On Thu, Mar 19, 2009 at 5:16 PM, Jason Li <jason.li at owasp.org> wrote:
> Sam,
>
> I'm not sure how you're quantifying "very rapidly" but if you have an
> empty policy file, all tags would be stripped out.
>
> You can go through the policy file and specify the action for any tag
> you would like by changing the action attribute of the tag. For
> example:
> <tag name="input" action="filter">
>
> Most of the tags in the base antisamy policy file use "validate" as
> the action attribute.
>
> The AntiSamy object was refactored to re-use a Policy object stored as
> an instance variable in the AntiSamy project. The previous behavior
> was to construct a new Policy object for each call of the scan()
> method, which introduced unnecessary processing overhead for
> subsequent calls to scan().
>
> Off the top of my head, I'm not completely sure about the thread
> safety of the AntiSamy object, but I *believe* it is virtually thread
> safe as the only concurrency issue I see arising is with the Policy
> object. The Policy object is technically not thread safe as the
> getDirective()/setDirective() methods were not written with thread
> safety in mind. However, the existing codebase never makes any call to
> the setDirective() method so while the method is technically exposed,
> so long as you're in control of the code calling AntiSamy, you can
> prevent any concurrency issues from arising by never using the
> setDirective() method.
>
> One of the planned future enhancements is better control of the Policy
> object. When this feature is added, we'll make sure to keep thread
> safety in mind so the new Policy object will be thread safe.
> --
> -Jason Li-
> -jason.li at owasp.org-
>
>
>
> On Thu, Mar 12, 2009 at 10:25 PM, Sam Gendler <sgendler at ideasculptor.com> wrote:
>> It is easy enough to use something like the slashdot policy file on
>> fields that are intended to have some formatting, but is it possible
>> to configure an antisamy policy file such that antisamy will very
>> rapidly strip out ALL html tags for fields like a user's name, which
>> may well be rendered to the page, too?  I can set up validation that
>> will limit the character set and structure, and I always html-escape
>> such strings when they are outbound so tags should never be
>> interpreted by the browser, but it would be an extra level of security
>> to simply strip all such content at submission time.  It occurs to me
>> that default behaviour must be to strip all tags that aren't
>> explicitly listed in the policy file, so I can probably just have an
>> empty tag-rules section in the policy file, but is there a way to
>> specify whether the behaviour should be tag removal or tag filtering
>> in that case?  I'd really rather have tag filtering in most instances.
>>
>> Also, in my search through the archives, I saw mention of reusing the
>> instance with different policy objects in order to avoid policy
>> parsing overhead.  There was mention of future changes in support of
>> this.  I'm curious as to whether that is now a viable strategy.  Is
>> the AntiSamy object threadsafe?  What about the policy object?  Can I
>> simply instantiate a single AntiSamy singleton and a single instance
>> of each supported policy which can then be shared be all processing
>> threads?
>> _______________________________________________
>> Owasp-antisamy mailing list
>> Owasp-antisamy at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-antisamy
>>
>


More information about the Owasp-antisamy mailing list