You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had searched in the issues and found no similar issues.
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. (b67ff01)
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 be http://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
The text was updated successfully, but these errors were encountered:
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! 😎
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. (b67ff01)
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
The text was updated successfully, but these errors were encountered: