WebApp Sec mailing list archives
RE: Preventing direct URL access in a J2EE environment
From: Jeff Robertson <Jeff.Robertson () DigitalInsight com>
Date: Wed, 2 Mar 2005 22:25:56 -0500
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
Current thread:
- Re: Preventing direct URL access in a J2EE environment, (continued)
- Re: Preventing direct URL access in a J2EE environment Saqib Ali (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Kevin Conaway (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Dwayne Ghant (Mar 03)
- RE: Preventing direct URL access in a J2EE environment David Robert (Mar 06)
- Re: Preventing direct URL access in a J2EE environment Kevin Conaway (Mar 06)
- Re: Preventing direct URL access in a J2EE environment Paul Johnston (Mar 13)
- Re: Preventing direct URL access in a J2EE environment Jeroen van Rijn (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Roy Britten (Mar 03)
- Re: Preventing direct URL access in a J2EE environment Jeroen van Rijn (Mar 03)