Whitelist an ID on URL with wildcard (regex)

Question

Whitelist an ID on URL with wildcard (regex)

Napsty opened this issue 2 years ago · comments

Hello, appreciate that you are continuing naxsi in this fork.
I'm currently using Naxsi WAF built from the master branch from https://github.com/nbs-system/naxsi (cloned September 21st).

I wanted to whitelist the rule 1000 on all URLs starting with /rest, however I still see blocked requests.

Whitelist rule:

BasicRule wl:1000 "mz:$URL_X:^/rest/.*$|URL"; # allow sql keywords on /rest

Block example:

2022/11/04 13:42:44 [error] 1757#1757: *1615318 NAXSI_FMT: ip=xx.xx.xx.xx&server=app.example.com&uri=/rest/webResources/1.0/resources&vers=1.3&total_processed=2872&total_blocked=308&config=block&cscore0=$SQL&score0=8&zone0=BODY&id0=1000&var_name0=xr&zone1=BODY&id1=1000&var_name1=xr, client: xx.xx.xx.xx, server: app.example.com, request: "POST /rest/webResources/1.0/resources HTTP/1.0", host: "app.example.com", referrer: "https://app.example.com/projects/GEN/summary/statistics"

Am I doing something wrong?

Giovanni · Answer 1 · Sat Nov 05 2022 03:39:04 GMT+0800 (China Standard Time)

The issue is that the original repo has broken regex support unless you use ancient versions of nginx and libprce. Use this repo and the bug should go away and work correctly.

Claudio Kuenzler · Answer 2 · Sat Nov 05 2022 18:38:30 GMT+0800 (China Standard Time)

Unfortunately still doesn't work, unless I am having an issue in the config.
Rebuilt the dynamic naxsi nginx module from your repository, enabled in Nginx. No errors with nginx -t. Restarted nginx.
But still getting a Naxsi block on /rest/..., tried with curl request:

MYIP - - [05/Nov/2022:11:33:55 +0100] "GET /rest/gadget/[...] HTTP/1.0" 418 0 "-" "curl/7.68.0"

error log:

2022/11/05 11:33:55 [error] 18415#18415: *7 NAXSI_FMT: ip=MYIP&server=app.example.com&uri=/rest/gadget/[...]&vers=1.4&total_processed=4&total_blocked=2&config=block&cscore0=$SQL&score0=8&zone0=ARGS&id0=1000&var_name0=tablecontext&zone1=ARGS|NAME&id1=1000&var_name1=tablecontext, client: MYIP, server: app.example.com, request: "GET /rest/gadget/[...] HTTP/1.0", host: "app.example.com"

Any idea why?

Environment: Debian Buster with Nginx 1.14.2 (installed from Debian repos), Naxsi module built from your repo and the deb source package.

Giovanni · Answer 3 · Sat Nov 05 2022 18:59:49 GMT+0800 (China Standard Time)

because you are whitelisting only the URL matchzone, but you need to whitelist also ARGS and ARGS|NAME
Just create 3 whitelist rules.

ip=MYIP
server=app.example.com
uri=/rest/gadget/[...]
vers=1.4
total_processed=4
total_blocked=2
config=block
cscore0=$SQL
score0=8
zone0=ARGS <----
id0=1000
var_name0=tablecontext
zone1=ARGS|NAME <----
id1=1000
var_name1=tablecontext

Claudio Kuenzler · Answer 4 · Sat Nov 05 2022 19:07:54 GMT+0800 (China Standard Time)

Thanks for the quick answer and hint! I tried to combine the zones using this:

BasicRule wl:0 "mz:$URL_X:^/rest/.*$|URL|ARGS|NAME"; # allow all on /rest

But it seems that doesn't work, can you confirm?
I now created three different WL rules using:

BasicRule wl:0 "mz:$URL_X:^/rest/.*|URL"; # allow all on /rest
BasicRule wl:0 "mz:$URL_X:^/rest/.*|ARGS"; # allow all on /rest
BasicRule wl:0 "mz:$URL_X:^/rest/.*|ARGS|NAME"; # allow all on /rest

This seems to work.

Giovanni · Answer 5 · Sat Nov 05 2022 19:09:52 GMT+0800 (China Standard Time)

The issue is mixing the rules especially when you have |NAME. when you have a match on |NAME, that one goes into his own rule. probably you can mix the other 2 together.

BasicRule wl:1000 "mz:$URL_X:^/rest/.*|URL|ARGS"; # allow all on /rest
BasicRule wl:1000 "mz:$URL_X:^/rest/.*|ARGS|NAME"; # allow all on /rest

Giovanni · Answer 6 · Sat Nov 05 2022 19:11:30 GMT+0800 (China Standard Time)

to improve the security, i actually do suggest to whitelist the name tablecontext and the value that tablecontext holds that generates this FP.

Giovanni · Answer 7 · Sat Nov 05 2022 19:13:05 GMT+0800 (China Standard Time)

https://github.com/wargio/naxsi/blob/main/naxsi_rules/whitelists/wordpress.rules#L126

Claudio Kuenzler · Answer 8 · Sat Nov 05 2022 19:16:07 GMT+0800 (China Standard Time)

BasicRule wl:1000 "mz:$URL_X:^/rest/.|URL|ARGS"; # allow all on /rest
BasicRule wl:1000 "mz:$URL_X:^/rest/.|ARGS|NAME"; # allow all on /rest

Yes, this also works, thanks!

whitelist the name tablecontext and the value that tablecontext holds that generates this FP.

Thanks for the hint. Unfortunately the requests here are quite complex and use a lot of args (not just tablecontext).

By the way, let me know if you accept donations or repo sponsors.

Giovanni · Answer 9 · Sat Nov 05 2022 19:36:20 GMT+0800 (China Standard Time)

i don't right now, but thank you for the interest :)

Claudio Kuenzler · Answer 10 · Sat Nov 05 2022 22:36:49 GMT+0800 (China Standard Time)

What if I want to completely exclude all rules on the /rest/ path? I still see blocks happening on that path, for example:

2022/11/05 14:09:03 [error] 23853#23853: *849 NAXSI_FMT: ip=MYIP&server=app.example.com&uri=/rest/analytics/1.0/publish/bulk&vers=1.4&total_processed=360&total_blocked=15&config=block&cscore0=$TRAVERSAL&score0=8&zone0=BODY&id0=1205&var_name0=elementtimings, client: MYIP, server: app.example.com, request: "POST /rest/analytics/1.0/publish/bulk HTTP/1.0", host: "app.example.com", referrer: "https://app.example.com/secure/Dashboard.jspa"

I now added another wl rule for the BODY zone:

BasicRule wl:0 "mz:$URL_X:^/rest/.*|URL|ARGS"; # allow all on /rest
BasicRule wl:0 "mz:$URL_X:^/rest/.*|ARGS|NAME"; # allow all on /rest
BasicRule wl:0 "mz:$URL_X:^/rest/.*|BODY"; # allow all on /rest

but what would your suggestion be? Maybe there's something simpler?

Giovanni · Answer 11 · Sat Nov 05 2022 22:51:35 GMT+0800 (China Standard Time)

There is no way to whitelist everything (like a wildcard). also you can join URL|BODY|ARGS
I could add such thing, but i feel like it would be abused by the users.

Claudio Kuenzler · Answer 12 · Sat Nov 05 2022 22:55:28 GMT+0800 (China Standard Time)

It would be cool if you could add such a feature. Some paths might be exposed to public where security is more important while some paths are behind authentication or other access restrictions and might require less protection.