Bug #104410: Create new content element - Forbidden (Error 403) on Apache 2.4.60+ - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #104410

closed

Create new content element - Forbidden (Error 403) on Apache 2.4.60+

Added by Eric Harrer 10 days ago. Updated 8 days ago.

Status:

Rejected

Priority:

Won't have this time

Assignee:

Category:

Backend User Interface

Target version:

Start date:

2024-07-17

Due date:

% Done:

Estimated time:

TYPO3 Version:

6.2

PHP Version:

Tags:

security, apache, error, 403, forbidden, CVE-2024-38474, UnsafeAllow3F

Complexity:

Is Regression:

Sprint Focus:

Description

When opening the New Content Element Wizard, the following error message appears:

Forbidden
You don't have permission to access this resource.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Since version 2.4.60, Apache has closed the security vulnerability https://www.cve.org/CVERecord?id=CVE-2024-38474 by no longer allowing encoded question marks in URLs. This leads to the problem described above. Similar problems have also been reported in the Contao community.

By setting the UnsafeAllow3F flag, the original behaviour of the server can be restored. However, there are already the first web hosting providers, especially in shared hosting, who understandably do not allow this. A current example is STRATO, which recently upgraded to Apache 2.4.61

For this reason, the question now arises as to whether this is an issue for TYPO3 core development or whether there is a possibility that Apache will provide another, less far-reaching, solution for the security vulnerability.

Actions

Copy link

Updated by Oliver Hader 10 days ago

I was not able to reproduce the behavior (HTTP 403 errors on URLs containing %3f, which is e.g. the case for the returnUrl parameter) with an Apache 2.4.61 local environment, using mod_fcgid.

Can you please provide details about the web hosting environment?
Are there any custom modifications to the .htaccess rules?

Actions

Copy link

Updated by Oliver Hader 10 days ago

Status changed from New to Needs Feedback

Actions

Copy link

Updated by Oliver Hader 10 days ago · Edited

For the records...¶

Based on our analysis of a web server environment under Apache 2.4.61, the operation of TYPO3 with regard to CVE-2024-38474 (https://www.cve.org/CVERecord?id=CVE-2024-38474) is not affected. The htaccess configuration provided by TYPO3 by default is not blocked by Apache, and the use of the new UnsafeAllow3F flag also appears unnecessary.

Actions

Copy link

Updated by Oliver Hader 10 days ago

Category changed from Link Handling, Site Handling & Routing to Backend User Interface

Actions

Copy link

Updated by Eric Harrer 10 days ago · Edited

Thanks for the feedback. Good to hear that it's not a general problem that could potentially affect other web hosting providers.

Unfortunately, I don't currently have STRATO web hosting myself, from which I could provide further insights. I just linked the topic that was discussed in the TYPO3 Community Hub, in the Contao Forum and on Slack and recorded it here to reach the core team.

If this is not a general problem, it will certainly be possible to close this "issue".

Actions

Copy link

Updated by Oliver Hader 10 days ago

Thanks for your feedback!

After clarifying this via Slack directly, it turned out that

the original error message was copy-pasted from https://community.contao.org/de/showthread.php?87114-Fehler-403-Forbidden-durch-Cookiebar-AH10508-Unsafe-URL-with-3f-URL-rewritten&p=586304&viewfull=1#post586304
other references stemmed from another forum thread at https://forum.t3academy.de/d/507-strato-create-content-forbidden-error-403-cve-2024-38474-unsafeallow3f/48

Actions

Copy link

Updated by Oliver Hader 10 days ago

Concerning Strato (https://www.strato.de/)¶

We (the TYPO3 Security Team) contacted the Strato Security Team today, asking for a clarification about their procedures (arbitrarily blocking any URL that contains %3f) and their misleading statements about "using insecure methods in Typo3" - which is of not the case.

We were able to reproduce the behavior on websites that are definitively not build with TYPO3 - the pure existence of %3f in the request URI was enough to get denied.

→ example https://filmscanner.info/%3f (resolves to 81.169.145.64, w00.rzone.de)

Actions

Copy link

Updated by Oliver Hader 10 days ago

Status changed from Needs Feedback to Rejected
Priority changed from Should have to Won't have this time

I'm closing this issue as it is related to an Apache vulnerability and very specific to one particular web hosting provider.

Please feel free to reopen this issue, in case the situation changes. Thanks!

Actions

Copy link

Updated by Franz Koch 10 days ago

since the report was only for v13: Has this also been tested by the security team with v12.4, or only v13? Or is a test with v12 not necessary since nothing changed in the backend logic of v13 in this regard?

And thanks for looking into it, much appreciated.

Actions

Copy link

#10