Does Craft Have a URL Rewrite Vulnerability?

Question

We could use some help tracking down a consistent error on our Craft installs according to Acunetix Security Audits.

URL Rewrite Vulnerability

It was identified that this application supports the legacy headers X-Original-URL and/or X-Rewrite-URL.

Support for these headers lets users override the path in the request URL via the X-Original-URL or X-Rewrite-URL HTTP request header and allows a user to access one URL but have web application return a different one which can bypass restrictions on higher level caches and web servers.

Many web frameworks such as Symfony 2.7.0 to 2.7.48, 2.8.0 to 2.8.43, 3.3.0 to 3.3.17, 3.4.0 to 3.4.13, 4.0.0 to 4.0.13 and 4.1.0 to 4.1.2 , zend-diactoros up to 1.8.4, zend-http up to 2.8.1, zend-feed up to 2.10.3 are affected by this security issue.

https://symfony.com/blog/cve-2018-14773-remove-support-for-legacy-and-risky-http-headers

https://framework.zend.com/security/advisory/ZF2018-01

• These sites are hosted on Forge / Linode servers.

• Versions vary, but most are recent-ish Craft 2.X

• A couple (though not all) use the Redirect Manager plugin

Answer 1

Both Yii 1 and Yii 2 will check for the X-Rewrite-URL header when determining the requested URI, however no known vulnerabilities exist related to that, because Craft is sure to use the same URI (whatever its source) for both routing and any other URI-related logic throughout the system. So it’s not possible to have Craft base its routing on one URI and template logic off of another URI, for example.

Answer 2

Maybe.

Here's what Acunetix has to say about it.

The test checks if a web application supports headers X-Original-URL or X-Rewrite-URL.

In this case, Craft CMS supports X-Rewrite-URL. Support of these headers is not a vulnerability itself, but more like misconfiguration which in some circumstances could lead to a vulnerability.

For example, if there is a reverse proxy(e.g Nginx) in from of Craft CMS and an administrator wants to restrict access to /admin/, s/he can set a deny rule on the proxy for location /admin/.

location /admin/ { deny all; return 403; }

However an attacker is still able to access the admin interface as Nginx knows nothing about X-Rewrite-URL. So the attacker just sends a request like this:

GET /something HTTP/1.1 Host: anything.com X-Rewrite-URL: /admin/login

A similar problem could be if a website is located behind a cache proxy. In this case, an attacker may exploit the cache poisoning attack which leads to XSS. It's a more complicated one. More information could be found here: https://portswigger.net/blog/practical-web-cache-poisoning

Therefore, the support of these headers (X-Original-URL or X-Rewrite-UR) doesn't lead to vulnerabilities of the site anything.com (at least, from the first glance), but it would be much safer for all user of Craft CMS if Craft CMS will make a fix (remove the support of these headers).