Issues

ZF-8484: Clarify the utility of Zend_Filter_StripTags to inform users of its appropriate use cases

Description

The documentation for Zend_Filter_StripTags begins and ends with:

{quote}This filter returns the input string, with all HTML and PHP tags stripped from it, except those that have been explicitly allowed. In addition to the ability to specify which tags are allowed, developers can specify which attributes are allowed across all allowed tags and for specific tags only. Finally, this filter offers control over whether comments (e.g., ) are removed or allowed.{quote}

In the wild, the StripTags filter is being used to prepare the direct output (i.e. non-escaped) of user or externally sourced HTML. The filter is configured for this purpose to allow a subset of commonly used HTML tags and attributes. This gives rise to two concerns:

  1. The API is not explained, and configurations may utilise the setAttributesAllowed() method to enable the attributes of tags. This is problematic since the method adds globally enabled attributes - i.e. they will be allowed for all allowed tags.

  2. The StripTags filter is not XSS safe, gives rise to malformed HTML, and allows for standalone closing tags. Any of these can be exploited on a site utilising the StripTags filter as its sole means of filtering HTML for direct output.

  3. Even when employed correctly, the StripTags filter utilises a loose regular expression for tag matching. This will delete any text containing an angle bracket (e.g. <).

Examples of this presumably invalid use of the StripTags filter is evident from public email lists and forums (like Stackoverflow). Given that misuse is obviously occurring in the wild, the correct usage of the StripTags filters should be explained in greater detail. Its existence in the wild on websites constitutes a significant security risk to those misapplying the filter.

Comments

Duplication of ZF-8483

It's not a duplication, this issue is a request to improve the documentation to eliminate any doubt about the role of Zend_Filter_StripTags. The linked issue concerns the actual source code and its flaws and does not refer in any way to the current state of the documentation.

They may be related, but they are not duplicates.

Until now, when I changed a filter I always documented the complete class. I documented about 5 filters this way which were only mentioned by a single sentence. You know that because it is a work in progress since 4 months. You also read the channel yesterday and what I replied.

I have the feeling that in your opinion it would be better when I don't fix the class ( ZF-8483 ), don't add a chapter ( ZF-8484 ) and also don't try to make ZF more secure ( http://framework.zend.com/wiki/display/… ) :-/

May I ask why ?

You feeling is misplaced, Thomas ;). I was only commenting that a documentation issue is not mentioned in the other issue and therefore it cannot be a duplicate. I can't be expected to track the documentation efforts of every developer so I reasonably assumed (until proven wrong) that no docs change would be made without prompting. If I'm wrong in that regard, I do apologise, but I stand by the current issue remaining open until reasonably resolved. If you decide to make note of the documentation issue in ZF-8483, then this issue may of course be closed as being tracked elsewhere (i.e. it would become a true duplicate).

On an honest note, I'm of the opinion the StripTags filter cannot be fixed and should be replaced. The class as is has had several reported XSS exploits so far, and is obviously undependable in this role. I support your proposal 100%. I'm writing an email to the zf-contributors list to highlight this.

The related section was added as part of ZF-8966 and ZF-8920 Several warnings have been added in addition