ApacheCon North America is almost concluding, and my experience this year has not disappointed. It’s been great to be able to meet up with lots of other project committers. Many committers make the trek to ApacheCon wherever it is in the world and, given that we normally work together just via the project mailing lists, it has been great to be able to discuss current issues and new ideas face to face. Of course, all of these discussions will be making their way (if they aren't there already) to the Tomcat dev mailing list so the everyone in the community can participate.
Personally, I have spent a great deal of my time in presentations. I have spoken about progress on Tomcat 8, delivered another session on clustering and two on security covering vulnerabilities and security response at the ASF. As always, slides are available from http://people.apache.org/~markt and there should be video and audio recordings available as well at some point. Most sessions were reasonably well attended and the conversation and questions flowed after the presentations. Here are some of the questions and answers I found most interesting:
Tomcat supports multiple instances, and you should consider installing Tomcat so that a single binary runtime directory supports multiple instances as a means of adhering to security best practices.
While the documentation on multiple instances is in the RUNNNING.txt file at the root of the Tomcat binary distribution file hierarchy, many people aren’t necessarily aware of the feature or why you might use it. To provide some insight, let’s look at how this functionality works and provide some insight to the related best practice for security.
Secure Socket Layer, or SSL, certificates are frequently used to confirm the identity of a server before consuming its services and to secure communications with the server. Typically, when an Apache web server is used to load balance requests to one or more Apache Tomcat servers (including VMware’s commercial version, tc Server), the SSL encryption and certificate authentication is terminated at the web server. Communication between the Apache web server and Tomcat is then trusted and in clear text.
However, there are organizational security policies and B2B scenarios that could mandate secure communication between Apache web server and Tomcat. Furthermore, it could be important to restrict access to Tomcat to known instances of Apache web server.
This tutorial will provide details for a configuration option that enables SSL communication and client certificate authentication between Apache Web Server and Tomcat.
At a high level, this tutorial provides instructions to
Cross-site scripting (XSS) is the leading form of security vulnerabilities for web applications today. This vulnerability is found when attackers are able to inject client-side scripting into web pages by tricking the browser to trust scripts run from malicious hosts. These scripts usually access user and session information stored in cookies, and allow the hackers to forge trusted user behavior. The result can allow hijackers to control your user account, change your account settings, or redirect web traffic to malicious or false advertising sites. Recently, there has been an increase in high-profile cross-site scripting attacks on sites like Twitter and IBM's DeveloperWorks, which illustrate how common these vulnerabilities exist on web sites both large and small.
Because cross-site scripting is such a significant and universal threat (a few cross-site scripting issues have been fixed in Tomcat 7), an unofficial extension to the Cookie specifications - httpOnly cookies - has been introduced to combat it. Although it is unofficial, it is widely supported. This feature reduces the risk of these security vulnerabilities by preventing the browser from allowing scripts to access information stored in cookies.
For development and operations teams, a presentation that covers various security configuration options available in Apache Tomcat and SpringSource tc Server.
A default Apache Tomcat installation is secure but each installation environment is different and may have additional security requirements. This presentation will examine the security configuration options available in Apache Tomcat and SpringSource tc Server, when to use them (and when not to use them) and the threats they might help mitigate. The rationale behind having resource passwords (e.g. for database access) in clear text in server.xml will also be discussed.