1

Since the release of the security patches in August 2021 that prevents Cross-Site Scripting via Rich-Text Content I noticed that the output of HTML Content Elements suddenly changed in our projects. Some tag attributes and tags got removed by the newly introduced HTML Sanitizer (when the template is modified so that t3:// style TypoLinks get rendered).

So simply overriding the default Html.html Fluid Template, changing the <f:format.raw> to <f:format.html> and adding a html decoding like in the following example is no longer sufficient.

<f:section name="Main">
    <f:comment> We use this to render links and other stuff in html elements </f:comment>
    <f:format.htmlentitiesDecode>
        <f:format.html parseFuncTSPath="lib.parseFunc">
            {data.bodytext}
        </f:format.html>
    </f:format.htmlentitiesDecode>
</f:section>

The easiest way to prevent changes in your html codes output provided by HTML Content Elements is to disable the sanitizer globally by adding lib.parseFunc.htmlSanitize = 0 to your TypoScript config, what is not ideal.

How can I disable the parseFunc.htmlSanitize only for this purpose?

Or is there an other solution to render TypoLinks within HTML Content Elements?

Note: You don't need to disable the HTML Sanitizer if you do not override the Html.html template!

Ludwig
  • 3,580
  • 2
  • 20
  • 24
  • Don't have a solution yet but maybe checkout https://forge.typo3.org/issues/95158 which proposes a new VH to just render links but leave all the other HTML untouched/unparsed – Georg Ringer Sep 09 '21 at 19:30
  • In order to copy a TypoScript block, please use `lib.parseHtmlFunc < lib.parseFunc` - thus using operator `<` instead of `=` (for scalar assignments) – Oliver Hader Sep 10 '21 at 08:35
  • @OliverHader Oh, stupid me. Thanks for pointing this out, it did the trick. I started using a reference with `=<` like described in https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.5.x/Important-94484-IntroduceHTMLSanitizer.html#stdwrap-parsefunc what did not do it's job and then ended up in this faulty TypoScript. I will add the answer by myself below. Thanks. – Ludwig Sep 10 '21 at 19:17
  • @GeorgRinger The idea with a new ViewHelper that handles `t3://` TypoLinks only would be great, more reliable and would reduce complexity by simply using `{data.bodytext}` in the template. – Ludwig Sep 10 '21 at 19:39
  • 2
    @Ludwig Here we go `` https://review.typo3.org/c/Packages/TYPO3.CMS/+/70977 – Oliver Hader Sep 10 '21 at 19:49
  • 1
    @OliverHader That's nice. Maybe it would be more straight forward to have a checkbox in the html content element's form to switch on or off the link rendering. Maybe with an option to set the default by a typo constant globally. I can't remember any project where I used html elements without enabling the rendering of links. And since we have fluid styled contents the complexity of enabling this is increasing more and more. I would welcome an easy solution that could be handled by an experienced editor without overwriting templates. – Ludwig Sep 14 '21 at 17:07
  • @Ludwig @OliverHader Is there a solution like you mentioned @Ludwig where I can enable `t3` links in html content elements site-wide without entirely turning off any html sanitization? Would I really have to override the default html content element to do this? – god_is_love Jun 11 '22 at 00:12
  • @god_is_love Not as far as I know. But maybe OliverHader has more details. – Ludwig Jun 13 '22 at 08:44

1 Answers1

0

Simply make a copy of lib.parseFunc and disable the sanitizer in this copy.

lib.parseHtmlFunc < lib.parseFunc
lib.parseHtmlFunc.htmlSanitize = 0

Then use this lib in your Html.html template.

<f:section name="Main">
    <f:comment> We use this to render links and other stuff in html elements </f:comment>
    <f:format.htmlentitiesDecode>
        <f:format.html parseFuncTSPath="lib.parseHtmlFunc">
            {data.bodytext}
        </f:format.html>
    </f:format.htmlentitiesDecode>
</f:section>

Thanks to @OliverHader for bringing me to the right track.

Ludwig
  • 3,580
  • 2
  • 20
  • 24
  • 2
    Mhm... this is not a good "solution" since `f:format.htmlentitiesDecode` decodes HTML and re-introduces potential XSS again. Either use `f:format.html` ("all" version") or `f:transform.html` (v11+) for that particular `t3://` URI topic. – Oliver Hader Jun 16 '22 at 10:25