WebApp Sec: Re: Preventing direct URL access in a J2EE environment

[Saqib Ali <docbook.xml () gmail com>]

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