JB, Yep, that is correct. Note the trailing slash is important, I think http://localhost:8181/gogo will return a 404 but http://localhost:8181/gogo/ will bring up the gogo console without requiring authentication.
Kevin On Thu, Feb 23, 2017 at 10:42 PM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Kevin, > > Let me try to reproduce. You mean that I can access to > http://localhost:8181/gogo without authentication, right ? > > Regards > JB > > > On 02/23/2017 11:28 PM, Kevin Schmidt wrote: > >> Hi, >> >> I've come across a situation where the Gogo console ends up being >> accessible at a URL that is unsecured. This is of course not a good >> thing ... >> >> When I install a base Karaf 4.0.8 (and 3.0.8 too it appears) and install >> the webconsole feature, I'm able to go to >> http://localhost:8181/system/console and it requires authentication, and >> I can navigate to the Gogo console >> (http://localhost:8181/system/console/gogo) and everything works fine. >> If I try to go to the Gogo console URL directly in a new browser >> session, it also requires authentication. All is good. >> >> But if I install the pax-war feature, problems arise. All of the above >> works fine, but the Gogo console is now available >> at http://localhost:8181/gogo/ and worse, it doesn't require >> authentication. Prior to installing pax-war, hitting that address would >> yield a 404. >> >> It appears what is happening is that the Gogo console plugin registers >> its servlet in the service registry with an alias property set to >> "/gogo" and the Pax Web Extender Whiteboard sees this and publishes the >> servlet at an endpoint using that alias, and does so unsecured. >> >> I'm not sure if the issue is the Gogo plugin registering itself with an >> alias so the extender whiteboard sees it and publishes it, or if the >> extender whiteboard is supposed to be smart enough to not publish the >> new endpoint, or at least it should do it secured. But it is probably >> pretty common to have a Karaf install with webconsole and pax-war >> features installed, and if so, this security hole is there to be >> exploited. >> >> The workaround we are doing for now is to stop the Gogo plugin bundle as >> we don't really need to use it, but I wonder if other endpoints are >> getting automatically published through this mechanism that might also >> be a surprise? >> >> What is the correct fix for this? >> >> Thanks, >> >> Kevin >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
