There is a world of difference between "leeching" - which is other websites
linking to your images and mp3's and such and thereby eating up your
bandwidth without increasing the eyeballs that see your web page - and the
security threat of forced browsing, which is what I assume the O.P. is
concerned about. Leeching is not a security issue and none of the commonly
used solutions for it are any good for security purposes, as they are all
designed to keep that image or whatever from showing up on the browsers of
the untechnical masses, while forced browsing is a tool of the clueful
attacker.
To address the original issue: (assuming you're using Struts since your URL
has ".do" in it) wouldn't it be easier to validate that the individual user
is permitted to the URL they are trying to access? This can be done in any
number of ways, using role-based or all manner custom security schemes.
Struts even has some built-in declarative support for roles, although I've
never used it.
Even taking the most worst-case, most coding-intensive approach, which is
programatically looking up the user's id (since in his case you probably
already implemented your own custom database-backed login screen that ends
up putting the user's id in session scope after a successful login) in a
custom database "permissions" table that maps user ID's to permitted URLs is
going to be simpler to code than some kind of a system to ensure that only
URLs generated by your application can ever be followed. A servlet filter
should be able to handle that easily.
Not saying that forcing the user to always use your links is impossible,
just that if you are checking all the permissions anyway then you probably
no longer need to worry about it all that much. Your mileage may vary, and
maybe you really do need this. There are probably folks around here who have
done it, and I personally know people who have written things almost exactly
like what you describe, but unless you've really analyzed your situation and
determined that you need it, it is probably overkill.
As an aside, ideally your Strut's actions should be using some kind of a
deeper layer (POJO's, EJB's, web services, stored procedures, something!) to
handle the real business logic, and that code should always be enforcing
domain-level security anyway, either declaratively or programmatically. Is
that user permitted to call that method? Does he own that bank account he is
trying to transfer money out of? If you take care of that sort of thing in
the business layer then any kind of URL security is just icing on the cake.
But you already said that you didn't want to have to modify a lot of your
code, and if you're not already doing this then it would take a lot of
effort to put it in now..
-----Original Message-----
From: Saqib Ali [mailto:docbook.xml@gmail.com]
Sent: Tuesday, March 01, 2005 1:47 PM
To: Kevin Conaway
Cc: webappsec@securityfocus.com
Subject: Re: Preventing direct URL access in a J2EE environment
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
