zimmerle
commented
5 years ago Hi @ledzepp4eva,
Thank you for detailed your report. The reason for that is the fact that when this rule was trigged, the response headers were already delivered to the client. The user likely got the original HTTP response code, and later nginx finalized the request with a 500, whenever ModSecurity rule matched.
This problem is not actually related to libModSecurity but to the nginx connector. There was an issue opened to treat that specific case: SpiderLabs/ModSecurity-nginx#41
I am closing this in favor of SpiderLabs/ModSecurity-nginx#41. Making a reference there as the problem is very well documented here.
Describe the bug
When a particular modsecurity rule is matched we receive a 500 error response instead of a 403.
Logs and dumps
Output of: 1.
Note: I have changed the website to example.net, so if you see the word example this was originally the websites name. I have also changed the upstream IP to 8.8.8.8 and the listen IP to 1.1.1.1
Note: I have changed the website to example.net, so if you see the word example this was originally the websites name. I have also changed the upstream IP to 8.8.8.8 and the listen IP to 1.1.1.1
To Reproduce
Looking at the nginx response in the access log this gives a 500 error
Expected behavior
I would expect the above command to give back a 403.
Server (please complete the following information):
Rule Set (please complete the following information):