WebApp Sec mailing list archives

Re: Preventing direct URL access in a J2EE environment


From: Saqib Ali <docbook.xml () gmail com>
Date: Tue, 1 Mar 2005 10:46:57 -0800

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


Current thread: