Transaction intializing twice per request for URI '/' #2816
Comments
|
Hello @nagri , As far as ModSecurity is concerned it is seeing two transactions. It is possible for a single HTTP request arriving at an nginx+ModSecurity instance to be processed twice -- depending on how you have set up your nginx configuration. For example error page redirection can result in ModSecurity seeing a request twice (possibly with the request method changed -- owasp-modsecurity/ModSecurity-nginx#152 (comment) ) Even if that particular scenario does not seem to match, my guess is that you are experiencing something comparable. You could try analyzing and experimenting with which location (etc.) blocks in your nginx configuration that you have modsecurity enabled. |
|
Hey @martinhsv, Thank you for replying. Very basic nginx conf, but the issue still persists. furthermore as per the modsecurity audit logs, we can see only one request came and one response was returned. correct me if I am wrong. |
|
One thing I'll draw your attention to is that in your posted debug log output, the two transactions (from ModSecurity's point of view) are 166567211462.029228 and 166567211414.410830. The first of those two ends with the phase REQUEST_BODY ("Starting phase REQUEST_BODY.") I.e. there is no execution of either the phase "RESPONSE_HEADERS" or "LOGGING". This suggests that processing of the original "transaction" is being interrupted at a level above ModSecurity. Indeed the first .conf file that you posted ( #2816 (comment) ) could be consistent with this possibility -- given the error-redirect specification that is present. However, unless something not shown is doing something, I would agree that your second .conf file ( #2816 (comment) ) does not suggest this -- especially if the ModSecurity debug log looks the same after the change to the second .conf file. I would suggest increasing the log level of your nginx error.log file. E.g.: Also, what is/was the content of the response received by the client? With the original .conf was it /50x.html? How about with the second .conf? |
Response is always OK with HTTP status code 200. Error Never occurred. One weid thing happening is that if the URI is anything but "/" the flow is proper and modsecurity is processing only one transaction. here for http://10.11.17.192/index.html debug.log audit.log whats so special about "/"? I also change the nginx error log to debug as you asked for. Here is what I got for URI / ; |
|
Hi @nagri , Your discovery that the anomaly only occurs with the URI '/' is a good finding. That narrows down the issue considerably. It looks like I am able to reproduce that behaviour, so it's not just you. My speculation is that this use case is at least loosely similar to the error-redirect issue discussed earlier in that:
It's possible that this is long-time expected behaviour in nginx or it could also be a bug in nginx. If this is causing a nuisance for you in a production environment, one option that you could consider: if '/' is merely serving safe static content, you could turn off modsecurity in that location block (or only turn it on in other location blocks, rather than in the surrounding server block). Other possibilities include include only turning off (in the '/' location block) those rules that cause misleading results. |
martinhsv
changed the title
30% of the traffic comes via '/' and all the rules are needed there as well. I am afraid cant use the workaround you suggested. What would be the next plan of action? Would you guys try to fix this from your end or would we have to live with this? |
|
When I gave that suggestion as a possible mitigation, what I meant was that you should assess what your needs are with respect to your rules. For example, let's assume you are using blocking mode, and malicious content (such as SQLi) triggers a rule that is intended to result in deny. In that case, I would expect you would not see the request being received by ModSecurity twice. I.e. for these types of rules you probably don't need to do anything special with respect to your URI="/" issue. For some other rules (e.g. transaction counts used for any anti-DoS purposes), knowing when there is a false doubling of the transaction count should be relatively simple to handle. It's, of course, up to you what to do. Those are just some things to consider. In terms of an actual fix, the issue would need more investigation to come to any firm conclusion. |
|
@martinhsv I dont know if this would be the right place to ask this question, but here it goes. If I create a vaiable say What I am observing is each worker process of nginx has a different copy of user.ugmJRkZkjvEz, or so it seems. |
|
Hello @nagri , No, this is not the right place for that. Posting questions on an unrelated issue has several negative effects:
However, to answer your question: if you want memory sharing across nginx worker processes, have a look at ModSecurity's lmdb support (compilation flag: '--with-lmdb'). |
Transaction intializing twice
For the mod security rules that I have wrote, one single request initializes the transaction twice and runs associated lua scripts twice.
Logs and dumps
Output of:
Notice: Be carefully to not leak any confidential information.
To Reproduce
Steps to reproduce the behavior:
Add the following modsecurity configuration;
Curl command to make the request.
Expected behavior
Expectation was Rule: 100002 would run only once per request, but its running twice.
Server (please complete the following information):
Rule Set (please complete the following information):
The text was updated successfully, but these errors were encountered: