[Discussion] How to systematically deal with "auth bypass" issues

[lprimak]

Discussion

Currently, every few weeks, Shiro projects receives a security vulnerability report. All of these reports are very similar in nature, but only slightly vary.

The themes are as follows:

• Authentication directives do not work exactly as Spring does, thus leading to confusion and perceived as auth bypass
• Some obscure characters and URL encoding or upper/lower-case lead to perceived auth bypass and confusion

We need to figure out what to do with those reports.
Currently, there isn't even an agreement whether these are or are not a true security issues.

Proposal

• Update documentation with a big disclaimer that the Ant pattern that's used in Shiro is not the same as Spring, so it can be easily linked to when security reports come in referencing this.
• Put the same disclaimer into security vulnerability issue template.
• URLdecode all incoming URLs, and then disallow any non-alphanumeric characters that go into authentication matching algorighm.

Please discuss. Thank you

[fpapon]

Thank @lprimak for opening this discussion.
Agreed with point 1 and 2 of the proposal. About the point 3, we need to be careful about the backward compatibility and to not breaking changes.

[lprimak]

Do we have any way to verify backwards-compatibility of any changes such as this?

How about secure-by-default and ability to disable either URLdecode or special character rejection via a flag to the filter, specified in shiro.ini?
Basically a feature flag that can be disabled?

[fpapon]

Yes I think the feature flag can be a good option. When I am talking about backward compatibility it's about the behavior with the same ini config file for the user.
Agreed with the secure-by-default, it's a good way but any default changes should be well documented and a part of a major version.
Thoughts?