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 <[email protected] > 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 <[email protected]> > To: [email protected]; Reza Naghibi <[email protected]> > 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 > <[email protected]> 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 <[email protected]> > To: [email protected] > 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 > <[email protected] > > 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 <[email protected]> > > To: [email protected] > > 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 > > > > > > > > > > > > > > > >
