2

I'm trying to get ModSecurity 2.7.1 to work with an ASP.NET MVC 3 website. The installation ran without errors and looking at the event log, ModSecurity is starting up successfully. I am using the modsecurity.conf-recommended file to set the basic rules.

The problem I'm having is that whenever I am POSTing some form data, it doesn't get through to the controller action (or model binder).

I have SecRuleEngine set to DetectionOnly.

I have SecRequestBodyAccess set to On.

With these settings, the body of the POST never reaches the controller action. If I set SecRequestBodyAccess to Off it works, so it's definitely something to do with how ModSecurity forwards the body data. The ModSecurity debug shows the following (looks to me as if all passed through):

Second phase starting (dcfg 94b750).
Input filter: Reading request body.
Adding request argument (BODY): name "[0].IsSelected", value "on"
Adding request argument (BODY): name "[0].Quantity", value "1"
Adding request argument (BODY): name "[0].VariantSku", value "047861"
Adding request argument (BODY): name "[1].Quantity", value "0"
Adding request argument (BODY): name "[1].VariantSku", value "047862"
Input filter: Completed receiving request body (length 115).
Starting phase REQUEST_BODY.
Recipe: Invoking rule 94c620; [file "*********************"] [line "54"] [id "200001"].
Rule 94c620: SecRule "REQBODY_ERROR" "!@eq 0" "phase:2,auditlog,id:200001,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:%{reqbody_error_msg},severity:2"
Transformation completed in 0 usec.
Executing operator "!eq" with param "0" against REQBODY_ERROR.
Operator completed in 0 usec.
Rule returned 0.
Recipe: Invoking rule 5549c38; [file "*********************"] [line "75"] [id "200002"].
Rule 5549c38: SecRule "MULTIPART_STRICT_ERROR" "!@eq 0" "phase:2,auditlog,id:200002,t:none,log,deny,status:44,msg:'Multipart request body failed strict validation: PE %{REQBODY_PROCESSOR_ERROR}, BQ %{MULTIPART_BOUNDARY_QUOTED}, BW %{MULTIPART_BOUNDARY_WHITESPACE}, DB %{MULTIPART_DATA_BEFORE}, DA %{MULTIPART_DATA_AFTER}, HF %{MULTIPART_HEADER_FOLDING}, LF %{MULTIPART_LF_LINE}, SM %{MULTIPART_MISSING_SEMICOLON}, IQ %{MULTIPART_INVALID_QUOTING}, IP %{MULTIPART_INVALID_PART}, IH %{MULTIPART_INVALID_HEADER_FOLDING}, FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
Transformation completed in 0 usec.
Executing operator "!eq" with param "0" against MULTIPART_STRICT_ERROR.
Operator completed in 0 usec.
Rule returned 0.
Recipe: Invoking rule 554bd70; [file "********************"] [line "80"] [id "200003"].
Rule 554bd70: SecRule "MULTIPART_UNMATCHED_BOUNDARY" "!@eq 0" "phase:2,auditlog,id:200003,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"
Transformation completed in 0 usec.
Executing operator "!eq" with param "0" against MULTIPART_UNMATCHED_BOUNDARY.
Operator completed in 0 usec.
Rule returned 0.
Recipe: Invoking rule 554cbe0; [file "*********************************"] [line "94"] [id "200004"].
Rule 554cbe0: SecRule "TX:/^MSC_/" "!@streq 0" "phase:2,log,auditlog,id:200004,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
Rule returned 0.
Hook insert_filter: Adding input forwarding filter (r 5541fc0).
Hook insert_filter: Adding output filter (r 5541fc0).
Initialising logging.
Starting phase LOGGING.
Recording persistent data took 0 microseconds.
Audit log: Ignoring a non-relevant request.

I can't see anything unusual in Fiddler. I'm using a ViewModel in the parameters of my action. No data is bound if SecRequestBodyAccess is set to On. I'm even logging all the Request.Form.Keys and values via log4net, but not getting any values there either.

I'm starting to wonder if ModSecurity actually works with ASP.NET MVC or if there is some conflict with the ModSecurity http Module and the model binder kicking in.

Does anyone have any suggestions or can anyone confirm they have ModSecurity working with an ASP.NET MVC website?

2 Answers 2

1

I submitted a bug report for this issue and it has now been fixed in modsecurity 2.7.2. https://www.modsecurity.org/tracker/browse/MODSEC-371

1

So, I'm a few years late to the party, but I'm working through similar issues now and thought I'd share what I'd found.

It's not really an MVC problem. It might be an IIS problem, though something similar appears to affect NGINX (based on this: https://github.com/SpiderLabs/ModSecurity/issues/664) And it still appears to be an issue in the version of ModSecurity that gets installed via the Web Platform Installer utility and the version that's automatically available in Azure AppService, so if there's a patch available, it probably isn't widely deployed.

Based on (https://github.com/SpiderLabs/ModSecurity/issues/562), I've been setting:

SecStreamInBodyInspection On

..which allows POST bodies through, though I've not found any clear indication as to why. This is a bit unsettling because I'm also not sure what, if any, downsides there might be, but the magic seems to work.

Interestingly, the OWASP CRS rules for ModSecurity set SecRequestBodyInspection but not SecStreamInBodyInspection, which suggests to me that this bug doesn't affect all hosts, but it's definitely a trap for IIS users.

HTH

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .