Bug #94776

Bug #94787: Tracking issue related to HTML sanitization issues

Email Links with config.spamProtectEmailAddresses = 2 do not work after Update

Added by Lina Wolf 2 months ago. Updated 12 days ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Security
Target version:
-
Start date:
2021-08-11
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Yes
Sprint Focus:

Description

After Updating from 10.4.18 to 10.4.19, Using

config.spamProtectEmailAddresses = 2
config.spamProtectEmailAddresses_atSubst = (at)

Links to Emailadresses do not work correctly anymore. Before the following HTML was generated:

<a href="javascript:linkTo_UnCryptMailto(%27ocknvq%2CkphqBrtczku%5C%2Fmkghgt0fg%27);">info(at)example.com</a>

Now the HTML Output ist:

<a>info(at)example.com</a>

Therefore linking emailadresses does not work anymore.

In the source code of the RTE they are displayed like this:

<a href="mailto:info@example.com">info@example.com </a>

If I disable spamProtectEmailAddresses the emailadress is generated.


Subtasks

Bug #94823: sanitizeHtml disables email when config.spamProtectEmailAddresses is enabledClosed2021-08-11

Actions
Bug #94848: spamProtectEmailAddresses not working since TYPO3 10.4.19Closed2021-08-12

Actions
Bug #94885: Mailto Links missing hrefClosed2021-08-13

Actions

Related issues

Related to TYPO3 Core - Bug #94833: mailto-Links in RTE will not get rendered in frontendClosed2021-08-12

Actions
#1

Updated by Lina Wolf 2 months ago

  • Description updated (diff)
#2

Updated by Lina Wolf 2 months ago

  • Description updated (diff)
#3

Updated by Georg Ringer 2 months ago

  • Is Regression set to Yes
#5

Updated by Torben Hansen 2 months ago

TYPO3 HTML Sanitizer strips those href attributes for links. Created PR so href values starting with javascript:linkTo_UnCryptMailto are accepted: https://github.com/TYPO3/html-sanitizer/pull/15

#6

Updated by Oliver Hader 2 months ago

  • Status changed from New to Accepted
#7

Updated by Christian Toffolo 2 months ago

I add that I have configured:

spamProtectEmailAddresses = ascii

and the email address are not translated to a Unicode HTML notation.

#8

Updated by Oliver Hader 2 months ago

  • Parent task set to #94787
#9

Updated by Gerrit Code Review 2 months ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/70411

#10

Updated by Gerrit Code Review 2 months ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/70411

#11

Updated by Oliver Hader 2 months ago

Christian Toffolo wrote in #note-7:

I add that I have configured:
[...]
and the email address are not translated to a Unicode HTML notation.

Example:

<a href="&#109;&#97;&#105;&#108;&#116;&#111;&#58;&#115;&#111;&#109;&#101;&#46;&#98;&#111;&#100;&#121;&#64;&#116;&#101;&#115;&#116;&#46;&#116;&#121;&#112;&#111;&#51;&#46;&#111;&#114;&#103;">some.body(at)test.typo3(dot)org</a>

The underlying library we're using decodes HTML hex/numeric entities per default, which actually is a good thing for having normalized attribute values additional checks can be performed on.

https://github.com/Masterminds/html5-php/blob/2.7.5/src/HTML5/Parser/Tokenizer.php#L565-L588

I'm pretty much convinced that spam bots are looking either for mailto: AND &#109;&#97;&#105;&#108;&#116;&#111;&#58; (as the entity encoded pendant) to extract email addresses. DOM-based crawlers are resolving entities automatically (exactly like Masterminds/html5-php does).

Yes, it is a change in behavior - but I think, it is not worth fixing it, because it does not add any additional "protection". What do you think?

#12

Updated by Oliver Hader 2 months ago

  • Category set to Security
  • TYPO3 Version changed from 10 to 9
#13

Updated by Gerrit Code Review 2 months ago

Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/70414

#14

Updated by Gerrit Code Review 2 months ago

Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/70415

#15

Updated by Torben Hansen 2 months ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#16

Updated by Gerrit Code Review 2 months ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch 11.3 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/70416

#17

Updated by Sven Juergens 2 months ago

hi, one question. Unfortunately, some of our pages are affected by this bug, so I wanted to ask is a regression update of TYPO3 to be expected this week or later? If it should be later, I would start to patch the pages manually first. I would just like to avoid patching all the pages and then there is an update immediately afterwards :)

#18

Updated by Oliver Hader 2 months ago

Sven Juergens wrote in #note-17:

hi, one question. Unfortunately, some of our pages are affected by this bug, so I wanted to ask is a regression update of TYPO3 to be expected this week or later? If it should be later, I would start to patch the pages manually first. I would just like to avoid patching all the pages and then there is an update immediately afterwards :)

Please see parent issue #94787 to get an overview. I fear there will be more issues/reports during the next few hours/days. It's obvious there will be new release packages, however it is currently not defined when that shall happen.

It also is kind of a chicken-egg problem - people not upgrading, waiting for new releases and then finding new bugs in those new releases because they were not tested earlier...

#19

Updated by Gerrit Code Review 2 months ago

Patch set 2 for branch 11.3 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/70416

#20

Updated by Johannes Nielsen 2 months ago

I add that setting

config.spamProtectEmailAddresses_atSubst = &#64;
config.spamProtectEmailAddresses_lastDotSubst = &#46;

now has no effect anymore. We often do this as a compromise between good spam protection and usability as there are still quite many users that copy-paste the e-mail address rather than simply clicking the email-link.

#21

Updated by Oliver Hader 2 months ago

As mentioned above already, spamProtectEmailAddresses and especially ascii or any substitutions do not offer much protection.

Just as a side-note, CloudFlare is using something like this to obfuscate email addresses:
https://support.cloudflare.com/hc/en-us/articles/200170016-What-is-Email-Address-Obfuscation-

<a href="/cdn-cgi/l/email-protection#f59dc1969ec3c2c4c7c6c1b59dc1969ec687c6c4db9b9081" role="button" title="Mail"><i class="fa fa-envelope"></i><span class="__cf_email__" data-cfemail="462e72252d707177747572062e72252d7534757768282332">[email&#160;protected]</span></a>

#22

Updated by Torben Hansen 2 months ago

  • Status changed from Under Review to Resolved
#23

Updated by Christian Toffolo 2 months ago

I agree that spamProtectEmailAddresses=ascii does not offer the best protection, but in most cases it's enough. In my experience, many sites running for many years, the email addresses published usually are not affected by spammers.

Isn't possible to add a TYPO3 config option to disable the sanitizer for mailto: links?
And then, in DefaultSanitizerBuilder.php, code something like:

$isMailtoUri = new Behavior\RegExpAttrValue('#^mailto:#');
?

This is to give the site admin the possibility to choose.

#24

Updated by Oliver Hader 2 months ago

  • Status changed from Resolved to On Hold
#25

Updated by Oliver Hader 2 months ago

  • Status changed from On Hold to Resolved
#26

Updated by Georg Ringer 2 months ago

  • Related to Bug #94833: mailto-Links in RTE will not get rendered in frontend added
#27

Updated by Oliver Hader 2 months ago

  • Status changed from Resolved to On Hold
#28

Updated by Oliver Hader 2 months ago

  • Assignee set to Torben Hansen
#29

Updated by Oliver Hader 2 months ago

  • Status changed from On Hold to Resolved
#30

Updated by Benni Mack 12 days ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF