Match rule transform POST in GET

[cello86]

Hi All,
we noticed on modsecurity for Nginx connector a strange behavior. If a rule is matched before the normal CRS rules engine the HTTP method is noticed like GET instead the original POST.

We already had some issues with the internal redirects but the matching on different phases can generate this type of error?

Thanks,
Marcello

[martinhsv]

Hello @cello86 ,

I'm not sure I understand the use case that you are describing.

Note that ModSecurity (including the nginx connector) is the "engine". CRS is a generic rule set that is often used with ModSecurity.

From what have included, however, what you are seeing sounds like it might be expected behaviour related to error redirects. You may wish to have a look at the following for more detail: #152 (comment)

If you think what you are experiencing is unrelated to that, please provide additional detail.

[cello86]

Hi @cello86,
we configured the nginx instance with the error page without mod_security enabled to avoid the internal redirect.

    server {
	server_name test.local;

        modsecurity on;
        modsecurity_rules_file /usr/local/nginx/conf/modsecurity.conf;
 
        error_page 403 /error/403.json;

        location ^~ /error {
            modsecurity_rules 'SecRule REQUEST_URI "@beginsWith /" "id:1,pass,phase:2,log,ctl:ruleEngine=DetectionOnly"';
            alias "/usr/local/nginx/error";
        }

 
        location / {
            root   html;
        }
    }

Marcello

[martinhsv]

Hello @cello86 ,

Perhaps I've misunderstood something but how does that configuration result in 'without mod_security enabled'?

You explicitly have 'modsecurity on' within the outside server block. So it will still be 'on' inside the 'location ^~ /error' -- which it seems you understand because you include an extra modsecurity_rules entry there.

That extra rule includes an action 'ctl:ruleEngine=DetectionOnly', so rules that are impacted by that will, of course, use Detection Only.

However even for rule detections after that point, you will still see the effect of the GET requests that were originally POSTs (e.g. in logging). Note also that your "id:1" rule will run later than at least some other rules (you have it as a phase:2 rule), you could have a look at the DebugLog output to confirm which rules are being run in which order.

If none of the above clarifies things for you, I think you're going to have to describe in more detail, what effects exactly you are seeing and how you expect them to be different.

[martinhsv]

Was there anything further on this?