Bug #103129: Modified "Host" header with invalid port leads to exception when creating the ServerRequestFactory->fromGlobals - TYPO3 Core - TYPO3 Forge

Custom queries

12 LTS
Accessibility
Dashboard issues
Easy tasks
Extbase Issues
FAL Issues
FAL Sprint 2023
Hierarchical Issues
Issues reported for v11
JavaScript issues
JavaScript Issues (w/o Epics/Stories)
Most wanted Bugfixes
Most wanted Features
My open issues
New & Unassigned
No feedback within 90 days
Open Bugs
Open issues of 10
Page Tree Regressions after 2020-07-28
Recently modified
Regressions
Stabilization Issues
Usability or UX

Watchers (1)

Benni Mack

Actions

Copy link

Bug #103129

open

Modified "Host" header with invalid port leads to exception when creating the ServerRequestFactory->fromGlobals

Added by Johannes Schlier 3 months ago. Updated 23 days ago.

Status:

Under Review

Priority:

Should have

Assignee:

Stefan Bürk

Category:

Target version:

Start date:

2024-02-15

Due date:

% Done:

Estimated time:

TYPO3 Version:

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

When a request is passed to TYPO3 that has an invalid port within the "Host" header (e. g. a non-numeric port "aaa" or too many numerals "123123123") TYPO3 pretty quickly runs into an error and returns an exception, including an HTTP 500 error.
In my opinion it would be preferable to silently ignore those invalid settings and either continue the request normally, or at least return a clean error (400 - Bad Request).

The attached screenshots are the complete stack trace of such a request.
This was reproduced with TYPO3 12.4.10 and 12.4.11.

Files

Download all files

Screenshot 2024-02-15 at 12.39.31.png (603 KB) Screenshot 2024-02-15 at 12.39.31.png		Johannes Schlier, 2024-02-15 11:45
Screenshot 2024-02-15 at 12.39.11.png (601 KB) Screenshot 2024-02-15 at 12.39.11.png		Johannes Schlier, 2024-02-15 11:45

Related issues 1 (1 open — 0 closed)

Related to TYPO3 Core - Bug #98264: Logging "unsupported" HTTP request methods as an exception into the log is wrong

Under Review

2022-09-06

Actions

Issue # Delay: days Cancel

History
Notes
Property changes

Actions

Copy link

Updated by Benni Mack 3 months ago

Idea is to catch invalid argument exception in AbstractApplication->run (dev-main), and then deliver a 400 response with no content.

Actions

Copy link

Updated by Stefan Bürk 26 days ago

Status changed from New to Needs Feedback
Assignee set to Stefan Bürk

How did you managed to get this down to TYPO3 (or a PHP application). I cannot reproduce
this in anyway with differnt browsers or curl (cli) directly. neither with direct local
LAMP setups nor ddev (like it seems you are using) - neighter with APACHE2 or NGNIX ?!

Literally, a invalid port part in a URI should be handled

1) by the client
2) by the webserver

Usually, the webserver could not be reached with a invalid port as it should not be
listening on that port. So even if the client does not handle it, it should be handled
on the webserver level. If a Webserver catches this, maybe because of the `https` protocol
in the uri IT still must decline the request because of the invalid port part - or remove
it when passing further down (stripping it from request uri).

So I'm with you - it should be corrected or a 400 Bad Request thrown, but that is not the
task of the PHP application. There is something badly wrong before the application ever
should be reached with such a port.

Silenty handling it on the TYPO3 side would only hide the "server configuration" issue.

I'm really interessted how you could pass such a invalid uri down to TYPO3.

Beside that, I'm with benni that we can add a 400 Bad Request for that case in a early
state, but silently passing it down would open for a lot of other issues anyway. Will
have a look the next day for a implementation.

Can you provide more information how you could triggered that at all ? Operating System,
browser, ddev config etc. ?

Actions

Copy link

Updated by Gerrit Code Review 26 days ago

Status changed from Needs Feedback to Under Review

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

Actions

Copy link

Updated by Gerrit Code Review 26 days ago

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

Actions

Copy link

Updated by Gerrit Code Review 26 days ago

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

Actions

Copy link

Updated by Gerrit Code Review 26 days ago

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

Actions

Copy link

Updated by Gerrit Code Review 26 days ago

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

Actions

Copy link

Updated by Gerrit Code Review 26 days ago

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

Actions

Copy link

Updated by Stefan Bürk 25 days ago

Related to Bug #98264: Logging "unsupported" HTTP request methods as an exception into the log is wrong added

Actions

Copy link

#10

Updated by Stefan P 24 days ago

@Stefan Bürk PHP also provides a dedicated built-in webserver. Start it with "php -S". Then your PHP code must handle these cases.

Actions

Copy link

#11

Updated by Stefan Bürk 23 days ago · Edited

Stefan P wrote in #note-10:

@Stefan Bürk PHP also provides a dedicated built-in webserver. Start it with "php -S". Then your PHP code must handle these cases.

Sidenote: PHP -S is not an official supported webserver nor a production ready webserver. See https://www.php.net/manual/en/features.commandline.webserver.php

Warning: This web server is designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network.

Even with that information - php build-in webserver won't start with such an invalid port, and I still could not find a way or client to "reach" port 443 or 80 or any other valid port where a webserver is listening) and having a manipulated header with a wrong port in it. I search for a way to create such a malformed request.

The related issue was about a invalid HTTP method - which can be done, for example using curl. But for an invalid port ?

I created a change - but detected that another (WIP) change from 2022 is hanging around with a literlly better approach.
Reading through it, sub-requests are mentioned which make literally sense to mitigate issues there also. I pinged the
author and core mergers discussion it back then, and we will see how to proceed here. I already linked the other issue
and with that the other change.

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

TYPO3 Core

Custom queries

Watchers (1)

Bug #103129

Modified "Host" header with invalid port leads to exception when creating the ServerRequestFactory->fromGlobals

Updated by Benni Mack 3 months ago

Updated by Stefan Bürk 26 days ago

Updated by Gerrit Code Review 26 days ago

Updated by Gerrit Code Review 26 days ago

Updated by Gerrit Code Review 26 days ago

Updated by Gerrit Code Review 26 days ago

Updated by Gerrit Code Review 26 days ago

Updated by Gerrit Code Review 26 days ago

Updated by Stefan Bürk 25 days ago

Updated by Stefan P 24 days ago

Updated by Stefan Bürk 23 days ago · Edited