POST body is not inspected by modsecurity #684

code1955 · 2014-03-20T15:53:34Z

Hi,

We are suffering an issue related to POST inspection.
We are running modsecurity 2.7.7 on apache 2.5.3
Backend application is running on Jetty 2.9.
The application presents a login form to the end user.
When filling in the login fields with crafted data, like sql strings, the call is accepted and sent to the backend application.
But adding sql strings in the URL blocks the call.
Backend application is at risk as modsecurity is the only security control in place.
I've been suggested to enable SecStreamInBodyInspection, but it doesn't work.
Any help is welcome.

Kind regards,

zimmerle · 2014-03-20T16:14:16Z

Did you have the SecRequestBodyAccess enabled?

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecRequestBodyAccess

code1955 · 2014-03-20T16:25:53Z

Yes, it is enabled

zimmerle · 2014-03-20T16:27:51Z

Can you share the output of your ModSecurity debug log and configurations?

code1955 · 2014-03-20T16:33:56Z

Here you go.
SecStreamInBodyInspection is enabled at proxy level.
I'll share reverse proxy config too

# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
#SecRuleEngine DetectionOnly
SecRuleEngine on


# -- Request body handling ---------------------------------------------------

# Allow ModSecurity to access request bodies. If you don't, ModSecurity
# won't be able to see any POST parameters, which opens a large security
# hole for attackers to exploit.
#
SecRequestBodyAccess On


# Enable XML request body parser.
# Initiate XML Processor in case of xml content-type
#
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
     "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"


# Maximum request body size we will accept for buffering. If you support
# file uploads then the value given on the first line has to be as large
# as the largest file you are willing to accept. The second value refers
# to the size of data, with files excluded. You want to keep that value as
# low as practical.
#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

# Store up to 128 KB of request body data in memory. When the multipart
# parser reachers this limit, it will start using your hard disk for
# storage. That is slow, but unavoidable.
#
SecRequestBodyInMemoryLimit 131072

# What do do if the request body size is above our configured limit.
# Keep in mind that this setting will automatically be set to ProcessPartial
# when SecRuleEngine is set to DetectionOnly mode in order to minimize
# disruptions when initially deploying ModSecurity.
#
SecRequestBodyLimitAction Reject

# Verify that we've correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
#
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"

# By default be strict with what we accept in the multipart/form-data
# request body. If the rule below proves to be too strict for your
# environment consider changing it to detection-only. You are encouraged
# _not_ to remove it altogether.
#
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200002',phase:2,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}'"

# Did we see anything that might be a boundary?
#
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"

# PCRE Tuning
# We want to avoid a potential RegEx DoS condition
#
SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000

# Some internal errors will set flags in TX and we will need to look for these.
# All of these are prefixed with "MSC_".  The following flags currently exist:
#
# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
#
SecRule TX:/^MSC_/ "!@streq 0" \
        "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"


# -- Response body handling --------------------------------------------------

# Allow ModSecurity to access response bodies. 
# You should have this directive enabled in order to identify errors
# and data leakage issues.
# 
# Do keep in mind that enabling this directive does increases both
# memory consumption and response latency.
#
SecResponseBodyAccess On

# Which response MIME types do you want to inspect? You should adjust the
# configuration below to catch documents but avoid static files
# (e.g., images and archives).
#
SecResponseBodyMimeType text/plain text/html text/xml

# Buffer response bodies of up to 512 KB in length.
SecResponseBodyLimit 524288

# What happens when we encounter a response body larger than the configured
# limit? By default, we process what we have and let the rest through.
# That's somewhat less secure, but does not break any legitimate pages.
#
SecResponseBodyLimitAction ProcessPartial


# -- Filesystem configuration ------------------------------------------------

# The location where ModSecurity stores temporary files (for example, when
# it needs to handle a file upload that is larger than the configured limit).
# 
# This default setting is chosen due to all systems have /tmp available however, 
# this is less than ideal. It is recommended that you specify a location that's private.
#
#SecTmpDir  /opt/apache/common_modsecurity/modsectmp/

# The location where ModSecurity will keep its persistent data.  This default setting 
# is chosen due to all systems have /tmp available however, it
# too should be updated to a place that other users can't access.
#
#SecDataDir  /opt/apache/common_modsecurity/modsecdata/


# -- File uploads handling configuration -------------------------------------

