RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
Apache webserver allows kind of "Content Spoofing" using default error pages.
Note that I am saying explicitly "kind of" here, because such an example has
been reported multiple times via HackerOne now, nevertheless it is not really
Content Spoofing IMHO; https://bz.apache.org/bugzilla/show_bug.cgi?id=59772
seems to agree with that.

Version-Release number of selected component (if applicable):
httpd-2.4.6-45.el7_3.4.x86_64

How reproducible and Steps to Reproduce:
- Install RHEL 7 (default or minimal installation)
- yum update -y  # apply all updates
- yum install httpd -y  # install httpd
- systemctl start httpd.service  # start httpd
- Visit http://<IP>/wp-content/cache/minify/%0D%0Ahas%20moved%20to%20www.example.net.%20Please%20visit%20example.net.%20The%20requested%20resource
- Result: Not Found
  The requested URL /wp-content/cache/minify/ has moved to www.example.net. 
  Please visit example.net. The requested resource was not found on this server.

Actual results:
Apache webserver allows kind of "Content Spoofing" using default error pages.

Expected results:
No "Content Spoofing" using default error pages at all, even not "kind of".

Cross-filed case 01835054 on the Red Hat customer portal.

Robert, thanks for the report.

I'm reluctant to change the defaults here.

a) Looking through the code, the URL is included in the default (hard-coded) response body for a wide variety of HTTP error responses. 

https://github.com/apache/httpd/blob/trunk/modules/http/http_protocol.c#L949

Depending on the config, it will be more or less trivial for users to get a response which includes the URL for other canned error responses too.  I don't want to patch all of that out and deviate from upstream behaviour unless we have good motivation.

b) It's actually useful to include this content in many of those errors; not doing so is really only playing to security theatre.

c) It's trivial to change the behaviour for 404 if you really do want this, a one liner:

   ErrorDocument 404 "404 Not Found" 

would suffice.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.