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
