RewriteRule started returning 403 Forbidden error

Question

I have a website that uses a set of quite simple RewriteRules of the format:

RewriteRule ^p/(.*)$ /product.php?$1 [L]

All was working well and still is working perfectly fine on localhost. For some reason, without me making any changes, those pages have started returning a 403 Forbidden error.

The problem seems to be spaces (encoded as %20) in the url query string. Looking in the logs shows this error

[rewrite:error] [pid xxxx:tid xxxxxxxxxxxxxx] [client xxx.xxx.xxx.xx:xxxxx] AH10411: Rewritten query string contains control characters or spaces

Sure enough, example.com/p/parameter%20name=value gives a 403 whereas example.com/p/parameterName=value doesn't.

Just adding spaces to a query string on a page that has a rewrite rule that doesn't use the query string doesn't cause an error. e.g. the rule RewriteRule ^contact-us/$ /contact.php [L] doesn't have a problem with the url example.com/contact-us/?query%20string=value

I'm aware that using + instead of %20 is a possibility or not using spaces at all. Both are not very practical options at the moment and using %20 was perfectly fine until about a day ago.

I can't see any permissions issues anywhere either.

Has anyone else come across this issue?

UPDATE:

As Mr White points out in his answer, the trick here is to make sure the B flag is set on the Rewrite rules in htaccess.

Because I am accessing the full query string using $_SERVER['QUERY_STRING'] I then needed to use urldecode as well.

This then returns the same output that I used to get before the Apache update.

Answer 1

For some reason, without me making any changes, those pages have started returning a 403 Forbidden error.

It's likely the version of Apache has been updated on your server.

I answered a similar question on StackOverflow just yesterday. This would seem to be a bug (IMO) in a recent version of Apache (2.4.56-1 / 2.4.52-1 ?), although this has also been cited as a "security fix" in the other answer on that question.

The "solution" is to use the B (escape backreferences) flag on your rule, to URL encode the (unencoded) backreference before it is used in the substitution string. For example:

RewriteRule ^p/(.*)$ /product.php?$1 [B,L]

(Presumably this URL-encodes the space as +, as opposed to %20 - which is what "normally" happens.)

Arguably, you should perhaps be using the B flag anyway here, although this depends on what other "special" characters you are expecting. eg. Without the B flag, a request of the form /p/param=v&lue would not be rewritten correctly since the & would not be URL encoded and the parameter value in the query string would effectively be broken.

However, you shouldn't need to use the B flag if all you are expecting is spaces. mod_rewrite (should) automatically URL encode an "invalid" substitution string. In this case the space should be URL encoded as %20 - which is perfectly valid, but now breaks with an error. In fact, it has been reported that even manually rewriting to %20 in the query string also breaks with this error. For example:

# Now breaks with error "AH10411: Rewritten query string contains control characters or spaces"
RewriteRule ^foo$ bar?q=one%20two [L]

The above is not invalid, but is now deemed to be.

(DISCLAIMER: I've not been able to test this myself yet.)

I'm not sure exactly what this "security fix" is meant to resolve (if indeed it is intentional), but it is certainly a breaking change that is affecting many sites. It also now invalidates several examples in the official Apache docs, which makes me think this is more of a "bug" than a "fix".

Reference:

• https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_b
• https://stackoverflow.com/questions/75684314/ah10411-error-managing-spaces-and-20-in-apache-mod-rewrite