The typical usage of Shiro is to maps a set of filters to a given "ant"
path.
/foo/api/* = authc, roles[foobar]
Shiro has always calculated the relative URL as a normalized path and
stripped everything after (and including) a semicolon.
So for example `/foo//api//bar;jsessionid=123` would match the above rule
as sure would compute this URL to be `/foo/api/bar`
The addressed CVE presents itself when Shiro protects another framework
that processes the path differently. For example with Spring, you could
map a controller to `/foo/api/{name}` If Shiro is configured to allow
anonymous access to `/foo/api` but require authentication to
`/foo/api/{name}` a request could be crafted which Shiro would process as
anonymous access, but the Spring controller would handle it differently.
Hopefully, that gives you enough info, while still being aware that folks
are still in the process of upgrading Shiro.
-Brian
On Wed, Aug 19, 2020 at 10:44 AM Antoine DESSAIGNE <
[email protected]> wrote:
> Hello everybody,
>
> I've just seen that the 1.6.0 release is out and it fixes a vulnerability
> issue. Unfortunately, I wasn't able to find out which commit fixes it. Can
> you help me? Thanks!
>
> Also, by looking at the documentation, I saw that backslashes, semi-colons,
> and non-ASCII characters in the URL are now rejecting the request by
> default for security reasons. I'm failing to see how those characters
> threaten Shiro. Maybe it's when Shiro is used with another library? Can you
> help me with that too? Thank you very much!
>
> Thanks a lot for your help on this matter. I need to be able to have
> special characters in the URL (for a search query) and I want to be sure
> that I'm not exposing myself to vulnerabilities.
>
> Have a nice day,
>
> Antoine
>
