Actually, sometimes, when you trap an error to generate another one (see
example below), you get an empty page (no body at all).
It could depend on the order of the filters ...
ex: SecRule RESPONSE_STATUS "@pm 500"\
You can replace "@pm 500" by "." for tests.
On 23/11/2010 15:29, Ryan Barnett wrote:
> On 11/23/10 5:11 AM, "Nick Gearls"<nickgearls@...> wrote:
>> Could you describe the expected behaviour of a blocking rule changing
>> the status of the response?
>> By "expected" behaviour, I mean the existing one but also the future
>> one, as it was not described anywhere, so it could be implementation
>> dependant and change in the future.
>> If you are in reverse proxy mode or direct mode, what happens to the
>> 1. is the status changed? Obviously not in phases 4/5
> Actually, you can still intercept the response and trigger a new status code
> in phase:4. ModSecurity is not sending the response data back in separate
> sections (Response Headers/Response Body), so the response headers are not
> already sent to the client after phase:3.
> Remember that ModSecurity is buffering/copying the *entire* response data
> into memory and doing inspection there. It is holding the response until
> ModSecurity phase:4 ends and then it is sending the existing/updated
> response to the client.
>> 2. is the original body sent or the default Apache message or nothing?
> When ModSecurity intercepts the response, it will use whatever local Apache
> error page is defined for the status code. This can be overridded though by
> using ErrorDocument directives in Apache to send whatever response body data
> you want.
> I think for your question though - the answer is no, the original response
> body data is not sent.
>> 3. in case Apache error message is displayed, is it only the built-in
>> one, or also custom pages (maybe with language variants)?
> As stated above, if you use ErrorDocuments, then you can customize the
> response body data page.
>> 4. is there any possibility of "loop" (blocking in different phases)?
> Not sure what you mean here? Can you please re-explain?
>> These questions are very important if you want, for instance, to hide
>> back-end error messages and display Apache error message instead.
> This is the exact intent of the outbound blocking rules in the CRS.
> Identify error/info leakages and then stop it and send a more generic error