# The location where ModSecurity stores intercepted uploaded files. This
# location must be private to ModSecurity. You don't want other users on
# the server to access the files, do you?
#
#SecUploadDir  /opt/apache/common_modsecurity/modsecupload/






# By default, only keep the files that were determined to be unusual
# in some way (by an external inspection script). For this to work you
# will also need at least one file inspection rule.
#
#SecUploadKeepFiles RelevantOnly

# Uploaded files are by default created with permissions that do not allow
# any other user to access them. You may need to relax that if you want to
# interface ModSecurity to an external program (e.g., an anti-virus).
#
#SecUploadFileMode 0600


# -- Debug log configuration -------------------------------------------------

# The default debug log configuration is to duplicate the error, warning
# and notice messages from the error log.
#
#SecDebugLog /opt/apache/common_modsecurity/modseclogs/debug.log
#SecDebugLogLevel 3


# -- Audit log configuration -------------------------------------------------

# Log the transactions that are marked by a rule, as well as those that
# trigger a server error (determined by a 5xx or 4xx, excluding 404,  
# level response status codes).
#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
#SecAuditLogType Serial
#SecAuditLog  /opt/apache/common_modsecurity/modseclogs/modsec_audit.log

# Specify the path for concurrent audit logging.
#SecAuditLogStorageDir  /opt/apache/common_modsecurity/modseclogs/audit/


# -- Miscellaneous -----------------------------------------------------------

# Use the most commonly used application/x-www-form-urlencoded parameter
# separator. There's probably only one application somewhere that uses
# something else so don't expect to change this value.
#
SecArgumentSeparator &

# Settle on version 0 (zero) cookies, as that is what most applications
# use. Using an incorrect cookie version may open your installation to
# evasion attacks (against the rules that examine named cookies).
#
SecCookieFormat 0

# Specify your Unicode Code Point.
# This mapping is used by the t:urlDecodeUni transformation function
# to properly map encoded data to your language. Properly setting
# these directives helps to reduce false positives and negatives.
#
SecUnicodeMapFile unicode.mapping 20127

code1955 · 2014-03-20T16:34:27Z

Sorry forthe display.
I don't how to change it.

zimmerle · 2014-03-20T16:37:07Z

Can you enable the SecDebugLog and share the output ?

Currently it is:
#SecDebugLog /opt/apache/common_modsecurity/modseclogs/debug.log
#SecDebugLogLevel 3

Will be great to have an output like this:
SecDebugLog /tmp/modsec-debug.log
SecDebugLogLevel 9

Thanks,
F.

code1955 · 2014-03-20T16:38:22Z

#---
# Read in the default values
#---

Include             /opt/apache/common/conf/httpd.conf
Include                         /opt/apache/common_modsecurity/httpconf/httpd-modsecurity.conf

# Mod security config

#SecRuleEngine DetectionOnly
SecRuleEngine on


SecTmpDir                       /opt/apache/xxx.yyy.com/modsectmp/
SecDataDir                      /opt/apache/xxx.yyy.com/modsecdata/
SecUploadDir                    /opt/apache/xxx.yyy.com/modsecupload/
SecDebugLog                     /opt/apache/xxx.yyy.com/logs/modsec_debug.log
SecDebugLogLevel                3
SecAuditLogType                 Serial
SecAuditLog                     /opt/apache/xxx.yyy.com/logs/modsec_audit.log
SecAuditLogStorageDir           /opt/apache/xxx.yyy.com/logs/
SecStreamInBodyInspection   on

#---
# Apache settings and overrides for this service
#---

ServerRoot                      /opt/apache/xxx.yyy.com

#---
# VirtualHost definitions
#---

User    apache

Listen                          ApacheServices1:3903
<VirtualHost                    ApacheServices1:3903>
ServerName                  xxxd.xxx-zzz.com
        RewriteLog              logs/rewrite.log
        RewriteEngine           On
        RewriteLogLevel         2
        RewriteRule             ^/server-status.*               -                                               [L]
        #DocumentRoot            /opt/apache/xxx.yyy.com/htdocs


    RewriteRule             ^/scan/(.*)$                   http://xxx24800lbd.xxx-zzz.com/scan/$1           [NC,P]
        ProxyPassReverse        /scan/                 http://xxx24800lbd.xxx-zzz.com/scan/

        RewriteRule             ^/(.*)$                 http://xxx24800lbd.xxx-zzz.com/scan/info/login.html     [NC,P]
        ProxyPassReverse        /                       http://xxx24800lbd.xxx-zzz.com/scan/info/login.html



    #ProxyPreserveHost  On


