On 26/02/14 23:27, Ichiro Furusato wrote:
Hi Brian,
Having recently attended a session on security exploits in the JDK I'm
realising the extent
of possible security issues in JSPWiki by opening up the possibility of
external jars and
external configuration, not to mention plugins. For plugins that by their
nature have security
issues (such as our GroovyPlugin and JavaScriptPlugin) we have taken the
approach of
not simply enabling them via a property, as this would permit them to be
made operational
by a property exploit, but rather "permanently" disabling them via a
private static member
variable, such that the classes must be modified and recompiled in order to
function.
I suppose the take-home message was that the open sandbox of the 90s has
given way
to the Java environment being a real target for security exploits that we
probably shouldn't
contribute to, i.e., we need to be very aware of side effects to our
designs.
Ichiro
That is very interesting, Ichiro. It will take me a while to think
through the implications, but my first impression is that a contributed
(i.e. not pre-packaged) jspwiki "plugin" ought not to be a deployment
option.
From my personal point of view that isn't too serious, because I
usually rebuild my jspwiki war and so could inject my code into a
"personal distribution". However, that doesn't feel like the sort of
customisation most users would relish.
If I understand your point sufficiently, it feels like it will be tricky
to resolve the philosophical dilemma. The servlet spec sees a webapp as
a) a collection of code (and default properties) packaged by the
developer, and b) a set of optional property overrides made by the
deployer. The architecture seems to assume that any "extra" code needed
by the webapp will be deployed /higher/ up the ClassLoader hierarchy,
but that doesn't fit the role of a jspwiki plugin.
Sorry, but I still haven't examined Harry's implementation, but if a
webapp needs its own ClassLoader to function properly, it isn't it
violating the servlet model. My experience is not wide enough, but are
there any other servlet projects that have already tackled this
structural problem?
I know the tomcat developers have been closing ClassLoader security
exposures recently. The "paint" is still wet on tomcat 7.0.52... perhaps
Harry's change works on older versions, but that doesn't alter the
architectural problem.
When Harry created it he probably thought he was working on simple bug.
Is this closed JIRA the appropriate place for this discussion?
Meanwhile, I'll have to revert to "war surgery" to deploy my plugin.
Thanks to everyone for your help,
Brian
On Thu, Feb 27, 2014 at 11:46 AM, Brian Burch <br...@pingtoo.com> wrote:
On 26/02/14 19:03, Harry Metske wrote:
hmm, to be honest I never considered this situation of having custom tags
in the plugin jar.
I am not sure if that can be fixed, I would have to dive into that a bit
more..
regards,
Harry
<snip/>
<and-so-on/>
I wonder whether "war surgery" is an inevitable consequence of having
contributed plugins that are not distributed inside the jspwiki war
file? I
don't think my plugin is unusual by needing additional css styles and
tags,
as well as the plugin itself. At the moment, these all need to be grafted
into the deployed webapp directory structure.
You know the old saying... when you are in a hole, STOP DIGGING!
It was a good idea of yours to try finding a way to let users deploy a
contributed plugin outside the webapp, but your reply indicates it was not
a trivial task.
That brings me back to a point I made in an earlier thread - perhaps it
should be easier to get a plugin accepted into the main distribution and
managed as part of jspwiki?
All these "extra" plugins could be enabled/disabled via properties,
possibly using your ClassLoader concepts, so that disabled plugins don't
get loaded at all and so won't represent a security risk for users who
don't want them active?
Thanks for your thoughts and help,
Brian
