[Owasp-antisamy] strip ALL html tags,js,css with antisamy?
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.
On Thu, Mar 19, 2009 at 5:16 PM, Jason Li <jason.li at owasp.org> wrote:
> 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
> <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
>> Owasp-antisamy mailing list
>> Owasp-antisamy at lists.owasp.org
More information about the Owasp-antisamy