You might have read my recent post about installing Railo 4 on a Debian server. Post-install I did a bit of clean up and also used Pete Freitag’s excellent hackmycf.com against that server. Many people might not know that it does support checking Railo servers as well as Adobe ColdFusion servers.
Two interesting things popped up:
1. Server Header Version Disclosure – what that essentially means is that if you request a page from the server, the server would respond with something like “Apache/2.2” or “Apache-Coyote/1.1”, leaving a small attack vector for potential attackers by telling them the particular version of what your HTTP or Application server is running on. In an Apache HTTP server scenario this can be easily prevented by specifying some directives in either a virtual host or globally on the server level.
ServerSignature Off ServerTokens Prod
It was kind of weird, because I def. had those directives set and when I was requesting “http://<theserver>.com/” it was just returning “Apache” to me (as expected). Why would it do that but hackmycf did think otherwise. I’ve pinged Pete a quick email and after a bit of trial and error it turned out that the tool actually requested an actual document such as “http://<theserver>.com/blabla.cfm”. The HTTP response indeed contained “Apache-Coyote/1.1” in any request that actually asked for a specific document and not only “/” and implicitly getting the default document, e.g. index.cfm. Looking into how the proxying between Apache and Tomcat/Railo is setup, this actually does make sense. The way to easily fix the issue is to modify your server.xml in Tomcat/Railo to override the server identification string for the HTTP response:
<Connector port="8888" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
server="Apache" />
The change I’ve made here is changing the HTTP server response from Tomcat/Railo to “Apache”, which matches what Apache returns for static pages, JS, images etc.
2. Session Cookies are not marked HTTPOnly – essentially marking your session management cookies HTTPOnly makes them less vulnerable for cross-site-scripting (XSS) attacks. How this works is described in details in Pete’s post (CF) and also in this post on neiland.net CF & Railo).
In Tomcat this is done on the Context level by adding an XML attribute:
useHttpOnly="true"
There are multiple places where you could have specified Context elements in your configuration. For once there’s a default context in context.xml and the attribute should be set there correctly by default. Then you might have added your own custom Context elements in the server.xml when specifying virtual hosts. Add the attribute as above there as well. I had done both, but hackmycf.com was still picking up the problem when I re-ran the test. Another quick email exchange with Pete shed some light onto the situation: I hadn’t switched the Railo server over to use J2EE sessions yet, but was still using the default CFID/CFTOKEN combination on that box.
It seems those cookies are not set to HTTPOnly by Railo (and I’m not sure if there’s a way that can be easily done). However, as Tomcat, the underlying servlet container was set to use HTTPOnly cookies for session management, switching over to J2EE sessions in Railo solved the problem. The corresponding jessionid cookie is set to HTTPOnly just fine, as it should be.
Both issues would probably not be considered critical, but fixing either contributes to an overall improved security of your server. Thanks again to Pete, who’s help in figuring some of the details, was greatly appreciated. You should really check out his hackmycf.com service.
Comments on this entry are closed.
{ 1 trackback }