</VirtualHost>

code1955 · 2014-03-20T16:39:13Z

I'll share debug log.
It has been set at 9 to record a connection

code1955 · 2014-03-20T16:41:23Z

Too much characters. I have to split it

rcbarnett-zz · 2014-03-20T16:51:20Z

You can paste your data here - https://gist.github.com/ and then put an html link here for us to view.

code1955 · 2014-03-20T16:53:07Z

ok

code1955 · 2014-03-20T16:54:57Z

Here you go

https://gist.github.com/code1955/9668518

code1955 · 2014-03-27T08:10:39Z

No Comment about this issue?

code1955 · 2014-03-27T09:46:19Z

Has this issue already seen somewhere else?
Do I make a mistake?

thank you in advance for your help

zimmerle · 2014-03-27T11:49:09Z

Hi @code1955, we saw that you application is exchanging JSON contents, you probably want to test our JSON branch. It supports does support to parser the JSON content. It is available here:

https://github.com/SpiderLabs/ModSecurity/tree/json

poona · 2014-03-27T13:10:33Z

@code1955

Could you please capture your traffic and paste/mail/share_privately your POST payload here? You can sanitize/redact sensitive data.

poona · 2014-03-27T13:22:40Z

s/Could you please/Is it possible for you to/

code1955 · 2014-03-27T15:29:05Z

Hi Anoop, it's already on github
Le 27 mars 2014 14:22, "Anoop Saldanha" [email protected] a écrit :

s/Could you please/Is it possible for you to/

Reply to this email directly or view it on GitHubhttps://github.com//issues/684#issuecomment-38801221
.

code1955 · 2014-03-27T15:30:00Z

Thank you. I'll check it!
Le 27 mars 2014 12:49, "Felipe Zimmerle" [email protected] a écrit
:

Hi @code1955 https://github.com/code1955, we saw that you application
is exchanging JSON contents, you probably want to test our JSON branch. It
supports does support to parser the JSON content. It is available here:

https://github.com/SpiderLabs/ModSecurity/tree/json

Reply to this email directly or view it on GitHubhttps://github.com//issues/684#issuecomment-38793482
.

poona · 2014-03-27T16:07:35Z

Hi @code1955
Actually I was trying to locate the entire HTTP request payload(captured from a tcpdump packet capture or through auditlog if you have configured the SecAuditEngine to "On"), which the debug log doesn't hold, afai understand. Or were you pointing at something at some other link that I'm probably missing?

code1955 · 2014-03-28T07:57:16Z

Dears,

I received several advises and I'd like to thank you for your support.
I have several things to test.
I'll keep you posted with the result.

Kind regards,

Jean-Raymond

On Thu, Mar 27, 2014 at 2:10 PM, Anoop Saldanha [email protected]:

@code1955 https://github.com/code1955

Could you please capture your traffic and paste/mail/share_privately your
POST payload here? You can sanitize/redact sensitive data.

Reply to this email directly or view it on GitHubhttps://github.com//issues/684#issuecomment-38800031
.

code1955 · 2014-03-28T13:53:17Z

Hi Anoop,

The information you're asking for can be found there:

https://gist.github.com/code1955/9668518

Kind regards

On Thu, Mar 27, 2014 at 2:10 PM, Anoop Saldanha [email protected]:

@code1955 https://github.com/code1955

Could you please capture your traffic and paste/mail/share_privately your
POST payload here? You can sanitize/redact sensitive data.

Reply to this email directly or view it on GitHubhttps://github.com//issues/684#issuecomment-38800031
.

zimmerle · 2014-03-28T13:55:48Z

@code1955 did you had a chance to have the json branch tested?

code1955 · 2014-03-28T14:12:05Z

Hi Felipe,

I Should I download the modsecurity-json.zip file and run this?:

These tools are built during the ModSecurity configure process run under
theapache2 directory. To use them you will first need to run configure
underthe apache2 directory:./configure [any options]

What will have to be done afterward?
indeed, I'll have to provide the soft and task list to the system engineer
who installed modsecurity on my Reverse proxies.

Kind regards

On Fri, Mar 28, 2014 at 2:55 PM, Felipe Zimmerle
[email protected]:

