I don't believe that there is something like well known configuration
files or most likely public viewable images. We cannot know all existing
nor upcoming libraries and configuration files. For images the same is
true. May be the images are top secret and only delivered to logged in
users. You can never know.
As a consequence, by default nothing should be public. It is just a
security best practise: Protect by default
We should only mark things that should be public or alternatively follow
the JSF 2 approach to put resources into a dedicated folder. In JSF 2
this is WEB-INF/resources/
the latter would allow a simple approach to language specific JavaScript
and CSS as well.
Yes, I know that it will break backward compatibility.
Best Regards
Sebastian Hennebrueder
Am 09.04.10 08:26, schrieb Alex Kotchnev:
I actually liked how the AssetDispatcher stuff worked - secured by default
and only allowing the stuff that was explicitly makred as public on the
classpath (e.g. css, images, etc). It seems to me that the default-open is a
slippery slope from a security standpoint : today I might forget that I
added some config file w/ a weird extension and tomorrow when I deploy, my
configuration would be widely readable by the world. Not cool.
I liked the idea that was discussed previously, where if possible anything
marked as an Asset would be available, everything else wouldn't; however, it
seemed like there was no good technical solution for that.
Regards,
Alex K
On Fri, Apr 9, 2010 at 2:15 AM, Joachim Van der Auwera<[email protected]>wrote:
Just protecting all files in the classpath may be a bit too strict. Why not
allow all graphics types (png/gif/jpeg) from everywhere? This makes the
integration of component libraries easier.
For example for using chenillekit in 5.2 you need to contribute a
RegexAuthorizer to see the images referred from the css files.
Kind regards,
Joachim
Thiago H. de Paula Figueiredo wrote:
On Thu, 08 Apr 2010 22:13:32 -0300, Howard Lewis Ship<[email protected]>
wrote:
What should be available by default? My opinion, anything in the context,
except WEB-INF.
What should not be available by default? My opinion, anything in the
classpath.
And that's where I disagree; maybe any non .class file outside of a
controlled package should be protected? If we remove the malicious
user's ability to "hunt' for files and protect the ones that may be
important (.class, etc.) then we're good.
Configuration files are very sensitive and are usually located in the
classpath in known places. I would consider most files in the classpath as
something that aren't meant to be publicly accessible unless explicitly
allowed.
--
Joachim Van der Auwera
PROGS bvba, progs.be
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
