« New HOWTO Article on Figuring Out SSL Cipher Strength in Java | Main | JBoss: Overlooked Solution for JGroups-Related Startup Errors »

09/04/2009

Apache Tomcat 5.5.28 Stable Released

I received email notification earlier today that version 5.5.28 stable has been released of Apache Tomcat.  Downloads are available at a mirror nearby.  Perhaps the best kept secret in the open source world today, the changelog for Tomcat 5.5.28 has not shown up on the site yet.  For those of us in the "inner circle", (which means "anyone who may have already downloaded the release and opened the included Changelog.html), there are a lot of fixes and security updates in this release.

New enhancements in this release:  

  • The Tomcat Installer for Windows will now detect and install the 64-bit version of tomcat.
  • The session cookie name and session path can now be configured via system property setting.
  • Support for httpOnly on session cookies.  Setting this prevents javascript document.cookie calls from being able to interact with the JSESSIONID.
  • and finally, one which I don't understand yet:  Allow log file encoding to be configured for JULI FileHandler.
In addition to these enhancements, there are lots of bug-fixes and updates to some third party libraries and components that tomcat depends on.  All in all, a very solid update.

One potential cause for confusion for me, at least, is surrounding bug fix 39396.  Starting with this release, tomcat will no longer report TRACE as a method in the Allow header on OPTIONS calls unless TRACE is enabled.  Personally, an OPTIONS request for every other web server, as far as I know, lets you know what methods that server is capable of supporting, not necessarily methods that are enabled on the server.  In my opinion, a vulnerability scanner that is flagging you as being vulnerable to TRACE based off of what the scanner scraped from an OPTIONS request "Allow" header response is a broken vulnerability scanner.  This potentially sets a precedent that other methods should be removed from the response header as well, if they are not enabled.  Will DELETE or PUT be next?  What about if OPTIONS is disabled?  Will OPTIONS requests still work and report that OPTIONS was disabled?  Sure, the last question is facetious but I think that the vulnerability scanners need to be smarter.  The web server should not be configured to fool the vulnerability scanner.  It should be configured to be as secure as possible but if all you need to do is disable OPTIONS and disable version numbering, then all you've really done is pass a scan without making the site any more secure.  Please someone correct me if my understanding of OPTIONS is completely wrong.

TrackBack

TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a01156fbc6fe6970c0120a5a0b453970c

Listed below are links to weblogs that reference Apache Tomcat 5.5.28 Stable Released:

Comments