ModSecurity

On 11/23/10 5:11 AM, "Nick Gearls" <nickgearls@...> wrote:

> Hello,
> 
> 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
> response:
>   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
response.

-Ryan

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"\
        "phase:3,t:none,nolog,deny,status:500"

You can replace "@pm 500" by "." for tests.

Nick

On 23/11/2010 15:29, Ryan Barnett wrote:
> On 11/23/10 5:11 AM, "Nick Gearls"<nickgearls@...>  wrote:
>
>> Hello,
>>
>> 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
>> response:
>>    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
> response.
>
> -Ryan
>
>
>