So in previous blogs we’ve bemoaned the complexity of the “utility stack” used by ICCP and friends, but over on the Enterprise side, Java/J2EE is no slouch, either.

Besides being currently engaged in a J2EE App Assessment for one of our non-SCADA clients, we’re using a lot of Java web applications and developing some security tools in Java. (Some day I’ll blog on some of these, but let me tell you Jython works just as well with Jakarta httpclient as it does with jamod.

Just today, I was testing Wildfire for use as our internal IM solution. Now I hadn’t set up my own Jabber server for 2-3 years but this was great! Make sure JAVA_HOME is set and run the startup script in bin (Java apps are quite UNIX-friendly whether running on Unix or not) and in 15 minutes you have added users and configured the server though an easy web interface. JSPWiki and SnipSnap are equally easy to setup. Before the MoinMoin Desktop came around, these Java wiki’s were much easier to setup. Just install Tomcat and deploy the .war.

But with this ease of deployment comes complexity. Many of these apps have an embedded database (if your are lucky!), a servlet container (Jetty or Tomcat) or full-blown application server with many many exposed interfaces (JMX, SOAP, HTTP, RMI, and more) and make extensive use of Apache Software Components such as Struts. And the Apache stuff is generally of high quality, with a relatively good security track record, but there are lots of moving parts. And then there are all the xml configuration files.

dbwiki:~/wildfire# find . -name "*.xml" | wc -l 23

(NOTE: Most of these are not security relevant, but just an example of the “XML Hell” of many Java apps)

Although there is no alternative (well, I guess you could the Microsoft route) to build/use applications that consist best of breed Open source components, but this is a lot of libraries to keep track of for security vulns and make sure they are configured right — and this is before you have to deal with any application code itself.