@code1955 https://github.com/code1955 did you had a chance to have the
json branch tested?

Reply to this email directly or view it on GitHubhttps://github.com//issues/684#issuecomment-38920943
.

zimmerle · 2014-03-28T14:15:40Z

Download the file from GitHub, as you are doing, and then try the following:

cd /path/to/your/modsecurity-extracted-files/
./autogen.sh
./configure
make
make install
make test
make test-regression

double check to see if "make install" really placed the mod_security2.so in the correct folder.

code1955 · 2014-03-28T14:19:10Z

Ok, thanks, I'll give that the sys engineer.
I keep you posted with result.
I will be during next week probably.

Have great week end!

On Fri, Mar 28, 2014 at 3:15 PM, Felipe Zimmerle
[email protected]:

Download the file from GitHub, as you are doing, and then try the
following:

cd /path/to/your/modsecurity-extracted-files/
./autogen.sh
./configure
make
make install
make test
make test-regression

double check to see if "make install" really placed the mod_security2.so
in the correct folder.

Reply to this email directly or view it on GitHubhttps://github.com//issues/684#issuecomment-38923024
.

code1955 · 2014-04-11T13:14:46Z

Hi Felipe,

Update has been done, but nothing has changed.
I'm wondering if an update of rules should be done to include something
like "Enable JSON Body Parsing" in modsecurity_crs_10_setup.conf.
I added this directive in the config file, but not sure it is correct.

-- [[ Enable XML Body Parsing ]]

The rules in this file will trigger the XML parser upon an XML request

Initiate XML Processor in case of xml content-type

SecRule REQUEST_HEADERS:Content-Type "Application/json"
"id:'900022',
phase:1,
t:none,t:lowercase,
nolog,
pass,
chain"
SecRule REQBODY_PROCESSOR "!@Streq JSON"
"ctl:requestBodyProcessor=JSON"

Just a copy/past of XML directive.

I'm going to check logs.
But for now, json content is still not parsed with or without the above
directive.

Any other advise is welcome.

Kind regards,

JR

On Fri, Mar 28, 2014 at 3:15 PM, Felipe Zimmerle
[email protected]:

Download the file from GitHub, as you are doing, and then try the
following:

cd /path/to/your/modsecurity-extracted-files/
./autogen.sh
./configure
make
make install
make test
make test-regression

double check to see if "make install" really placed the mod_security2.so
in the correct folder.

Reply to this email directly or view it on GitHubhttps://github.com//issues/684#issuecomment-38923024
.

zimmerle · 2014-04-11T13:32:07Z

Hi @code1955, Did you made this tests using our release candidate version or the json branch?

ModSecurity recommended configuration file contains the example to invoke the json parser:
https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended#L29-L30

Do you ming to share the logs again?

code1955 · 2014-04-22T14:15:24Z

Hi Felipe,

I tested the JSON branch as per your advise.
It doesn't work.
Show log debug level 9 extact:

