As you said at the end, I would ensure your 15 exception file is Included before the modsecurity.conf file. 

--
Ryan Barnett
Lead Security Researcher

On Jan 30, 2013, at 4:24 PM, "Daniel Silva Almendra" <daniel.almendra@bcb.gov.br> wrote:

Hi Breno and other ModSecurity Developers/Users.

 

If anyone has ever seen the problem below, please help us.

 

Weíre using Modsecurity 2.7.1 (over Apache 2.2.22-1), and weíre facing the following problem: we have an application that has a web services module, which runs in the backend (behind Apache/ModSecurity). This webapp allows the user (web services client) to submit PDF file via POST requests. These PDF files are attached to the SOAP/XML message. When the user tries to send a specific PDF file (not all), ModSecurity returns an HTTP Status ď0Ē to the user, and in ssl_error_log file we see the following message:

 

[<date>] [error] [client ***.***.***.***] ModSecurity: XML parsing error: XML: Failed parsing document. [hostname "**********"] [uri "**********"] [unique_id "**********"]

 

It seems that ModSecurity is trying to parse the document, thinking it is XML, but since itís not, the parser returns that error and blocks the access.

 

In this server specifically, ModSecurity is set to DetectionOnly mode, so we donít understand why it is blocking in this case. When we deactivate ModSecurity, the request is forwarded to the backend successfully, which rules Apache out of the problem.

 

In modsecurity.conf we have:

 

SecRule REQUEST_HEADERS:Content-Type "text/xml" \

     "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"

 

SecRule REQBODY_ERROR "!@eq 0" \

     "id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"

 

And in modsecurity_crs_10_setup.conf, we have the following lines:

 

SecRule REQUEST_HEADERS:Content-Type "text/xml" \

  "id:'900017', \

  phase:1, \

  t:none,t:lowercase, \

  nolog, \

  pass, \

  chain"

        SecRule REQBODY_PROCESSOR "!@streq XML" \

          "ctl:requestBodyProcessor=XML"

 

We tried to comment out the rule 200001, but the behaviour was the same. We also tried to insert an exception in the file modsecurity_crs_15_local_exceptions.conf, like this:

 

SecRule REQUEST_FILENAME "@beginsWith <problematic_path>" "phase:1,t:none,pass,id:'1024',nolog, \

    ctl:ruleRemoveById=900017, \

    ctl:ruleRemoveById=200001, \

    ctl:ruleRemoveById=200000Ē

 

Even with the comments above, the behaviour didnít change. I believe the main problem is either of the following:

-          The exception above is included after the rules themselves, so the block action has already happened when the exception rule triggers.

-          The XML parser error causes ModSecurity to abort the request analysis as a whole, no rule is actually triggered. It simply canít handle the request.

 

How can we stop this from happening?

 

Regards,

Daniel Almendra

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/



This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.