Bug #93343
closed
Accessing non-translated page with strict language breaks all menus
Added by Andreas Kienast over 3 years ago. Updated about 1 year ago.
0%
Description
- a site language in strict mode and with no fallback languages configured
- a page not translated into that language
Clear all caches in the backend and open the page with the L parameter attached, e.g. /customize?L=2. At this point, all menus are broken when opening the page /customize in another browser not logged in in the backend (mind the missing L parameter!).
Files
| xdebug-pagelinkbuilder.png (234 KB) xdebug-pagelinkbuilder.png | Andreas Kienast, 2021-01-22 08:30 | ||
| config.yaml (572 Bytes) config.yaml | Andreas Kienast, 2021-01-22 11:36 | ||
| 93343.patch (1.66 KB) 93343.patch | Patch v2 | Andreas Kienast, 2021-01-22 11:38 | |
| recording-l-param.mp4 (3.14 MB) recording-l-param.mp4 | Andreas Kienast, 2021-01-22 20:05 |
Updated by Andreas Kienast over 3 years ago
I just found that using a non-existent language id (e.g. L=9999999999) works as well
Updated by Andreas Kienast over 3 years ago
Updated by Andreas Kienast over 3 years ago
- Project changed from TYPO3 Core to 1716
Moved to "Core Security" as this might qualify as a DOS.
Updated by Oliver Hader over 3 years ago
Can you please add the relevant parts of your site configuration YAML to this ticket? Thx
Updated by Andreas Kienast over 3 years ago
- File config.yaml config.yaml added
I've added my whole site config (which is as minimalistic as possible). Locally, I can now access https://10.ddev.site/customize?L=99999999999 (with introduction package installed) which gets cached.
Updated by Oliver Hader over 3 years ago
Thx for sharing the configuration. Can you please describe (or add a screenshot) what "broken" means in this case. In my own tests, menu links now contain that (invalid) ?L=11111 parameter. It also only seems possible to use numeric values here, e.g. ?L=wordpress-spam did not work.
Update #1:
Checked again with the requirement "calling a non-translated page with invalid L-value". Now I see a couple of <a href="" class="dropdown-item"...> elements (empty href).
Update #2:
Dropping the filter from config.linkVars = L(int) allows arbitrary params. Not using config.linkVars at all, is fine here. Advise to use the filter is documented at https://docs.typo3.org/m/typo3/reference-typoscript/master/en-us/Setup/Config/Index.html#linkvars
→ I guess this is related to config.linkVars = L only and the link generation handling not checking valid L-parameters
Updated by Andreas Kienast over 3 years ago
- File recording-l-param.mp4 recording-l-param.mp4 added
I've added a short recording that demonstrates the issues based on the requirements to reproduce the issue. I hope this helps to understand the issue better.
Updated by Oliver Hader over 3 years ago
Looking at it from a security point of view, it seems to be "low" (2.8-3.5):
The only impact is on "availability", however the service (website) is still working, just anchor tags are empty. That's why I applied the corresponding sub-score modifier.
Updated by Andreas Kienast over 3 years ago
We face that issue on typo3.com, and in there the L parameter is kept in cache. If you watch my recording, you may notice that this is the case in there as well for some links ("Home" and menu subpages).
Updated by Torben Hansen over 3 years ago
I had this problem on a customer site last week too, which was migrated from 8.7 to 10.4.
Since the solution is to not include the L parameter in config.linkVars, is this still considered a security vulnerability or a misconfiguration issue?
Updated by Torben Hansen about 3 years ago
Updated by Torben Hansen about 3 years ago
- Related to Task #86054: Slug Handling does not add config.linkVars added
Updated by Oliver Hader about 3 years ago
- Category set to T3-04: Cache poisoning
- Status changed from New to Needs Feedback
- Target version set to public
- empty
hrefattribute → that's a bug, not security related, also no DoS scenario - injecting arbitrary payload that gets cached → cache poisoning (sure due to
linkVars, can be avoided by using filers in TypoScript)
Since TYPO3 v9 the L parameter has a specific meaning: it's related to a language (in sys_language) and has to be a positive integer value.
Prior to that, L was evaluated in TypoScript conditions and could have been and meant anything.
From my point of view it should be handled as a regular bug fix, not as a security vulnerability.
What do you think?
Updated by Torben Hansen about 3 years ago
I agree that this should be handled as a bugfix.
Updated by Oliver Hader over 2 years ago
- Project changed from 1716 to TYPO3 Core
- Category deleted (
T3-04: Cache poisoning) - Target version deleted (
public)
Updated by Denis Mir over 2 years ago
It is important to mention here that using "config.linkVars" does not fix the issue even when forcing the links vars via "config.linkVars" to be the correct ones.
Example:
Page URI: /de/test
Page URI called with empty cach to mess up the links: /de/test?L=3 (with 3 being another available language than german)
So it is possible to mess with the whole site links and get this invalid markup in the cache. And customers are getting targeted by bots calling these falsy URIs around midnight when the cache gets cleared. This breaks the pages. Only clearing the cache again is able to correct the issue.
Updated by Torben Hansen over 2 years ago
It is important to mention here that using "config.linkVars" does not fix the issue even when forcing the links vars via "config.linkVars" to be the correct ones.
What exactly do you mean with "correct ones"? A configuration like e.g. config.linkVars = L(0-3) would still lead to the problem, since the L parameter is included in config.linkVars.
Updated by Denis Mir over 2 years ago
config.linkVars = L(0-3) would still lead to the problem, since the L parameter is included in config.linkVars.
Yeah this is what I said setting the linkVars correctly does not help.
Updated by Denis Mir over 2 years ago
Do I understand it correctly that removing the "config.linkVars" for the L parameter is considered a solution? (so for 9LTS and up we should not use the "config.linkVars" for the L parameter at all?
Updated by Benni Mack about 1 year ago
- Status changed from Needs Feedback to Closed
Denis Mir wrote in #note-22:
Do I understand it correctly that removing the "config.linkVars" for the L parameter is considered a solution? (so for 9LTS and up we should not use the "config.linkVars" for the L parameter at all?
Removing config.linkVars = L should most definitively be removed! It is outdated and not needed anymore with Site Handling (at least for v10+)