Possible Issue with URL Normalizer and Urls containing newline character

Has anyone else run into this issue?

Potentially malicious person tries to pull up a page on a website with /%0A appended to a valid URL (with or without additional valid characters after the newline character)

Without the UrlNormalizer configured on the UrlManager, this call results in the expected ‘Page Not Found’ error.

With the UrlNormalized configured, it’s somehow including the newline when it attempts to redirect the page to the normalized location:

Has anyone else run into this issue?

UrlManager is configured as:

		'enablePrettyUrl'     => true,
		'showScriptName'      => false,
		'enableStrictParsing' => false,
		'suffix'              => '/',
		'normalizer'          => [
			'class'  => 'yii\web\UrlNormalizer',
			'action' => \yii\web\UrlNormalizer::ACTION_REDIRECT_TEMPORARY,
			// use temporary redirection instead of permanent

Note, this happens whether I have the action param of the normalizer declared or not.

I assume this is from people trying to use the php-fpm vulnerability to try to exploit the server. They’re not getting far, but it’s alarming that the headers are actually trying to send on that newline?

Should be noted: changing the action to ACTION_NOT_FOUND works as expected displaying the 404 page (but negates the normalization benefit)

Except this server error being triggered there is nothing to worry about. PHP is safe from header splitting since 5.1.2.
If you want to get rid of that problem you could use Normalizer’s action parameter with custom callback to strip new line characters (and maybe carriage return as well).


Yeah, I ended up putting in a call that will strip the PHP_EOL character out of the normalized pathInfo. Just found it very strange that that wasn’t sanitized by default.

Don’t think anyone was getting anywhere with their attempts, but it was certainly filling up my error logs.

1 Like