Problem/Motivation

The global "Text area" that can be added to footer, header or no-result areas is not meant to fully support twig. Background: https://www.drupal.org/node/2805173#comment-11814857. It does actually support twig when "Use replacement tokens from the first row" is checked and result count > 0. I would like full twig support. why using a powerfull language like twig only for replacing tokens? row "Custom text" fields explicitly support twig, why not header "text area" fields?

I'm curious for arguments why "Text area" supports twig conditionally, but is only designed to parse tokens?

Proposed resolution

  • Let the "Text area" always parse twig, or
  • Add a new "Custom area" that extends "Text area" class "TokenizeAreaPluginBase" and adds twig parsing.

The latter I build as a small custom module, can make a patch of that.

Remaining tasks

Comments

keesje created an issue. See original summary.

keesje’s picture

Issue summary: View changes
dawehner’s picture

I was running into this the other way as I was totally expecting that we support that.

andypost’s picture

Status: Active » Closed (works as designed)
Issue tags: +VDC, +Security
Related issues: +#2805173: importing a view with a text area containing Twig markup shows the raw Twig

@dawehner twig is for templates, we do not allow use twig engine for user input (security reasons, same as php filter that allows delete nodes)
So closing as related #2805173-10: importing a view with a text area containing Twig markup shows the raw Twig

andypost’s picture

Misunderstanding comes from ”twig syntax of tokens"
https://www.drupal.org/node/2404639
https://www.drupal.org/node/2566251

andypost’s picture

>>Major because closes potential data-loss vulnerabilities. Not critical because this requires admin-level permissions (access to Twig templates) to exploit this.

andypost’s picture

keesje’s picture

Hi @andypost, can you please explain why this (allow use twig engine on "text area") is a security threat and not on a "Custom text" field? thanks.

andypost’s picture

I think both are, because #2513266: Twig templates can call delete() on entities and other objects
So I think we should reconsider if "custom text" row allows to use twig

keesje’s picture

Thanks, I agree.
I didnt realise twig was that powerful, capable of deleting entities.
There are strong cases though for using code-like logic in a views header. views_php module popularity could be proof of that.

keesje’s picture

Reading the issue #2513266 tread you linked,
I get the impression that this security issue is fixed in current core release. Looking at the code, implementing class "TwigEnvironment" from the core "Drupal\Core\Template" namespace should be safe for user input?

silverham’s picture

Status: Closed (works as designed) » Active

Opening to get feedback on issue.

Chi’s picture

Version: 8.3.x-dev » 9.1.x-dev

Editing Twig templates by untrusted users will never be safe. That's because Drupal render arrays are too powerful. Aside from that third party Twig extensions can enable unrestricted functionality. Think of PHP filter in Twig Tweak. However, given that Twig is already allowed for other field types enabling it for textareas won't make the site less secure. For the purpose of consistency we should either enable it on all text fields in Views UI or remove it completely.

Chi’s picture

The better approach could be creatiing a separate Twig enviroment with strict sandbox policies and without support for render arrays. That could be usefull not only in Views UI but in many other places. For example in email templates.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.