Re: Preventing direct URL access in a J2EE environment

[Jeroen van Rijn <xananda () gmail com>]

Kevin,

Building on Paul's example (which was in more detail what I meant by a
random token):

If you want to allow using the back button you could store the last 'n' tokens.

Provided the token length is sufficient and 'n' isn't too large this
would only be slightly less secure, but still accomodate the users as
well.

Then if a link is clicked which includes any of the 'n' stored tokens
you do whatever it is you want to do.

You'd either delete all tokens if this action invalidated the previous
pages, or you'd delete them a bit more selectively if they're still
allowed to browse back to the remaining preceeding pages for which
personal tokens exist.

I hope that made sense, it did in my mind.

- Jeroen.


On Thu, 03 Mar 2005 10:54:12 +0000, Paul Johnston <paul () westpoint ltd uk> wrote:
> 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


-- 
0x00FEEDFACECOFFEE