[22/Apr/2014:16:02:22 +0200]
[xxx.xxx.xxx/sid#15505a8][rid#7fd0a4002970][/scan/info/authenticate/login/][4]
Recipe: Invoking rule d74f38; [file

"/opt/apache/common_modsecurity/modsecconf/modsecurity-recommended.conf"]
[line "56"] [id "200001"].

[22/Apr/2014:16:02:22 +0200]
[xxx.xxx.xxx/sid#15505a8][rid#7fd0a4002970][/scan/info/authenticate/login/][5]
Rule d74f38: 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"

[22/Apr/2014:16:02:22 +0200]
[xxx.xxx.xxx/sid#15505a8][rid#7fd0a4002970][/scan/info/authenticate/login/][4]
Transformation completed in 4 usec.

[22/Apr/2014:16:02:22 +0200]
[xxx.xxx.xxx/sid#15505a8][rid#7fd0a4002970][/scan/info/authenticate/login/][4]
Executing operator "!eq" with param

"0" against REQBODY_ERROR.

Kind regards,

JR

On Fri, Apr 11, 2014 at 3:32 PM, Felipe Zimmerle
[email protected]:

Hi @code1955 https://github.com/code1955, Did you made this tests using
our release candidate version or the json branch?

ModSecurity recommended configuration file contains the example to invoke
the json parser:

https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended#L29-L30

Do you ming to share the logs again?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/684#issuecomment-40203349
.

zimmerle · 2014-04-29T22:28:23Z

Hi @code1955,

Can you provide the full log, as you did on the comment: #684 (comment) ?

Also, we have release the version 2.8.0 which incorporates the features of the json branch, it will be good to test on 2.8.0 instead.

zimmerle · 2015-07-01T13:41:46Z

Hi @code1955, yesterday I've merge #904 into nginx_refactoring branch. It should fix this issue, please confirm that the issue is fixed.

plancked · 2017-01-07T20:13:01Z

Hello Guys,

I'm trying to come up with a simple rule that will deny specific string on a POST body data.

Can you help me create this rule? :)

Thanks
A.

void-in · 2017-01-09T05:10:49Z

@lelekos You shouldn't comment on existing threads your issue is not related. Also I would suggest you read the ModSecurity reference manual or use the mailing list for support queries.

Anyway, a simple rule like:

SecRule REQUEST_BODY "bad-string-to-block" "id:00001,deny,msg:'bad request blocked'"

code1955 · 2017-01-09T08:56:37Z

Hi Zimmerle , and others,

Reading back this post, I apologise for my silence
I'm not any more working for the company where issue occurred, since 2013.
So I'm unable providing any feedback, sorry.
Nevertheless I'd like to thank you for your commitments, and I hope this post was useful for others .
Good job guys, don't stop it!

JR

plancked · 2017-01-09T23:09:09Z

Hello,

I have actually made it to load the strings though a .txt file:

SecRule ARGS "@pmFromFile c:\inetpub\wwwroot\private\badstrings.txt" "t:normalisePathWin,deny,id:49459,severity:4,msg:'NO'"

@void-in thanks.

Alex

md2k · 2017-01-12T18:17:40Z

Hi guys, i have problem with ModSecurity, it is fail to parse Content-Type: application/x-www-form-urlencoded with error: Unknown request body processor: application/x-www-form-urlencoded; charset=UTF-8

Example of request is (it admin-ajax.php request in WP, one of them):
curl 'https://www.domain.net/wp-admin/admin-ajax.php' -H 'Pragma: no-cache' -H 'Origin: https://www.domain.net' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-US,en;q=0.8,ru;q=0.6' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'Cache-Control: no-cache' -H 'X-Requested-With: XMLHttpRequest' -H 'Connection: keep-alive' -H 'Referer: https://www.domain.net/wp-admin/admin.php?page=w3tc_dashboard' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.51 Safari/537.36' --data 'data%5Bwp-auth-check%5D=true&interval=60&_nonce=a4ca997c17&action=heartbeat&screen_id=toplevel_page_w3tc_dashboard&has_focus=false' --compressed

Audit log is:

{
    "transaction": {
        "client_ip": "111.111.111.111",
        "time_stamp": "Thu Jan 12 17:37:17 2017",
        "server_id": "c453bc20354668790965b09c5b033295f1e98e59",
        "client_port": 65043,
        "host_ip": "111.111.111.111",
        "host_port": 443,
        "id": "148423903790.931236",
        "request": {
            "protocol": "POST",
            "http_version": 1.1,
            "uri": "/wp-admin/admin-ajax.php",
            "headers": {
                "Host": "www.domain.net",
                "Connection": "keep-alive",
                "Content-Length": "129",
                "Pragma": "no-cache",
                "Cache-Control": "no-cache",
                "Accept": "application/json, text/javascript, */*; q=0.01",
                "Origin": "https://www.domain.net",
                "X-Requested-With": "XMLHttpRequest",
                "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.51 Safari/537.36",
                "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8",
                "Referer": "https://www.domain.net/wp-admin/admin.php?page=w3tc_dashboard",
                "Accept-Encoding": "gzip, deflate, br",
                "Accept-Language": "en-US,en;q=0.8,ru;q=0.6",
                "Cookie": "removed"
            }
        },
        "response": {
            "http_code": 400,
            "headers": {
                "Connection": "close",
                "Server": "nginx/1.10.2",
                "Date": "Thu, 12 Jan 2017 16:37:17 GMT",
                "Content-Length": "575",
                "Content-Type": "text/html"
            }
        },
        "producer": {
            "modsecurity": "ModSecurity v3.0.0-alpha (Linux)",
            "connector": "ModSecurity-nginx v0.1.1-beta",
            "secrules_engine": "Enabled",
            "components": [
                "OWASP_CRS/3.0.0\""
            ]
        },
        "messages": [
            {
                "message": "Failed to parse request body.",
                "details": {
                    "match": "Matched \"Operator `@eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) \" at REQBODY_ERROR",
                    "ruleId": "200002",
                    "file": "/etc/nginx/modsecurity.conf",
                    "lineNumber": "53",
                    "data": "Unknown request body processor: application/x-www-form-urlencoded; charset=UTF-8",
                    "severity": "2",
                    "ver": "",
                    "rev": "",
                    "tags": [

                    ],
                    "maturity": "0",
                    "accuracy": "0"
                }
            }
        ]
    }
}

Debug Level 9 for such request here: https://gist.github.com/md2k/b0e5acc42c153a3c8a66eda6f40feb75

I use current lates master of v3/master branch and ModSec Nginx dynamic module repository to create plugin (also latest)
Nginx 1.10.2
Ubuntu 14.04.5 LTS

Any idea what wrong with it, from my point of view it is normal request which is pretty common in web?

As addition, nginx compiled with options:

nginx version: nginx/1.10.2
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
built with OpenSSL 1.0.1f 6 Jan 2014
TLS SNI support enabled
configure arguments: --add-dynamic-module=../ModSecurity-nginx/ --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-file-aio --with-threads --with-ipv6 --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed'

md2k · 2017-01-24T13:17:24Z

Any updates for this ?

md2k · 2017-02-15T15:40:26Z

@zimmerle can you take a look for this issue? (i use V3 branch with Nginx through ModSecurity-Nginx module), OWASP 3.0.0
Thank you.

zimmerle · 2017-02-16T18:45:04Z

Hi @md2k,

Originally this issue was about a problem on ModSecurity version 2.x. As I can see you are having trouble on v3.x. Do you mind to open an specific issue for it?

md2k · 2017-02-20T11:33:58Z

Hi @zimmerle , moved ticket to #1330

zimmerle · 2017-05-09T21:05:20Z

No longer a concern in libModSecurity. Marking it as won't fix for 2.x. Further information about libModSecurity available here:
https://github.com/SpiderLabs/ModSecurity/tree/v3/master

zimmerle modified the milestone: v2.8.0 Mar 27, 2014

zimmerle added the TBF by libmodsec label Oct 21, 2016

zimmerle closed this as completed May 9, 2017

POST body is not inspected by modsecurity #684

POST body is not inspected by modsecurity #684

Comments

code1955 commented Mar 20, 2014

zimmerle commented Mar 20, 2014

code1955 commented Mar 20, 2014

zimmerle commented Mar 20, 2014

code1955 commented Mar 20, 2014

code1955 commented Mar 20, 2014

zimmerle commented Mar 20, 2014

code1955 commented Mar 20, 2014

code1955 commented Mar 20, 2014

code1955 commented Mar 20, 2014

rcbarnett-zz commented Mar 20, 2014

code1955 commented Mar 20, 2014

code1955 commented Mar 20, 2014

code1955 commented Mar 27, 2014

code1955 commented Mar 27, 2014

zimmerle commented Mar 27, 2014

poona commented Mar 27, 2014

poona commented Mar 27, 2014

code1955 commented Mar 27, 2014

code1955 commented Mar 27, 2014

poona commented Mar 27, 2014

code1955 commented Mar 28, 2014

code1955 commented Mar 28, 2014

zimmerle commented Mar 28, 2014

code1955 commented Mar 28, 2014

zimmerle commented Mar 28, 2014

code1955 commented Mar 28, 2014

code1955 commented Apr 11, 2014

-- [[ Enable XML Body Parsing ]]

The rules in this file will trigger the XML parser upon an XML request

Initiate XML Processor in case of xml content-type

zimmerle commented Apr 11, 2014

code1955 commented Apr 22, 2014

zimmerle commented Apr 29, 2014

zimmerle commented Jul 1, 2015

plancked commented Jan 7, 2017

void-in commented Jan 9, 2017

code1955 commented Jan 9, 2017

plancked commented Jan 9, 2017

md2k commented Jan 12, 2017 • edited Loading

md2k commented Jan 24, 2017

md2k commented Feb 15, 2017

zimmerle commented Feb 16, 2017

md2k commented Feb 20, 2017

zimmerle commented May 9, 2017

md2k commented Jan 12, 2017 •

edited

Loading