Kevin,
Per Paul below, he rather eloquently summed this up but I will add
some minutia:
1. Google for CSRF web application for more security related info
as opposed to anti-leeching.
2. Paul distinguishes stateful vs. crypto auth tokens. I think we use
different terminology for the same ideas which is simply:
3. Simple terms to use are Static Authorization Tokens (SATs), and
Dynamic Authorization Tokens (DATs). Static would be a reusable
hash which is preferable from a resource standpoint, and dynamic
would be a one-time token that cryptographically secure and is
significantly stronger in terms of forcing authorization.
Use in cookies is self-defeating. Use in form fields is ideal and
provides an application with the least attack surface. All sensitive
functions must then be postable forms.
Use of DATs in URLs is better than nothing, limiting CSRF, limiting
most URL-based script injection like URL parameter XSS, and
limiting workflow bypasses by enforcing 'explicit entrypoints', like
you expressed concern for having.
Use of SATs or DATs in URLs does significantly increase attack
surface as they can be subject to scripted brute force by CSRF,
they are stored in web logs by default, and passed in refer fields.
4. Browser "back" button: if you implement a ReturnURL parameter
in your application and issue a unique DAT to ReturnURL like you
would for the rest of your links/forms, there is a way to maintain
use of the Back button.
When a user requests an URL with a dead token you can redirect
them to the application entrypoint, which can read the ReturnURL
parameter and if there's a valid link+SAT/DAT, load the originating page.
5. I'll be releasing a paper on this later this month distinguishing
session from auth tokens and talking about all the different ways
these can be used, pros and cons, etc., if you are still in the market
for info at that time.
Arian
-----Original Message-----
From: Paul Johnston [mailto:paul@westpoint.ltd.uk]
Sent: Thursday, March 03, 2005 4:54 AM
To: Kevin Conaway
Cc: webappsec@securityfocus.com
Subject: Re: Preventing direct URL access in a J2EE environment
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
