RE: Preventing direct URL access in a J2EE environment

["Scovetta, Michael V" <Michael.Scovetta () ca com>]

Saqib,

No offense, but that's a bad solution. You should never rely on
non-validated header content. If you don't really care very much, but
kinda-sorta want people to not leech, then that's one thing, but if the
application "requires anti-leeching", you need to do a lot more than
check the referrer header. Some ideas could be:
  * short life cookie (set it in the surrounding html, check when
loading the image or whatever)
  * check for a active session (authenticate)
  * funnel all static content through a servlet or something,
        http://server/get_file?id=abcdefg


Regards,

Mike

Michael Scovetta
Computer Associates
Senior Application Developer

-----Original Message-----
From: Saqib Ali [mailto:docbook.xml () gmail com] 
Sent: Wednesday, March 02, 2005 12:23 AM
To: RSnake
Cc: Kevin Conaway; webappsec () securityfocus com
Subject: Re: Preventing direct URL access in a J2EE environment

well for most applications that require anti-leeching, just deny any
HTTP request which has the HTTP_REFERER set to blank.

In Peace,
Saqib Ali
http://validate.sf.net

On Tue, 1 Mar 2005 14:34:30 -0800 (PST), RSnake <rsnake () shocking com>
wrote:
>         Referers are also not availible in some security settings.
>         Zonelabs Zone Alarm Pro, and both Norton Internet Security and
>         Norton Personal Firewall all drop the referring URL.  Forget
>         spoofable, sometimes it's just not there at all.
>
>         See this for details from Symantec:
http://service1.symantec.com/SUPPORT/nip.nsf/46f26a2d6dafb0a788256bc7005
c3fa3/b9b47ad7eddd343b88256c6b006a85a8?OpenDocument&src=bar_sch_nam
>         There are a number of tricks you can use to get more
information
>         from the user's machine, but Referring URL isn't reliable.
Not
>         to mention it can also be non-existant via meta refreshing.
>
> On Tue, 1 Mar 2005, Saqib Ali wrote:
>
> > It is a commonly used technique called anti-leeching or
anti-leaching .
> > Search for "anti leeching php" or "anti leeching jsp" on Google. You
> > will find many resources.
> >
> > You can control the path that a user takes by checking for the
> > HTTP_REFERER . But this is not a fail-proof technique, because the
> > HTTP_REFERER can alwasy be spoofed.
> >
> > In Peace,
> > Saqib Ali
> > http://validate.sf.net
> >
> >
> > On Tue, 1 Mar 2005 10:19:37 -0500, Kevin Conaway
> > <kevin.conaway () gmail com> 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
> >
> >
> > --
> > In Peace,
> > Saqib Ali
> > http://tools.tldp.org/search.php <--- Search for Linux HOWTOs
>
> -R XSS Cheatsheet: http://www.shocking.com/~rsnake/xss.html
>
> The information in this email is confidential and may be legally
> privileged.  It is intended solely for the addressee.  Access to
> this email by anyone else is unauthorized.  If you are not the
> intended recipient, any disclosure, copying, distribution or any
> action taken or omitted to be taken in reliance on it is
> expressly prohibited and may be unlawful.


-- 
In Peace,
Saqib Ali
http://tools.tldp.org/search.php <--- Search for Linux HOWTOs