HTML tags stripped from Mission Statment, default page visible

yeah, i think thats not needed. mission should be in default input format like other textareas. here is the code that strips (from theme/engines/phptemplate.engine): $mission = filter_xss(theme_get_setting('mission'));

That filter_xss() statement arose from a security mailinglist discussion.

The text-handling situation in 4.6 used to be that we had two types of text: plain-text and rich. Plain-text was simply escaped and output without formatting, while rich text passed through the filter system. This idea was not always applied consistently though. The mission statement was an example of a field which was output raw instead. Technically this was an XSS issue, though in practice no-one would ever allow a non-admin to change the mission statement.

There are a couple of other areas where there is or was a similar unsafe or inconsistent formatting use. Most of the time it comes down to the fact that providing an input format choice is impractical for some fields and/or that restricting the admin to the default input format is undesirable.

A good use case is taxonomy term descriptions. Many admins want to use simple inline mark-up here (emphasis, links, ...). But, we don't really want to store an input format for every single taxonomy term. Plus, taxonomy descriptions should be small and to the point: they should not contain block-level elements like <p>, which is what the filter system outputs.

So my proposal was to use filter_xss() there instead, with a permissive (fixed) set of allowed tags. The output would still validate and be safe, admins could still use some HTML mark-up, but the whole format business (which is mostly aimed at end-users) does not come into play. There is also the advantage that we restrict ourselves to a single, known format, which means we can easily use strip_tags to remove markup (this is e.g. necessary when using taxonomy term descriptions as tooltips).

This was not intended to hit 4.7/4.6 yet, but I spoke the magic XSS word and someone decided it should go in anyway, for the mission statement at least.

This needs to be noted somewhere (upgrade notes?) - it may catch people out. Its been on my bugs todo list for a while, until I stumbled on this issue.

Yeah, people should collect such things for the upgrading guide and/or a release announcement.

Moving to docs.

I guess my next question is but Footer does allow Raw or HTML

Is there a differnet the way thes tow sections arew handled internally?

thanks

Section created http://drupal.org/node/57649

Page for this issue created: http://drupal.org/node/57650
Edit or comment if you have improvements. The contents were taken from a few different posts.

Here's a patch which implements the approach I outlined above and applies it consistently to all admin fields where necessary. All HTML tags that can be used in the html body are allowed, except scripts and styles.

Committed after a discussion. Too many people would have complains about the mission, and the patch is quite small anyway. Plus, it is a good policy to avoid raw output whenever we can.