Apache httpd does not execute ErrorDocument directive if response code is changed during phase 4 #2849
Description
Describe the bug
When response code is changed during phase 4 and the original response code is other than 200, Apache httpd does not execute ErrorDocument directive and bad response is generated.
Logs and dumps
Output of:
- DebugLogs (level 9)
- AuditLogs
- Error logs
To Reproduce
- Add following configuration:
ProxyPass /helloworld http://localhost:9090/unavaible ErrorDocument 403 /custompage.html SecRule RESPONSE_PROTOCOL "@contains HTTP" "id:'4',phase:4,auditlog,log,deny,status:403,msg:'yay!'" - Create and place custompage.html page to server root.
- execute
$ curl -v localhost/helloworld
Actual behavior
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access this resource.</p> <p>Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.</p> </body></html> Expected behavior
Proper rewritten response with custom error document:
Server (please complete the following information):
- ModSecurity version (and connector): mod_security-2.9.6
- WebServer: httpd-2.4.37
- OS (and distro): Linux Fedora
Rule Set (please complete the following information):
- Running any public or commercial rule set? No
Additional context
In my opinion, this is caused by apache httpds assumption that changed status of request which got through filter is a recursive error which occured during handling of previous errors.
See ap_die_r function in http module of apache, particularly this part of code:
/* * The following takes care of Apache redirects to custom response URLs * Note that if we are already dealing with the response to some other * error condition, we just report on the original error, and give up on * any attempt to handle the other thing "intelligently"... */ if (recursive_error != HTTP_OK) { while (r_1st_err->prev && (r_1st_err->prev->status != HTTP_OK)) r_1st_err = r_1st_err->prev; /* Get back to original error */ if (r_1st_err != r) { /* The recursive error was caused by an ErrorDocument specifying * an internal redirect to a bad URI. ap_internal_redirect has * changed the filter chains to point to the ErrorDocument's * request_rec. Back out those changes so we can safely use the * original failing request_rec to send the canned error message. * * ap_send_error_response gets rid of existing resource filters * on the output side, so we can skip those. */ update_r_in_filters(r_1st_err->proto_output_filters, r, r_1st_err); update_r_in_filters(r_1st_err->input_filters, r, r_1st_err); } custom_response = NULL; /* Do NOT retry the custom thing! */ } else { int error_index = ap_index_of_response(type); custom_response = ap_response_code_string(r, error_index); recursive_error = 0; } Clearing the original response code with f->r->status = 200; in send_error_bucket function appears to fix this issue.
This issue is a continuation of #533 and extends findings of Marc Stern in #533 (comment)