Block Layout & Place Block pages are unsafe due to XSS vulnerabilities in title and category fields

Created on 4 April 2024, 8 months ago
Updated 5 April 2024, 8 months ago

Problem/Motivation

This was originally reported as a security issue but was cleared by the security team to be fixed in public

There is a block module issue in Place Block page (/admin/structure/block/library/umami)
Block definition label and category is not being sanitized before rendering.

Steps to reproduce

1. Install Umami site
2. Create a custom block plugin whose attributes looks like:

#[Block(
  id: "test_xss_title",
  admin_label: new TranslatableMarkup("<script>alert('XSS subject');</script>"),
  category: new TranslatableMarkup("<script>alert('XSS category');</script>"),
)]

3. Clear cache
4. Visit the "Place Block" page /admin/structure/block/library/umami
5. Confirm that block title and category are not properly escaped and the alert modals are triggered
6. Place a block instance of the test_xss_title block plugin in any of the regions
7. Visit the "Block Layout" page (/admin/structure/block)
5. Confirm that new block category is not properly escaped and the alert modal is triggered

Proposed resolution

Sanitize the category and label

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
BlockΒ  β†’

Last updated 1 day ago

Created by

πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @larowlan
  • πŸ‡ͺπŸ‡ΈSpain plopesc Valladolid
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10
  • πŸ‡ͺπŸ‡ΈSpain plopesc Valladolid
  • Pipeline finished with Failed
    8 months ago
    Total: 169s
    #138325
  • Pipeline finished with Failed
    8 months ago
    Total: 1727s
    #138328
  • Status changed to Needs work 8 months ago
  • πŸ‡ͺπŸ‡ΈSpain plopesc Valladolid

    Created a initial patch for this that solves the initial issue, but could escape strings twice, like in the failing test.

    Tests fails because views provided blocks have the following admin_label:

    $admin_label = new TranslatableMarkup('@view: @display', ['@view' => $view->label(), '@display' => $display->display['display_title']]);
    

    That means that malicious values in the view or display names are already escaped in advance.
    However, an admin_label where the malicious part is not in a token, like the one below, should be escaped:

    new TranslatableMarkup("<script>alert('XSS subject');</script>")
    

    As far as I know, we don't have a reliable way to determine whether a string has been already escaped to determine if a second escape is necessary or not.

    In the current scenario, I'm not sure whether it's better to allow XSS unsafe strings, or have double escaped ones for views. Any of the scenarios is unlikely to happen.

    If someone has a better approach to solve this situation, any advice is much appreciated.

Production build 0.71.5 2024