[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-dev] Fwd: Major security issue or misconfiguration?
|
Matthew,
I did manage to get a web.xml and the classes output in WEB-INF/classes:
https://github.com/hmalphettes/tycho-example-projects/commit/50b1b2ca78ec8caea3bb5381da825359e4e5c1f6
Not an actual web-bundle, I started from the tycho example projects
and this is using the latest tycho-0.15.
I hope this helps.
Hugues
On Fri, Jun 29, 2012 at 11:24 AM, Hugues Malphettes
<hmalphettes@xxxxxxxxxxx> wrote:
> Thanks a lot for the feedback Matthew.
>
> On Thu, Jun 28, 2012 at 10:08 PM, Matthew Painter
> <matthew.painter@xxxxxxxxxx> wrote:
>> So, unfortunately, this doesn't work.
> In fact we are using the "Jetty-WarFolderPath: WebContent" for all our
> internal project and we are still using 7.*.
> I'm preparing an example with a tycho build for it.
>
> <snip>
>
>> I have the feeling it might be a case of a bug in Tycho here, so checking
>> out the source now.
>
> Many thanks for the investigation with tycho.
> Definitely sounds like a regression.
>
> Best,
> Hugues.
>
>>
>> Further the other option - making tycho compile into WEB-INF classes works
>> BUT will only either compile into WEB-INF classes, OR include
>> WEB-INF/web.xml:
>>
>> no .class files, web.xml:
>>
>> source.WEB-INF/classes/ = src/
>> output.WEB-INF/classes/ = target/classes
>> bin.includes = META-INF/, \
>> WEB-INF/classes/,
>> assets/,
>> WEB-INF/web.xml
>>
>>
>>
>> .class files, no web.xml:
>>
>> source.WEB-INF/classes/ = src/
>> output.WEB-INF/classes/ = target/classes
>> bin.includes = META-INF/, \
>> WEB-INF/classes/,
>> assets/
>>
>>
>> I have the feeling it might be a case of a bug in Tycho here, so checking
>> out the source now.
>>
>> On Thu, Jun 28, 2012 at 9:33 AM, Matthew Painter
>> <matthew.painter@xxxxxxxxxx> wrote:
>>>
>>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>
