Open haster opened 1 year ago
My suggestion in the short term would be to set blockTraversal
to false, and add a custom filter to implement a more flexible traversal blocking technique.
And then send us a pull request so everyone can benefit! 😎
Yeah, that was the way I was going also.
Search before asking
Environment
Wildfly 26
Shiro version
1.12.0
What was the actual outcome?
Shiro's InvalidRequestFilter blocks (returns a 400 Bad Request) any path containing an encoded forward slash (%2F) or period (%2E) anywhere when blockTraversal is true. (https://github.com/apache/shiro/commit/b67ff01cb1b94d23908ed7cfb6dfce4d16b54a02)
Not allowing traversal for non-normalized paths seems like a good idea but indiscriminately blocking every encoded forward slash or period seems a bit strict.
For example, the following path would be blocked:
GET /mycompany/issuer/http:%2F%2Fmycompany.example.com/tokens
(where the value of the path parameter 'issuer' would eventually behttp://mycompany.example.com
).This is not path traversal, nor is a URL like
/mycompany/issuer/..%2F..%2F/
, though an overly enthusiastic decoding of such a URL could of course result in path traversal.Maybe this should be a non-default 'extra strict' setting? With the default only blocking non-normalized paths?
What was the expected outcome?
Paths containing encoded forward slashes or periods are allowed by default.
How to reproduce
Start an application configured with a default shiro config (an application that listens to every path and simply consumes or echoes it for example), and do a GET for an path such as
/mycompany/issuer/http:%2F%2Fmycompany.example.com/tokens
Debug logs
No response