RFC 2396 defines parameters which can occur in any of the path segments of a URL, after a semi-colon character. The servlet spec refers to these as "path parameters" and is not consistent on whether they should be removed from the decoded values returned by HttpServletRequest,getServletPath() and HttpServletRequest,getPathInfo(). As a result, different servlet containers treat the issue differently. Tomcat does not include path parameter values, but Websphere apparently does.
Path parameters should be removed before matching against a secured Ant path pattern (which uses the concatenated servletPath + pathInfo). They complicate the process of pattern matching and make it harder to account for all possible URL values which an attacker could submit. In practice they are rarely used within an application, though most users will be familiar with the addition of a jsessionid parameter to URLs.
As an example, if an application defined a secured path as "/secure/*", then to account for the possibility of path parameters, the pattern would actually have to be "/secure/**", otherwise a path such as "/secure;x=y/file" could be used to bypass the match. In cases where a trailing wildcard is not used, it could be possible to add a parameter which caused a different match to take place. For example with this configuration:
A user could potentially gain admin access by submitting a request to "/admin/securedFile.jsp;x=user.jsp".