Apache JServ Security Issues

This document briefly discusses security issues of which Apache JServ users should be aware.

Web server
Most importantly, the Apache web server and the machine it runs upon should be well-secured according to the vendor's most recent advice. For sensitive applications, it may be appropriate to use Apache JServ with an SSL-enabled version of Apache.
Apache JServ Protocol
It is recommended that the sockets used by Apache to communicate to Apache JServ be firewalled to prevent connections from external machines, and that it be used over a secure network.
Currently Apache JServ implements IP filtering and connection authentication but it does not prevent data sniffing nor server spoofing. Even if current security features are enough for most needs, it is highly recommended that the connection be secured to guarantee safety of sensible and secret data.
Hostile servlets
Apache JServ currently provides little protection against malicious servlet code loaded onto the local host. Java code loaded as a servlet executes with the permissions of the JVM (generally, the same as those of the web server.) In some situations it may be appropriate to run Apache in a chroot'd environment. Implementing a SecurityManager wrapper around servlets is on the TODO list.
Network-loaded code
Apache JServ does not currently support loading code across the network. If the sandbox and other security issues discussed here were implemented, then code could be safely loaded across the network.
Cookies and sessions
Cookies or rewritten URLs are used to identify sessions. Objects within a session are never transmitted across the network.
If a remote attacker could guess another user's session ID, they could impersonate that user. By default, cookies are not stored on the user's disk when their browser terminates.
The cookies supplied by JServ are used purely to link to information on the server they originate from and pose no risk to the security of the browser.
System classes
Users who can install servlet classes may override Apache JServ or Java Runtime classes with their own definitions. This may cause security problems.
Native code
Apache JServ currently allows native code to be loaded from within servlets and Java itself imposes no restrictions on native code.