[Mod-security-developers] [JIRA] Resolved: (MODSEC-183) Denying on RESPONSE_STATUS != 200 leads to broken error page

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-183.
--------------------------------------

    Resolution: Cannot Reproduce

> Denying on RESPONSE_STATUS != 200 leads to broken error page
> ------------------------------------------------------------
>
>                 Key: MODSEC-183
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-183
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.12
>         Environment: RHEL 5.3, Apache 2.2.16, mod_security 2.5.12, mod_fcgid 2.3.6
>            Reporter: Edgar Frank
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.4
>
>
> Denying a request (e.g. r->status == 500) in phase 3 with RESPONSE_STATUS and status:403 leads to a broken error page. (you want this setup to disguise application specific error behaviour)
> When mod_security denies such a request, it sends an error bucket with e.g. code 403 down the output filter chain, leaving r->status as is (e.g. 500).
> Finally, ap_die kicks in and tries to generate an error page. As r->status is != HTTP_OK (200) and ap_die is called with an error code, it regards this as a recursive error, thus disabling a custom error page and choosing the builtin one. (some thing like "an error occured, additionally a 403 occured while trying to handle the ErrorDocument"). See ap_die in http_protocol.c in modules/http of httpd.
> First, you have no chance to present a custom error page. It will always look awkward, if a customer sees such a site.
> Second, this presents a possible information disclosure and defeating the purpose of what you wanted to set up. Because of this point, I chose to set the severity to major.
> I understand that ap_die is designed to work with internal redirects and we're in an unfortunate situation, as we're already in the output filter chain. But on the other hand, as ap_die is effectively called with the information mod_security provided, mod_security should cope with its API.
> My naive first approach would be to set r->status to 200 in send_error_bucket, but I can't judge the side effects of this.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira