Issues while using error_page and location

[zimmerle]

According to the original report (Ehsan Mahdavi) the audit logs are not working for custom error pages (using: error_page or location). In that scenario the logs are not written.

Ehsan Mahdavi also said that in case of SecRuleEngine is set to DetectionOnly everything works like expected.

[intelbg]

Hello, is there a plan to be fixed? The issue still exists and it's very serious. Also, audit_logging now works without the custom 403 page only in serial mode, not in concurrent. Thank you in advance. I think fixing this will solve many other issues and will help many people like me.

[intelbg]

In addition, the problem with concurrent logging was my mistake. It works. Remains the problem with custom 403 page only.

[intelbg]

If you don't plan to fix it can you please tell me which file and function is related to this problem ?

[victorhora]

@averges @intelbg

Have you tried enabling the intercept_errors directives (e.g. proxy_intercept_errors) directive in Nginx?

[intelbg]

hi @victorhora! Thanks about the reply. I tried - in server block and in location. but didn't help. Logging didn't work with it too with custom 403 page.

[averges]

@victorhora, yes, I've tried with intercept_errors directives but no luck.

Thank you for looking into this error.

[cauealvesbraz]

@zimmerle Here too

It's enabled the proxy_intercept_errors and returns the same problem.

[cauealvesbraz]

Maybe, have some problem in this code: https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_module.c#L164-L186

I'm trying to understand it

[intelbg]

@ceasbz I think that the problem is in this chunk of code too, but I a can't understand and fix it. If you do it please share the fix. I will appreciate it!

[zimmerle]

Hi,

Notice the configurations [1] and [2]. They are different by the error_block location.

In [1] the error was specified inside the location block. In that case the ModSecurity rules specified for the location block will be also applied to the error. That is different from [2] where we have no ModSecurity rules configured for the error block.

In my tests, having the configuration in the right place, I managed to have ModSecurity working as expected. I am closing the bug assuming that it was a configuration issue. If you think otherwise, please re-open.

[rm3nchaca]

Hi!
I've tested the 2 example configs, the 1 is not showing the custom error page but is logging as expected, the 2 displays the custom error page but is not logging.

[AirisX]

Hi @rm3nchaca,

Try to consider suggestions in this thread #76

[intelbg]

Hello @AirisX! I replaced the files with yours and recompiled nginx with the new modsecurity-nginx files. Logging seems to work, but uid parameter is no more logged in the audit log. UID parameter is a uid cookie set in nginx with userid module like follows:

userid on;
userid_name uid;
userid_expires 1s;
userid_path /;
Then when you are blocked on the page it's shown:
403 Forbidden by TU2Xb1qNgCOsXwgwAwMDAg==

And this should be logged in audit logs too as it was before your patch. Can you please give me an advice how to proceed?

[AirisX]

Hello @intelbg,

Could you provide your config? Please, also show an example of the audit log entries before and after patch.

[intelbg]

@AirisX Thank you about your reply!
Here is the config file, the log file now and screenshot of log file before the patch where there is a line cookie with the uid value. Do you think that this is related to the patch? If you prefer I can write you on a private message/email.

config.txt
log_after_patch.txt

[AirisX]

Hello @intelbg,

Could you clarify, do you mean uid cookie in the request header? As I can see from you screenshot of the log file, you are talking about request header. In this case this may be due to the parameter userid_expires which sets the expiration time to 1s and the next client request after this time may not contain this cookie. Therefore, if you make 2 (or more) requests per second the second and subsequent audit entries will contain the uid cookie.

[intelbg]

@AirisX you are right! But no matter what value it's set in some moment there is a point that no uid cookie is logged and I can't understand why. In the time of expiration it should provide and log immediately a different cookie, right?

[AirisX]

@intelbg Yes, while the uid cookie is not expired, it should be logged. Try to increase the userid_expires value to 1 hour, to exclude other reasons.

[intelbg]

@AirisX even with 1 hour settings for expiration, the first request for example does not log the uid cookie. With the second and third there is no problem (I attached the log).
auditlog.txt
Also, if it's with big expiration time one uid cookie will match / parse more than one matched/blocked rule as I want to have separate uid cookie value for every different block hit. How can achive it? Is it possible and why in case of expiration it's not logged as it should immediately assign another uid cookie hash. Sorry it it's already out of the topic but technically I really can't understand this and need solution.

[AirisX]

@intelbg of course, the first request doesn't contain the uid cookie, since for achieve this it must be set by the first Set-Cookie server response header. How else the client software must to know about this cookie!?
I wrote about it earlier in comment #55 (comment):

Therefore, if you make 2 (or more) requests per second the second and subsequent audit entries will contain the uid cookie.