[documentation] [Documentation bug] HTML tags stripped from Mission Statment, default page visible

[killes]

Issue status update for 
http://drupal.org/node/55898
Post a follow up: 
http://drupal.org/project/comments/add/55898

-Project:      Drupal
+Project:      Documentation
 Version:      <none>
-Component:    base system
+Component:    Admin Guide
 Category:     bug reports
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  pwolanin
 Updated by:   killes at www.drop.org
 Status:       active

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


Moving to docs.




killes at www.drop.org



Previous comments:
------------------------------------------------------------------------

Sun, 26 Mar 2006 05:13:07 +0000 : pwolanin

I just updated a site from drupal 4.7-beta5 to CVS (2006-03-25), and I'm
seeing two odd behaviors on the <front> page.



*  All the formatting tags (<p>, <h2>, <br/>), but not <a> tags are
stripped out of the Mission statement, as becomes apparent when I view
the page source.  
*  Only for anonymous users, a new set of links appear at the bottom of
the page :
"1 2 next › last »".
If I click, for example, "last" i see the default front page text
/node?page=1 underneath the non-formatted Mission statement.  Since I
have 2 nodes promoted to the front page, I thought /node?page=1 is
supposed to become inaccessible?


------------------------------------------------------------------------

Sun, 26 Mar 2006 15:46:56 +0000 : moshe weitzman

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'));




------------------------------------------------------------------------

Sun, 26 Mar 2006 18:19:32 +0000 : Steven

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.




------------------------------------------------------------------------

Sun, 26 Mar 2006 18:41:02 +0000 : pwolanin

Thank you!  That's easily put back to the previous version's code now
that I know where the cause lies.


Why was this filtering added?  I'd imagine most sites would want some
formatting in their mission statement.




------------------------------------------------------------------------

Thu, 06 Apr 2006 12:52:42 +0000 : leafish_paul

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.