Yes, I have done it this way before. You don't even need to put them in the
WEB-INF directory. You can have the servlet read the file itself and stream
it back. Just configure the JSP container to send requests for the resource
to the servlet.
You do need some mechanism for the servlet to determine a valid request from
an invalid one - e.g. session information.
It's nice because it does not impact the existing app.
-David
-----Original Message-----
From: Dwayne Ghant [mailto:dghant@temple.edu]
Sent: Thursday, March 03, 2005 4:28 PM
To: Kevin Conaway
Cc: webappsec@securityfocus.com
Subject: Re: Preventing direct URL access in a J2EE environment
I believe you can drop the whole application into the WEB-INF directory
and just point to it using a servlet or index.jsp from you local web
content directory.
What Container are you using.?? Tomcat , BEA , WebLogic, Oracle
(Tomcat), WebSphere ect.
Kevin Conaway wrote:
Blocking the referrer does nothing for me in this context.
A.) You should NEVER rely on input from the user do to security
validations
and
B.) I cant use the referrer tag since it will show up as coming from
my site when users are browsing legitimately.
I just want to enforce that users actually click on a link to go to a
certain page, not type in the URL manually.
Thanks
Kevin
On Tue, 1 Mar 2005 21:22:52 -0800, Saqib Ali <docbook.xml@gmail.com> wrote:
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/46f26a2d6dafb0a788256bc7005c3fa
3/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
--
Dwayne A. Ghant
Application Developer
Temple University
215.204.5555
dghant@temple.edu
