Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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?
Comment | File | Size | Author |
---|---|---|---|
#8 | filter.xss.admin.patch | 8.15 KB | Steven |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedyeah, 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'));
Comment #2
Steven CreditAttribution: Steven commentedThat 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.
Comment #3
pwolanin CreditAttribution: pwolanin commentedThank 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.
Comment #4
pfaocleThis 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.
Comment #5
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedYeah, people should collect such things for the upgrading guide and/or a release announcement.
Moving to docs.
Comment #6
green monkey CreditAttribution: green monkey commentedI 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
Comment #7
sepeck CreditAttribution: sepeck commentedSection 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.
Comment #8
Steven CreditAttribution: Steven commentedHere'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.
Comment #9
Steven CreditAttribution: Steven commentedComment #10
Steven CreditAttribution: Steven commentedCommitted 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.
Comment #11
(not verified) CreditAttribution: commented