Whitespace, tabs and malformed authority values are still accepted by Uri::withHost()

[fasrm]

Summary

Despite the basic host validation introduced in #196 / #172, Uri::withHost() still accepts malformed and ambiguous host values containing:

• whitespace
• tabs
• malformed IPv6 authorities
• ambiguous multi-port authorities

These values propagate into:

• Request Host headers
• serialized HTTP requests
• trusted X-Forwarded-Host rewriting flows

This allows malformed Host headers such as:

Host: evil.com bad:8080
Host: evil.com<TAB>bad:8080
Host: example.com:80:90:8080
Host: [::1

to be generated by Diactoros request objects.

---

Affected Components

• Laminas\Diactoros\Uri::withHost()
• Laminas\Diactoros\Request
• Laminas\Diactoros\RequestTrait
• Laminas\Diactoros\ServerRequestFilter\FilterUsingXForwardedHeaders

---

Reproduction

Direct withHost() usage

<?php

require 'vendor/autoload.php';

use Laminas\Diactoros\Uri;

$hosts = [
    'evil.com bad',
    "evil.com\tbad",
    '[::1',
    'example.com:80:90',
];

foreach ($hosts as $host) {

    echo "====================\n";
    echo "HOST: " . json_encode($host) . "\n";

    try {

        $uri = (new Uri('http://example.com'))
            ->withHost($host);

        echo "RESULT = " . (string)$uri . "\n";

    } catch (Throwable $e) {

        echo "EXCEPTION = " . $e->getMessage() . "\n";
    }

    echo "\n";
}

Output:

HOST: "evil.com bad"
RESULT = http://evil.com bad

HOST: "evil.com\tbad"
RESULT = http://evil.com        bad

HOST: "[::1"
RESULT = http://[::1

HOST: "example.com:80:90"
RESULT = http://example.com:80:90

---

Host header propagation

<?php

require 'vendor/autoload.php';

use Laminas\Diactoros\Request;
use Laminas\Diactoros\Request\Serializer;
use Laminas\Diactoros\Uri;

$uri = (new Uri('http://127.0.0.1:8080'))
    ->withHost("evil.com\tbad");

$request = new Request($uri);

echo Serializer::toString($request);

Serialized request:

GET / HTTP/1.1
Host: evil.com    bad:8080

---

Trusted X-Forwarded-Host rewriting

<?php

require 'vendor/autoload.php';

use Laminas\Diactoros\ServerRequest;
use Laminas\Diactoros\ServerRequestFilter\FilterUsingXForwardedHeaders;
use Laminas\Diactoros\Uri;

$request = new ServerRequest(
    serverParams: [
        'REMOTE_ADDR' => '127.0.0.1',
    ],
    headers: [
        'X-Forwarded-Host' => "evil.com\tbad",
    ],
    uri: new Uri('http://original.local/')
);

$filter = FilterUsingXForwardedHeaders::trustAny();

$filtered = $filter($request);

echo $filtered->getHeaderLine('Host');

Output:

evil.com    bad

---

Expected Behavior

Uri::withHost() should reject malformed host values containing invalid whitespace, malformed authorities, or ambiguous host/port forms before they propagate into Host headers or serialized HTTP requests.

---

Notes

This appears related to the existing malformed URI handling discussions in:

• Uri::__toString() can yield malformed URIs #172
• Add basic host validation in Uri and add port validation to the Uri constructor #196

The issue does not appear to be limited to URI stringification; malformed host values can propagate into actual serialized HTTP messages and trusted forwarded-header rewriting flows.

[froschdesign]

@fasrm
Sorry for the very late response!

Would you be willing to create a few tests as a pull request to illustrate the problem, perhaps along with a solution?

[Xerkus]

PSR-7 UriInterface is fundamentally broken. Most valid urls actually in use by PSR-7 applications are decidedly not valid RFC 3986 URIs: IDN that is not punicoded is not valid, IRI (non-percent-encoded UTF characters outside of ASCII printable range) is not valid, what browsers following living WHATWG specification consider valid is not valid outside of overlapping subset.

Having PSR-7 UriInterface instance DOES NOT guarantee it is valid or safe. On top having a valid url for one context does not guarantee it is valid or safe elsewhere even within same application. This is a huge mess and it was an attack surface for a long time across applications and languages. Outside of the narrow happy path woods get dense dark and dangerous.

Encoded, decoded and normalized url variants (following which of the competing specifications?) are not supported nor considered by PSR-7 and support is not possible within the existing interface. None of those operations are allowed to be applied more than once.

Fun fact:

laminas-diactoros/src/Uri.php

Line 410 in 23c526b

$parts = parse_url($uri);

parse_url() does not follow any specifications.
The more I looked into this in the past the more horrified by the discoveries I was.

Local fix is to ignore PSR-7 UriInterface definition as impossible to achieve and implement #219 with WHATWG version to follow the actual usage. It does not solve the fundamental issue for the PSR-7 consumer since PSR-7 is explicitly defined for decoupling contract and implementation. Re-parsing and validation must still happen where UriInterface is consumed.

Proper fix is to establish a working group with FIG, work on a new specification to obsolete PSR-7, then advocate and push its adoption and then push for uniform implementation across the entire ecosystem. This is a massive undertaking to say the least. I am not willing to take it.

[fasrm]

Thanks for the response and for taking a deeper look into this.

I completely agree that the issue goes beyond a simple malformed URI edge case and touches broader PSR-7 / URI normalization ambiguities, especially around differing RFC3986, WHATWG and real-world parser behaviors.

My main concern here was less about URI stringification itself and more about unsafe propagation into downstream trust boundaries, including:

• Host header generation
• serialized HTTP requests
• trusted forwarded-header rewriting flows
• potential parser differentials between components

I also agree that a PSR-7 UriInterface instance alone should not necessarily be treated as inherently “safe” or canonical.

That said, I still think rejecting clearly malformed authority forms (whitespace, tabs, malformed IPv6, ambiguous multi-port authorities, etc.) at the Diactoros boundary would reduce ambiguity and help prevent unsafe propagation into consuming layers.

I’d be happy to put together a PR with focused tests reproducing the current behavior, and potentially propose stricter validation handling for obviously malformed host values.

I’ll spend a bit more time exploring the edge cases and then open a PR with reproducible tests and a proposed approach.

Thanks again for the discussion — this is a really interesting area.

[froschdesign]

#219 looks like a good idea and solution to me.