RE: Preventing direct URL access in a J2EE environment

["Evans, Arian" <Arian.Evans () fishnetsecurity com>]

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