ModSecurity 🚀 - Appears that tx.allowed_request_content_type is not parsed correctly.

Spent some time digging in similar one. So far my assumption is that parser is failing somewhere in the SETVAR_ACTION_QUOTED path.

Minimal configuration to show the differences in various quoting syntaxes:

root@vagrant:/home/test/ModSecurity# cat /etc/nginx/modsec/main.conf  | grep -v "^#" | strings
include /etc/nginx/modsec/modsecurity.conf
SecRule &TX:allowed_http_versions1 "@eq 0" \
    "id:1,\
    phase:1,\
    pass,\
    nolog,\
    setvar:'tx.allowed_http_versions1=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'"
SecRule &TX:allowed_http_versions2 "@eq 0" \
    "id:2,\
    phase:1,\
    pass,\
    nolog,\
    setvar:tx.allowed_http_versions2=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0"
SecRule &TX:allowed_http_versions3 "@eq 0" \
    "id:3,\
    phase:1,\
    pass,\
    nolog,\
    setvar:tx.allowed_http_versions3='HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'"

Debug log excerpts:

[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:allowed_http_versions1 with value: HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:allowed_http_versions2 with value: HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:allowed_http_versions3 with value: 'HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'

@zimmerle @victorhora appreciate your input here, especially any insights about parser debugging. I constructed a chain of "tokens" or "actions" like the following:

ACTION_SETVAR
BEGIN(SETVAR_ACTION_QUOTED)
BEGINX_
EXPECTING_VAR_PARAMETER_OR_MACRO_QUOTED
BEGIN_ACTION_WAITING_CONTENT
SETVAR_ACTION_QUOTED_WAITING_CONTENT

and stuck after (6) here.

I also noticed some changes were made in this area in the following commits, but haven't had enough time to check all the diffs:
https://github.com/SpiderLabs/ModSecurity/commit/6fe8655ed9c608710af1604375f757c38b3eae51
https://github.com/SpiderLabs/ModSecurity/commit/a299997e02ab266d527db1da99e4b8c261fa9842

defanator on 17 Apr 2018

👍1

@JaiHarpalani for the sake of clarity, last part of a list includes closing single quote char:

root@vagrant:/etc/nginx/modsec# curl -vi -X POST --data-binary "param1=value1&param2=value2" -H "Content-Type: text/plain" http://localhost/modsec-full/
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 80 (#0)
> POST /modsec-full/ HTTP/1.1
> Host: localhost
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Type: text/plain
> Content-Length: 27
> 
* upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
< Server: nginx/1.13.10
Server: nginx/1.13.10
< Date: Tue, 17 Apr 2018 15:22:30 GMT
Date: Tue, 17 Apr 2018 15:22:30 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 170
Content-Length: 170
< Connection: keep-alive
Connection: keep-alive

< 
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.13.10</center>
</body>
</html>
* Connection #0 to host localhost left intact

root@vagrant:/etc/nginx/modsec# curl -vi -X POST --data-binary "param1=value1&param2=value2" -H "Content-Type: text/plain'" http://localhost/modsec-full/
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 80 (#0)
> POST /modsec-full/ HTTP/1.1
> Host: localhost
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Type: text/plain'
> Content-Length: 27
> 
* upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.13.10
Server: nginx/1.13.10
< Date: Tue, 17 Apr 2018 15:22:49 GMT
Date: Tue, 17 Apr 2018 15:22:49 GMT
< Content-Type: text/plain
Content-Type: text/plain
< Content-Length: 39
Content-Length: 39
< Connection: keep-alive
Connection: keep-alive

< 
Thank you for requesting /modsec-full/
* Connection #0 to host localhost left intact

(note the Content-Type header in the 2nd case)

defanator on 17 Apr 2018

👍1

Thanks for the helpful input @defanator.

So there's definitely a different behaviour for parsing setvar between v2 and v3. Let me see if I can come up with a fix here. @zimmerle I might need your help :)

@JaiHarpalani as a temporary workaround, you may wish to remove the single quotes around tx.allowed_request_content_type. That will be processed correctly by the parser and allows all the specified content-types.

victorhora on 30 Apr 2018

Just noticed an interesting warning from Flex when rebuilding the Parser:

/home/vhora/modsecurity-v3.0.2/src/parser/seclang-scanner.ll:713: warning, rule cannot be matched

Which, in my codebase (3.0.2) points to SETVAR_ACTION_QUOTED_WAITING_CONTENT (\')

victorhora on 30 Apr 2018

It seemed like the issue was really on that part of the code. I've changed the order on which SETVAR_ACTION_QUOTED_WAITING_CONTENT (\') was waiting for the input and it looks like it's all good now.

I've tested with the CRS (tx.allowed_request_content_type) and now it should accept all those Content-Types as it is. And hopefully it might fix some other related issue.

It's being tested by the buildbots (#1759) but @JaiHarpalani @defanator, it would be nice if you could check if you get the same results as I did to be on the safe side.

Thanks.

victorhora on 1 May 2018

@victorhora patch is now part of v3/master.

zimmerle on 3 May 2018

❤1

@zimmerle @victorhora sorry for the delay, just got a chance to check this again.

Unfortunately, it doesn't work as of v3/master (389cc25), I'm still getting the following:

root@vagrant:~# curl -vi -X POST --data-binary "param1=value1&param2=value2" -H "Content-Type: text/plain" http://localhost/modsec-full/
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 80 (#0)
> POST /modsec-full/ HTTP/1.1
> Host: localhost
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Type: text/plain
> Content-Length: 27
> 
* upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
< Server: nginx/1.13.10
Server: nginx/1.13.10
< Date: Sun, 06 May 2018 04:37:28 GMT
Date: Sun, 06 May 2018 04:37:28 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 170
Content-Length: 170
< Connection: keep-alive
Connection: keep-alive

< 
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.13.10</center>
</body>
</html>
* Connection #0 to host localhost left intact

Error log parts:

2018/05/05 21:37:28 [info] 16579#16579: *1 ModSecurity: Warning. Matched "Operator `Rx' with parameter `^application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'$' against variable `TX:0' (Value: `text/plain' ) [file "/etc/nginx/modsec/owasp-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "928"] [id "920420"] [rev "2"] [msg "Request content type is not allowed by policy"] [data "text/plain"] [severity "2"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] [hostname "127.0.0.1"] [uri "/modsec-full/"] [unique_id "152558144896.402540"] [ref "v0,4o0,10o0,10v94,10"], client: 127.0.0.1, server: , request: "POST /modsec-full/ HTTP/1.1", host: "localhost"
2018/05/05 21:37:28 [info] 16579#16579: *1 ModSecurity: Access denied with code %d (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/owasp-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "127.0.0.1"] [uri "/modsec-full/"] [unique_id "152558144896.402540"] [ref ""], client: 127.0.0.1, server: , request: "POST /modsec-full/ HTTP/1.1", host: "localhost"
2018/05/05 21:37:28 [warn] 16579#16579: *1 [client 127.0.0.1] ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/owasp-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "127.0.0.1"] [uri "/modsec-full/"] [unique_id "152558144896.402540"] [ref ""], client: 127.0.0.1, server: , request: "POST /modsec-full/ HTTP/1.1", host: "localhost"
2018/05/05 21:37:28 [info] 16579#16579: *1 ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:INBOUND_ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/owasp-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "61"] [id "980130"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): Request content type is not allowed by policy"] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [tag "event-correlation"] [hostname "127.0.0.1"] [uri "/modsec-full/"] [unique_id "152558144896.402540"] [ref ""] while logging request, client: 127.0.0.1, server: , request: "POST /modsec-full/ HTTP/1.1", host: "localhost"

libmodsecurity debug log parts:

[8] Saving variable: TX:allowed_request_content_type with value: application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'
[..]
[4] Executing chained rule.
[4] (Rule: 0) Executing operator "Rx" with param "^application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'$" Was: "^$" against TX:0.
[9] Target value: "text/plain" (Variable: TX:0)
[9] Matched vars updated.
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:msg with value: Request content type is not allowed by policy
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:anomaly_score with value: 5
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:920420-OWASP_CRS/POLICY/CONTENT_TYPE_NOT_ALLOWED-TX:0 with value: text/plain
[4] Rule returned 1.

Also, I see that @victorhora used bison 3.0.2 in 5e40850, while I remember there was a hard requirement (?) of bison >= 3.0.4. Would it be the reason? I'll try with parser rebuilding a bit later.

defanator on 6 May 2018

👍1

Rebuilding libmodsecurity with --enable-parser-generation didn't help.

defanator on 6 May 2018

👍1

Hummm that's weird @defanator. I was sure it fixed the issue that @JaiHarpalani reported. Let me triple check to make sure and I'll get back here with my results.

Not sure about the hard requirement with the parser. I'll check with @zimmerle and let you know.

Thanks a lot for the feedback! :D

victorhora on 7 May 2018

Hey @defanator I'm getting different results here :/

With the latest libModSecurity codebase (without rebuilding the parser) If I run your cURL request this is what I get:

$ curl -vi -X POST --data-binary "param1=value1&param2=value2" -H "Content-Type: text/plain" http://localhost:8080/modsec-full/
* Hostname was NOT found in DNS cache
*   Trying ::1...
* connect to ::1 port 8080 failed: Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /modsec-full/ HTTP/1.1
> User-Agent: curl/7.38.0
> Host: localhost:8080
> Accept: */*
> Content-Type: text/plain
> Content-Length: 27
>
* upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 404 Not Found
HTTP/1.1 404 Not Found
* Server nginx/1.13.11 is not blacklisted
< Server: nginx/1.13.11
Server: nginx/1.13.11
< Date: Sat, 21 Apr 2018 15:28:43 GMT
Date: Sat, 21 Apr 2018 15:28:43 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 170
Content-Length: 170
< Connection: keep-alive
Connection: keep-alive

<
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.13.11</center>
</body>
</html>
* Connection #0 to host localhost left intact

Debug log:

[8] Saving variable: TX:allowed_request_content_type with value: application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain
[4] (Rule: 0) Executing operator "Rx" with param "^application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain$" Was: "^$" against TX:0.
[9] Target value: "text/plain" (Variable: TX:0)
[4] Rule returned 0.
[9] Matched vars cleaned.

If I do change _Content-Type_ outside of the values defined by rule (text/plainboom) , this is what I get:

curl -vi -X POST --data-binary "param1=value1&param2=value2" -H "Content-Type: text/plainboom" http://localhost:8080/modsec-full/
* Hostname was NOT found in DNS cache
*   Trying ::1...
* connect to ::1 port 8080 failed: Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /modsec-full/ HTTP/1.1
> User-Agent: curl/7.38.0
> Host: localhost:8080
> Accept: */*
> Content-Type: text/plainboom
> Content-Length: 27
>
* upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
* Server nginx/1.13.11 is not blacklisted
< Server: nginx/1.13.11
Server: nginx/1.13.11
< Date: Sat, 21 Apr 2018 15:40:16 GMT
Date: Sat, 21 Apr 2018 15:40:16 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 170
Content-Length: 170
< Connection: keep-alive
Connection: keep-alive

<
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.13.11</center>
</body>
</html>
* Connection #0 to host localhost left intact

Debug logs:

[8] Saving variable: TX:allowed_request_content_type with value: application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain

[4] (Rule: 0) Executing operator "Rx" with param "^application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|ap$
[9] Target value: "text/plainboom" (Variable: TX:0)
[9] Matched vars updated.
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:msg with value: Request content type is not allowed by policy
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:anomaly_score with value: 5
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:920420-OWASP_CRS/POLICY/CONTENT_TYPE_NOT_ALLOWED-TX:0 with value: text/plainboom
[4] Rule returned 1.

Maybe I'm missing something? :/ I'm wondering if our different setups is leading us to get different results. Should I maybe try with your Vagrant @defanator? :)

In the meantime @JaiHarpalani, it would be nice if you could test the fix and report back :)

Thanks!

victorhora on 7 May 2018

I will try to test the fix and let you know how my testing goes.

On Mon, May 7, 2018 at 4:03 PM, Victor Hora notifications@github.com
wrote:

Hey @defanator https://github.com/defanator I'm getting different
results here :/

With the latest libModSecurity codebase (without rebuilding the parser) If
I run your cURL request this is what I get:

$ curl -vi -X POST --data-binary "param1=value1&param2=value2" -H "Content-Type: text/plain" http://localhost:8080/modsec-full/

Hostname was NOT found in DNS cache

Trying ::1...

connect to ::1 port 8080 failed: Connection refused

Trying 127.0.0.1...

Connected to localhost (127.0.0.1) port 8080 (#0)

POST /modsec-full/ HTTP/1.1
User-Agent: curl/7.38.0
Host: localhost:8080
Accept: /
Content-Type: text/plain
Content-Length: 27

upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 404 Not Found
HTTP/1.1 404 Not Found

Server nginx/1.13.11 is not blacklisted
< Server: nginx/1.13.11
Server: nginx/1.13.11
< Date: Sat, 21 Apr 2018 15:28:43 GMT
Date: Sat, 21 Apr 2018 15:28:43 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 170
Content-Length: 170
< Connection: keep-alive
Connection: keep-alive

<

404 Not Found

404 Not Found

nginx/1.13.11

Connection #0 to host localhost left intact

Debug log:

[8] Saving variable: TX:allowed_request_content_type with value: application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain
[4] (Rule: 0) Executing operator "Rx" with param "^application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain$" Was: "^$" against TX:0.
[9] Target value: "text/plain" (Variable: TX:0)
[4] Rule returned 0.
[9] Matched vars cleaned.

If I do change Content-Type outside of the values defined by rule
(text/plainboom) , this is what I get:

curl -vi -X POST --data-binary "param1=value1&param2=value2" -H "Content-Type: text/plainboom" http://localhost:8080/modsec-full/

Hostname was NOT found in DNS cache

Trying ::1...

connect to ::1 port 8080 failed: Connection refused

Trying 127.0.0.1...

Connected to localhost (127.0.0.1) port 8080 (#0)

POST /modsec-full/ HTTP/1.1
User-Agent: curl/7.38.0
Host: localhost:8080
Accept: /
Content-Type: text/plainboom
Content-Length: 27

upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

Server nginx/1.13.11 is not blacklisted
< Server: nginx/1.13.11
Server: nginx/1.13.11
< Date: Sat, 21 Apr 2018 15:40:16 GMT
Date: Sat, 21 Apr 2018 15:40:16 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 170
Content-Length: 170
< Connection: keep-alive
Connection: keep-alive

<

403 Forbidden

403 Forbidden

nginx/1.13.11

Connection #0 to host localhost left intact

Debug logs:

[8] Saving variable: TX:allowed_request_content_type with value: application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain

[4] (Rule: 0) Executing operator "Rx" with param "^application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|ap$
[9] Target value: "text/plainboom" (Variable: TX:0)
[9] Matched vars updated.
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:msg with value: Request content type is not allowed by policy
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:anomaly_score with value: 5
[4] Running [independent] (non-disruptive) action: setvar
[8] Saving variable: TX:920420-OWASP_CRS/POLICY/CONTENT_TYPE_NOT_ALLOWED-TX:0 with value: text/plainboom
[4] Rule returned 1.

Maybe I'm missing something? :/ I'm wondering if our different setups is
leading us to get different results. Should I maybe try with your Vagrant
@defanator https://github.com/defanator? :)

In the meantime @JaiHarpalani https://github.com/JaiHarpalani, it would
be nice if you could test the fix and report back :)

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SpiderLabs/ModSecurity/issues/1733#issuecomment-387205630,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AfgiHq6H36vE-x1mFRZ_bGqxD0FELLEKks5twLaGgaJpZM4TKrPy
.

JaiHarpalani on 7 May 2018

@victorhora that's weird indeed. I've just re-created the entire VM from scratch a few minutes ago and it's still failing. Relevant data:

vagrant@vagrant:/home/test/ModSecurity$ git log | head -4
commit 389cc253595ab9bce765196e9c3782447d2ada85
Author: Felipe Zimmerle <[email protected]>
Date:   Thu May 3 15:12:00 2018 -0300

vagrant@vagrant:/home/test/ModSecurity-nginx$ git log | head -4
commit c9e38d8507da94fa68d79dd1cdebc2717a4b458f
Author: Felipe Zimmerle <[email protected]>
Date:   Thu May 3 16:45:57 2018 -0300

vagrant@vagrant:/etc/nginx/modsec/owasp-crs$ git log | head -5
commit e4e0497be4d598cce0e0a8fef20d1f1e5578c8d0
Merge: d46913e 9d2465d
Author: Chaim Sanders <[email protected]>
Date:   Fri May 12 13:11:20 2017 -0400

vagrant@vagrant:/etc/nginx/modsec/owasp-crs$ cat /etc/nginx/nginx.conf 
load_module /home/test/ngx_http_modsecurity_module.so;

user nginx;
worker_processes 1;

#master_process off;
worker_rlimit_core 1000M;
working_directory /tmp/;

error_log /var/log/nginx/error.log debug;
pid /var/run/nginx.pid;

events {
    worker_connections 65536;
}

http {
    access_log off;
    keepalive_requests 100000;

    upstream local {
        server 127.0.0.1:8080;
        keepalive 128;
    }

    upstream upload-app {
        server 127.0.0.1:3131;
    }

    server {
        listen 8080 default_server backlog=32000;
        location / {
            default_type text/plain;
            return 200 "Thank you for requesting ${request_uri}\n";
        }
    }

    server {
        listen 80 default_server backlog=32000;
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        location = /status {
            stub_status on;
        }

        location = /204 {
            return 204;
        }

        location / {
            proxy_pass http://local;
        }

        location /upload/ {
            include uwsgi_params;
            uwsgi_pass upload-app;
            client_max_body_size 256m;
        }

        location /modsec-light/ {
            modsecurity on;
            proxy_pass http://local;
        }

        location /modsec-light/upload/ {
            modsecurity on;
            client_max_body_size 256m;
            include uwsgi_params;
            uwsgi_pass upload-app;
        }

        location /modsec-full/ {
            modsecurity on;
            modsecurity_rules_file /etc/nginx/modsec/main.conf;
            proxy_pass http://local;
        }

        location /modsec-full/upload/ {
            modsecurity on;
            modsecurity_rules_file /etc/nginx/modsec/main.conf;
            client_max_body_size 256m;
            include uwsgi_params;
            uwsgi_pass upload-app;
        }
    }
}

Request is the same, all the data in logs is the same.

I'm doing all my tests with the help of vagrant-based environment: https://github.com/defanator/modsecurity-performance

Appreciate any ideas as I'm really stuck now.

defanator on 8 May 2018

👍1

As mentioned on the chat, the problem is that my test environment was not sane. I've rebuilt it and noticed that I had the same results as @defanator.

I've submitted a proper fix for this at https://github.com/SpiderLabs/ModSecurity/pull/1775. Would again appreciate feedback from you folks. Hopefully I got it right now :)

victorhora on 17 May 2018

@victorhora see my comments in the #1775. It works fine and seems to fix the initial issue.

defanator on 17 May 2018

👍1

Thanks for the quick turnaround @defanator! :)

Closing this one.

victorhora on 18 May 2018

Modsecurity: Appears that tx.allowed_request_content_type is not parsed correctly.

All 15 comments

404 Not Found

403 Forbidden

Related issues