Hmm... Of course, the next question should probably be raised if it's
a good idea to base your security model on paths that don't even exist
in reality...
It seems a bit odd to me to place your trust on how the URI string
will be handled internally. If there isn't such a path as
.../protected/..., then why even base your restrictions on that? IMHO,
it's just asking for it. Sooner or later you'll forget while
maintaining your app and you will have a security hole.
Wouldn't it be much better to restrict based upon the action name
itself? That's something that actually exists, not some made-up path
that relies on the user/URI processing to stay that way.
So, in either case, I would/do map my security straight to the name of
the action. If you think about it, it even makes practical sense:
UserRoleA can "deleteItem"(.do)... It even reads normally when you
look at your web.xml.
Just my 2 cents.
JQ.
On Sun, 20 Feb 2005 18:27:51 +0100, Christian Bollmeyer
<[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
