Text trimmed by "Trimmed" or "Summary or trimmed" field formatters will get run through Xss::filter() potentially changing their content

Created on 10 November 2017, over 6 years ago
Updated 4 March 2024, 3 months ago

Problem/Motivation

Steps to reproduce:

  1. Install Drupal from 11.x HEAD with the Standard profile
  2. Select the Full HTML format when creating the following Article nodes as it doesn't filter by "Limit allowed HTML". The use case are dangerous things like iframes or script tags or inline styles. Not advisable, but there is a use case for it for admin users.
  3. Create an "Article" node with <div style="color: red">red text</div> followed by less than 600 characters of text
  4. Create an "Article" node with <div style="color: red">red text</div> followed by more than 600 characters of text
  5. On the node view page for both nodes, the text at the top will be red -- this is expected, because the text filter allows it
  6. Go to the front page - you'll see that one node (the one with less than 600 characters) shows the text in red, but the other (the one with greater than 600 characters) does not

The problem is, when the "Summary or trimmed" or "Trimmed" field formatters do their thing, they first apply the text filter and then text_summary() will either return the same value (if no trimming is necessary) which is already marked as "safe" or will return a trimmed value, which is just a plain string (and so not marked as safe).

Then in \Drupal\Core\Render\Renderer->ensureMarkupIsSafe(), if it's a plain string (and so not marked as safe) it'll additionally run Xss::filter() on the output, which will remove stuff, even if it's allowed by the text format!

Proposed resolution

If filtered markup is passed to the `#pre_render` callback, that summarizes the text, return filtered markup instead of a plain string.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

📌 Task
Status

Needs work

Version

11.0 🔥

Component
Text 

Last updated 9 days ago

Created by

🇺🇸United States dsnopek USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • I've extended the patch ( interdiff_9_19 ) by a safety check to ensure only markup, that is already passed as filtered, is back-casted from string. I'm not sure if the taken approach is sufficient.

  • Pipeline finished with Success
    5 months ago
    Total: 595s
    #82913
  • As the ensureMarkupIsSafe renderer method the treats MarkupInterface as safe and TextTrimmedFormatter::preRenderSummary is a public static method and therefore may be called within a different context by contrib/custom modules (e.g. a render element that doesn't preserve the #pre_render callback preRenderText) iv'e tried to find a more generic implementation but as MarkupInterface doesn't dictate the `::create` method i couldn't find a practical approach.

    As test coverage is needed anyway i hope to have some time in the next days and extend an existing ones or add a new one if necessary.

  • Pipeline finished with Failed
    4 months ago
    Total: 171s
    #89048
  • Pipeline finished with Success
    4 months ago
    Total: 524s
    #90711
  • 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺

    Minor remarks, looking good :)

  • Pipeline finished with Success
    4 months ago
    Total: 505s
    #101805
  • Status changed to Needs review 4 months ago
  • As the implemented solution has been approved during review, i belief the proposed solution and remaining task can be updated in the issue summary. Back to review.

  • 🇺🇸United States smustgrave

    Going to find out if this falls under BC policy as this could change the display on existing sites which might not be desired.

  • Pipeline finished with Success
    4 months ago
    Total: 502s
    #104211
  • Status changed to Needs work 4 months ago
  • 🇺🇸United States smustgrave

    Brought this up in slack #needs-review-queue-initative https://drupal.slack.com/archives/C04CHUX484T/p1708719216555289

    I asked if this would be a D11 fix only because of the backwards compatibility impact and @catch replied "It wouldn't make it 11.x only but we might have to put it behind a settings.php switch or feature flag"

    So maybe a field formatter setting could cover it? Know smart trim has something like that.

  • Thanks for taking care of BC.

    I think the required change depends on issue classification.
    In my eyes this is a bug fix, not a feature request, because as a user (i.e. site builder) i don't expect that my hard-coded markup is filtered out when summarized.

    Since the activity (and probably demand) for a fix seems not very high why not make it 11.x only?

Production build 0.69.0 2024