Hi,
I can think of three solutions for that.
I was wondering about 3 as well, but it has the negative of not being able to support assets created in the code via PrivateAsset (e.g. items with dynamic paths).
As for 2, isn't there a generic mechanism for sharing application-level data in the cluster? I vaguely remember seeing something like that, but it could have been implementation specific -- I trust that you have a better view of these things.
If there isn't, then 3 certainly seems like the only reasonable choice despite the minor limitations it would bring. After all, those cases are not that frequent and there are workarounds available (using context assets or writing a custom service).
Best regards,
- mb
"Howard M. Lewis Ship" <[EMAIL PROTECTED]> wrote:
You found one of the dirty little secrets of Tapestry.The best thing would be, yes, if the asset service would only d/l services which match against private assets, somewhere.I can think of three solutions for that.1) Scan the app to find all the private assets first. Inefficient.2) Register each asset as it is vended out. How to synchronize (generically) in a cluster?3) Change the service to be not the resource path for the asset, but the page, compnent and asset name.I think option #3 is the best solution, what do you think?----- Original Message -----From: Mind BridgeTo: Howard LewisSent: Saturday, October 19, 2002 6:09 AMSubject: The AssetService -- a security risk in its current incarnationHi Howard,
There is one issue that I had noticed long ago, but had forgotten about it, and it came to my attention again only recently.
The AssetService can currently return any file that is in the classpath. Since each class file contains the other classes that it relates to, it is trivial to write a quick program that starts with the application servlet (whose name or that of the .application spec can be guessed) and pulls down the entire application from there.
Besides the "stealing" of the code, a hacker could then also analyze the application for security weaknesses and would have a far easier job if he decides to wreck havok.
I think this could be considered a pretty serious security hole.
One way to fix it that would be very much backward compatible, I think, is to create a "registry" of private assets. When a PrivateAsset object is created, it would register the path it refers to in the registry, and the AssetService would return only the items that are in the registry and balk at the rest. As a result, only the files that the developer intended to provide would be accessible.
If you like this approach, please let me know -- I can implement it if you want me to.
Also, do you think it may be a good idea to create a maintenance release of 2.2 (or an intermediate release before the 2.3 features are added)?
I hope this makes sense.
Best regard,
-mb
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
