CVE-2021-32163: case sensitive in jwtauthn match prefix · Issue #1633 · mosn/mosn

Describe the bug

When using JWT authorization, it is case-sensitive to the prefix that the URL matches, which can lead to authentication bypassing in some scenarios.

It is recommended to apply URL normalization and employ case-insensitive comparison in order to eliminate the risk of potential access control list bypasses.

Expected behavior

Be intercepted by jwtauthn

Actual behavior

Bypass the intercept

Steps to reproduce

config.js

......
"rules": [
             {
                     "match": {
                     "prefix": "/index"
             },
......

NodeJS with Express

curl http://127.0.0.1:2046/index -s -o /dev/null  -H "Authorization: Bearer token" -w "%{http_code}\n" 
401


curl http://127.0.0.1:2046/indeX -s -o /dev/null  -H "Authorization: Bearer token" -w "%{http_code}\n"
200

Minimal yet complete reproducer code (or GitHub URL to code)****Environment

• MOSN Version

According to RFC3986, only the host, sheme, and hexadecimal digits should be case-insensitive. The other generic syntax components are assumed to be case-sensitive.

So, by default, the prefix “/index” should not match with “/indeX”

Yes, that’s true for RFC3986, but the conventions generally use all lowercase paths.

As MOSN is a general network proxy, I think its function of authenticating the matching path needs to support the differences of most applications to the greatest extent.

Personally, I suggest that case-insensitive matching be enabled by default, and users can configure it by themselves.

If the default is case-sensitive, it is best to remind users of possible risks.

Is there any documentation about your mentioned conventions?

I referred to the Envoy JWT Authentication module, but found that its match is also case-sensitive by default. Or am I wrong with some places?

And we do need to provide the ability to configure whether case-sensitive or not by users.

That’s what @GLYASAI is doing right now in #1637