Hello Daniel,

Could you please send me (private) your audit log, error log and debug log (level 9) just when you trigger the error?
Let me check if i can see the problem.



On Wed, Jan 30, 2013 at 7:06 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.

Were using Modsecurity 2.7.1 (over Apache 2.2.22-1), and were 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 its not, the parser returns that error and blocks the access.

In this server specifically, ModSecurity is set to DetectionOnly mode, so we dont 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" \


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, \




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, \


Even with the comments above, the behaviour didnt 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 cant handle the request.

How can we stop this from happening?


Daniel Almendra