WebApp Sec: Re: Preventing direct URL access in a J2EE environment

[Paul Johnston <paul () westpoint ltd uk>]

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