WebApp Sec mailing list archives

Re: Preventing direct URL access in a J2EE environment


From: Paul Johnston <paul () westpoint ltd uk>
Date: Thu, 10 Mar 2005 15:16:11 +0000

Kevin,

I had a moderate amount of success with this but unfortunately, we
also use some 3rd party libraries that display data
(displaytag.sf.net) and the URLs that it spits out (for paging) are
not modifiable without some serious rework.
Well, to enforce flow you must have some involvement from every page - that's a fundamental.

If the problem is just that you can't change the URLs, then you could leave them intact and just store in the session which URLs the user is authorized to access next. That doesn't protect against CSRF, but really you only need that on forms, so this could be ok.

If the problem is that there are bits of the app where you can't change the code, but need the feature, things get harder. You could have some kind of front-end filter (perhaps even a separate box) that rewrites outgoing links and checks incoming ones. I doubt this would be any easier than modifying the relevant parts of the app.

Other than that, it comes down to either finding a hack that will let you get the changes through the 3rd party libraries, or deciding that flow will not be enforced for those parts of the site. As for hacks, if it's acceptable to require javascript then you may be able to store the auth tokens in variables/hidden fields and fill-in the URLs on the client. Another possibility, if the 3rd party bits use relative URLs, is to have the auth token as part of the path, so the browser attaches it to the relative URLs.

Regards,

Paul



Kevin Conaway wrote:

I am using BEA WebLogic 8.1.

As I stated in my initial email, I extended certain tag libraries
(NetUI, JSTL etc) to output a cryptographically strong token on any
type of URL (form, anchor, c:url etc).

The token, along with the User ID and action being requested are
stored when the tag is generated.

I wrote a Servlet filter to intercept incoming action requests and
check to see if it had the token.  If it didn't it rejected the
request.  If it did, it looked up the action and User ID by the
incoming token.  If the action and User ID matched, it let the request
through.

I also enabled this ONLY for new requests (redirects if you will), not
forwarded requests because forwarded requests are valid (and can only
be done by the system as I understand it) but they wont and cant
contain a token.


With that in mind, I'm at a stand still right now..

Kevin
--
Paul Johnston, GSEC
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul () westpoint ltd uk
web: www.westpoint.ltd.uk


Current thread: