[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Fwd: Major security issue or misconfiguration?

Thanks so much for your input and testing Hugues.

I think to be pragmatic I will go with using Jetty-WarFolderPath: WebContentÂsolution.Â

It is probably more of a matter of full disclosure I guess, with the tutorials showing using this. Trying to filter, as Âyou point out, would be impossible without letting users specify a inclusion/exclusion filter.

I am happy to take an action to do this if it is thought the best way forward?

On Thu, Jun 28, 2012 at 3:08 AM, Hugues Malphettes <hmalphettes@xxxxxxxxxxx> wrote:
Hi Matthew,

Thanks for the report.

Indeed the best workaround is to generate them in WEB-INF/classes.
In theory tycho supports it: https://issues.sonatype.org/browse/TYCHO-328
But I just spend 50 minutes trying it: it does not work for me anymore.

Another workaround consists of placing your webapp folder in a nested folder.

For example 'WebContent'
Add this entry to the manifest:
Jetty-WarFolderPath: WebContent

Then place your web.xml inside WebContent/WEB-INF
and your static content inside WebContent

In your build.properties:
bin.includes = META-INF/,\
       WebContent/,\
       .

In any case I filed this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=383707

I'm not sure what should be the outcome of this: filter *.class by default ?
What if in fact you do want to server those?
How about all the other files: properties, anything could be inside the classes?

Hugues

On Thu, Jun 28, 2012 at 6:19 AM, Matthew Painter
<matthew.painter@xxxxxxxxxx> wrote:
> 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
>
>
>
> _______________________________________________
> 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