devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: Separate "Console" from Java Client
Date Thu, 08 Jan 2015 15:27:44 GMT
Good. I guess a new JIRA ticket would be good in that area. Volkan (though
he is not a full PMC member at this stage) said he'd be happy to help, so I
guess it should work well. Whether or not a separate "example" still makes
sense after a console exists, not sure, they would likely be redundant.
Which is why https://issues.apache.org/jira/browse/DMAP-54 could end up
worth closing (after such module exists and works the same way)


On Thu, Jan 8, 2015 at 4:20 PM, Reza Naghibi <reza.naghibi@yahoo.com.invalid
> wrote:

> If someone gets shell access to a server and decides to run DeviceMap
> benchmarks, what would be kind of funny :)
>
> Regardless, again, im in total agreement. org.apache.devicemap.cmd.Main
> belongs somewhere else. Its not core functionality.
>
>
>       From: Werner Keil <werner.keil@gmail.com>
>  To: dev@devicemap.apache.org; Reza Naghibi <reza.naghibi@yahoo.com>
>  Sent: Thursday, January 8, 2015 10:13 AM
>  Subject: Re: Separate "Console" from Java Client
>
> If someone gained shell access to a server they don't need to use the Web
> interface (which normally should respond to foul-play or DOS attempts by
> refusing connections anyway) They also don't even need root or sudo rights
> here. As Open Source files can be found publicly available so knowing the
> source a simple batch/shell against the JAR would work without writing Java
> code yourself.At the moment DeviceMap may not be as widely deployed as
> Apache poster children like Tomcat, etc. but it's visible and the command
> line environment does not have the same security managers protecting the
> Web container, so the JAR somewhere in most file systems (a "webapp"
> folder, "tmp" or similar) could be used to script an attack. Where the
> extra power (and some risk) of console access is desired by a company they
> can add it, but it should be their choice, not pre-bundled under the hood.
>
>
> On Thu, Jan 8, 2015 at 3:48 PM, Reza Naghibi
> <reza.naghibi@yahoo.com.invalid> wrote:
>
> You can only DOS code which is exposed on the web. I dont think calling a
> main() method is a common practice in web development. If a developer
> chooses to do this, more power to them. Its a choice, not a risk.
>
>       From: Werner Keil <werner.keil@gmail.com>
>  To: dev@devicemap.apache.org
>  Sent: Thursday, January 8, 2015 9:29 AM
>  Subject: Re: Separate "Console" from Java Client
>
> It offers just "read only" access, so data could not be destroyed directly,
> but a DOS (Denial Of Service) attack by executing Ten Thousands or Millions
> of UA strings would already be risk enough to most companies. This happens
> in similar ways e.g. against SQL databases and unless it's a really
> unprotected enterprise server, those are also done much easier against a
> console interface like Oracle SQL*Plus.
>
> Werner
>
>
>
>
> On Thu, Jan 8, 2015 at 2:35 PM, Reza Naghibi
> <reza.naghibi@yahoo.com.invalid
> > wrote:
>
> > While I totally agree with you that org.apache.devicemap.cmd.Main can and
> > should live somewhere else, it is in no way, shape, or form a security
> > risk. There is no 'shell' in there.
> >
> >      From: Werner Keil <werner.keil@gmail.com>
> >  To: dev@devicemap.apache.org
> >  Sent: Thursday, January 8, 2015 8:27 AM
> >  Subject: Separate "Console" from Java Client
> >
> > Hi,
> >
> > As discussed mainly here in JIRA
> > https://issues.apache.org/jira/browse/DMAP-54 it seems advisable to
> > separate the "Console" (Main class) from the actual Java Client.
> >
> > An optional W3C module on top of it already suggests bit of
> modularization,
> > so a small optional module (pretty much similar to the "Console Example"
> > which is the actual subject of DMAP-54) would further improve this.
> >
> > Most importantly baking a console shell into the client library poses a
> > security risk because it requires little more than a batch or shell
> script
> > to run UA queries against that and it runs in a Java SE context. All
> known
> > Java vulnerabilities of the last months and years affect Java SE in a
> > standalone/desktop environment, a proper EE container is usually well
> > protected as well as code running inside it. While a JAR that exposes
> > console functionality may be abused via scripts much more easily.
> >
> > Regards,
> >
> > Werner
> >
> >
> >
> >
>
>
>
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message