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

Jason Li jason.li at owasp.org
Thu Mar 19 20:16:55 EDT 2009


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