Closed
Description
As we discussed in ModSecurity issue #2465, the nginx connector tries to do all the processing as early as possible.
The unexpected behavior is the server doesn't send the response headers to client. It can reproduced with this minimal rule set:
include /etc/nginx/modsec/modsecurity.conf
SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"
SecAction "id:900101,phase:1,nolog,pass,t:none,setvar:tx.trigger_phase1=1"
SecAction "id:900103,phase:1,nolog,pass,t:none,setvar:tx.trigger_phase3=1"
SecAction "id:900105,phase:1,nolog,pass,t:none,setvar:tx.trigger_phase5=1"
SecRule TX:TRIGGER_PHASE1 "@eq 1" "id:901111,phase:1,t:none,deny,log"
SecRule REQUEST_BODY "@rx attack" "id:901121,phase:2,t:none,deny,log"
SecRule TX:TRIGGER_PHASE3 "@eq 1" "id:901131,phase:3,t:none,deny,log"
SecRule RESPONSE_BODY "@rx ok" "id:901141,phase:4,t:none,deny,log"
SecRule TX:TRIGGER_PHASE5 "@eq 1" "id:901151,phase:5,t:none,pass,log,msg:'This is the phase 5.'"
The request can be anything, the set contains 3 rules which will triggered always in phase 1, 3 and 5.
The disrputive action of these rules are deny which means the rule wants to terminate the process, but Nginx continues.
Metadata
Metadata
Assignees
Labels
No labels