Re: Preventing direct URL access in a J2EE environment

[Kevin Conaway <kevin.conaway () gmail com>]

I am using BEA WebLogic 8.1.

As I stated in my initial email, I extended certain tag libraries
(NetUI, JSTL etc) to output a cryptographically strong token on any
type of URL (form, anchor, c:url etc).

The token, along with the User ID and action being requested are
stored when the tag is generated.

I wrote a Servlet filter to intercept incoming action requests and
check to see if it had the token.  If it didn't it rejected the
request.  If it did, it looked up the action and User ID by the
incoming token.  If the action and User ID matched, it let the request
through.

I also enabled this ONLY for new requests (redirects if you will), not
forwarded requests because forwarded requests are valid (and can only
be done by the system as I understand it) but they wont and cant
contain a token.

I had a moderate amount of success with this but unfortunately, we
also use some 3rd party libraries that display data
(displaytag.sf.net) and the URLs that it spits out (for paging) are
not modifiable without some serious rework.

With that in mind, I'm at a stand still right now..

Kevin


On Thu, 03 Mar 2005 13:28:11 -0800, Dwayne Ghant <dghant () temple edu> wrote:
> 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/46f26a2d6dafb0a788256bc7005c3fa3/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