Re: Preventing direct URL access in a J2EE environment

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

Kevin,

I'd say you have two likely options:

1) Statefully store authorization tokens
When a page is requested, random numbers are generated for each URL it 
links to. These are included in the generated URL and also stored in the 
user's session. Incoming requests have the auth token checked against 
the session, and auth tokens are removed from the session once used. You 
probably want 128-bit tokens to prevent brute force attacks.

2) Use cryptographic auth tokens
Similar to (1), but instead of generating random numbers and storing 
them, use a cryptographic function, e.g. md5(url + username + 
server_secret). This avoids saving state, but is not as secure as (1), 
because a user can re-use an auth token several times. You can include a 
timestamp in the auth token to reduce this, but you can never make it 
watertight.

It's worth taking a moment to think what these restrictions mean to your 
users: they cannot use the browser's "back" button. They also cannot 
bookmark pages protected in this way. I could accept this from my bank, 
but I would get annoyed if my webmail account made such restrictions.

I recommend storing these auth tokens either in URLs, hidden form fields 
or JavaScript variables. If you store them in cookies (or any 
authentication store that the browser automatically attaches to 
requests) then your application will be vulnerable to CSRF.

Best wishes,

Paul


Kevin Conaway wrote:

> For our application, we would like to prevent users from requesting
> application resources directly.  E.g. browsing to
> http://localhost/app/method.do?id=5&type=3 instead of actually
> clicking on a link that the application provides.
>
> We would like to do this without a major impact on our code.  I was
> thinking of using the following scenario:
>
> - Currently we have tag libraries that help build all our URLS.  These
> tag libraries would be modified to include a strong cryptographic
> token that is unique to each URL/User combination.  - The token/URL
> combination would be stored in the application context for a
> pre-determined amount of time.
>
> - Next, we would use a Servlet filter to intercept the URL.  First,
> deny URLS requested without tokens. If a token is passed, verify that
> matches the token stored in the application context for the requested
> URL.
>
> For the token, I was considering using SecureRandom to generate a
> random number and compute a hash of the random number and the URI
> being requested.  This would be stored along with with URI and the
> user Id.
>
> Could anyone point out any pitfalls I need to be aware of, or if I'm
> going about things the wrong way?
>
> Thanks
>
> 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