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,
Well, to enforce flow you must have some involvement from every page - that's a fundamental.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.
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:
- Preventing direct URL access in a J2EE environment Kevin Conaway (Mar 01)
- Re: Preventing direct URL access in a J2EE environment Saqib Ali (Mar 01)
- Re: Preventing direct URL access in a J2EE environment RSnake (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Saqib Ali (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Kevin Conaway (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Dwayne Ghant (Mar 03)
- RE: Preventing direct URL access in a J2EE environment David Robert (Mar 06)
- Re: Preventing direct URL access in a J2EE environment Kevin Conaway (Mar 06)
- Re: Preventing direct URL access in a J2EE environment Paul Johnston (Mar 13)
- Re: Preventing direct URL access in a J2EE environment RSnake (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Jeroen van Rijn (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Roy Britten (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Saqib Ali (Mar 01)
- Re: Preventing direct URL access in a J2EE environment Jeroen van Rijn (Mar 03)
- <Possible follow-ups>
- RE: Preventing direct URL access in a J2EE environment Jeff Robertson (Mar 03)
- RE: Preventing direct URL access in a J2EE environment Scovetta, Michael V (Mar 03)
- RE: Preventing direct URL access in a J2EE environment Evans, Arian (Mar 06)