[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-dev] Fwd: Major security issue or misconfiguration?
|
Thanks Jesse :)
I tracked down what I think is the issue in org.eclipse.jetty.osgi.boot.internal.webapp.JettyContextHandlerExtender:
134 // support for OSGi-RFC66; disclaimer, no access to the actual
135 // (draft) of the spec: just a couple of posts on the
136 // world-wide-web.
137 URL rfc66Webxml = bundle.getEntry("/WEB-INF/web.xml");
138 if (rfc66Webxml == null)
139 {
140 return;// no webapp in here
141 }
142 // this is risky: should we make sure that there is no classes and
143 // jars directly available
144 // at the root of the of the bundle: otherwise they are accessible
145 // through the browser. we should enforce that the whole classpath
146 // is
147 // pointing to files and folders inside WEB-INF. We should
148 // filter-out
149 // META-INF too
150 String rfc66ContextPath = getWebContextPath(bundle,dic);
151 try
152 {
153 JettyBootstrapActivator.registerWebapplication(bundle,".",rfc66ContextPath);
154 }
155 catch (Throwable e)
156 {
157 // TODO Auto-generated catch block
158 e.printStackTrace();
159 }
When eclipse builds the bundles, the class files are indeed in the root and so are visible as static resources. The workaround would be to have eclipse put the files within WEB-INF/classes, although I cannot see how this is possible within eclipse/tycho at the moment.
This seems to be by default a massive security issue when using eclipse generated web bundles with Jetty RT. I would also suggest it might be a good idea to not have directory browsing on by default in the webdefault.xml?
What do you think is the best way forward Hugues / everyone else?
It appears to also affect my previous installation, but due to the jetty temporary webapp directories being cleaned by the system (and this not being picked up), it was giving 404s - I think this may be a separate bug/issue the simple workaround being (in theory) to set Java up with a different default temp file location that is not interfered with.
Thanks for your time :)
Matt
On Wed, Jun 27, 2012 at 10:32 PM, Jesse McConnell
<jesse.mcconnell@xxxxxxxxx> wrote:
Hugues is your best bet for an answer.
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx
On Wed, Jun 27, 2012 at 4:03 PM, Matthew Painter
<
matthew.painter@xxxxxxxxxx> wrote:
> Hi all,
>
> Disclosure: This is a cross post from the users list where no-one had any
> suggestions - I hope you as devs may have more insight? :)
>
> I am using Jetty7.5.1+OSGi, exposing servlets by using Web-ContextPath.
>
> Say my path is Web-ContextPath is /foo and I have class bar.FooBar, then I
> can retrieve the class file by going to:
>
>
http://my.server/foo/bar/FooBar.class
>
> and I infact can list the whole directory and subdirectory by visiting:
>
>
http://my.server/foo
>
> If I have a servlet mapped to /* then this does not happen.
>
> This seems like an enormous issue. It hasn't happened previously, and I
> can't seem to find what has changed.
>
> The previous behaviour was to 404 on requesting anything but servlet
> mappings, or assets that are not class files and not in META-INF or WEB-INF.
>
> Can anyone shed any light on why all the class files in the bundle are
> exposed?
>
> Thanks!
>
> Matt
>
>
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev
