On Sunday 20 February 2005 16:52, Erik Weber wrote:
> Could you elaborate please? Is this a Servlet model security problem,
> one specific to Struts, or one that is only exposed by neglect in
> some other area (which is what I suspect)? This is news to me. I've
> used path mapping all my Java life. I've also posted numerous
> path-mapping strategies on this list (as have others) and never have
> encountered any warnings like this.
Well, after checking, it's actually p. *3*62ff. There Hans says: "The
extension rule, using the expression *.do, is the one that's
recommended for for mapping requests that should be processed
by Struts" (after explaining the different kinds of rules (exact match,
longest path prefix, extension). On p. 363, he says, after giving
some example: "It turns out, however, that even with a separate
mapping for protected resources, it's easy to bypass the the
access control for a Struts action when you use the path prefix
mapping. I'll show you why in a moment. To avoid security issues,
I recommend you stick to the extension-mapping model". Of
course he shows, as always, from p. 364 on. It all starts with
a simplified version of Struts 1.0.2 code:
protected String processPath(HttpServletRequest request) {
String path = null;
path = request.getPathInfo();
if ((path != null) && (path.length() > 0)) {
return (path);
}
path = request.getServletPath();
int slash = path.lastIndexOf("/");
int period = path.lastIndexOf(".");
if ((period >= 0) && (period > slash))
path = path.substring(0, period);
return (path);
}
Then he goes on: "The processPath() method first calls
getPathInfo() on the request object to get the part of the
path that remains after removing the part the container
uses to identify the servlet. For instance, with a path-
prefix mapping such as /ch18/protected/do/* for
the Struts servlet in the deployment descriptor and
a URI such as /ora/ch18/protected/do/StoreMsg, the
getPathInfo() method returns /storeMsg. If it returns
null, it means that an extension mapping is used for the
Struts servlet or that the URI is invalid. If so, the the
getServletPath() method is called to get the complete
context-relative path for the request. With a mapping such
as *.do and a URI such as /ora/ch18/protected/StoreMsg.do,
it returns /ch18/protected/StoreMsg.do. The processPath()
method strips off the extension part and returns the rest
of the path, i.e. /ch18/protected/StoreMsg.
Hence, when you use the path-prefix mapping, only the part
of the URI that comes after the part that identifies the Struts
servlet is returned an subsequently finds a matching action,
while with an extension mapping, the whole context-relative
path is returned and identifies the action. This is what causes
the security problem I mentioned earlier. With the access-
control filter mapped to /ch18/protected/*, and the Struts
servlet mapped to /ch18/do/* and /ch18/protected/do/*,
an adventurous user can access a protected action with a
URI like /ch18/do/storeMsg instead of
/ch18/protected/do/storeMsg, completely bypassing the
access-control filter. This means the only secure way to
to provide access control for Struts actions when you
use path-prefix mapping is to do the access control
within the actions instead of with a filter. It's easier to
just stick to extension mapping, as I recommended
earlier."
So much for now. Filters aside, I think it's more of
a general configuration trap, and probably things
have been changed sind 1.0.2 anyway. Still, we
at least prefer everything we want to channel
through the Struts servlet have a *.do (or what-
ever unique) ending, regardless of path issues,
as not losing track of mapping details is an ongoing
challenge with larger apps in general, and the
last thing I'd like to care about are additional
security considerations of any kind :-)
HTH,
-- Chris.
> Thanks,
> Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
