Embedded Jetty Server and Enhanced Jetty Security

Jetty is an open-source, standards-based, full-featured web server implemented entirely in java. It is released under the Apache 2.0 licence and is therefore free for commercial use and distribution. It is a pretty good for embedded the server into any other java enabled product.

Hereunder are some points to enhance the Jetty server security.

Suppress the server version header

By default, the Jetty server includes some version information in it's response headers:

HTTP/1.1 200 OK

Date: Wed, 31 Mar 2004 03:46:50 GMT

Content-Type: text/html;charset=ISO-8859-1

Server: Jetty/4.2.7 (SunOS/5.8 sparc java/1.4.1_03)

...

<snip>

While this is not itself a security risk, some organisations would rather not give out such detailed information. To suppress this header, the system property org.mortbay.http.Version.paranoid needs to be set to true:

java -Dorg.mortbay.http.Version.paranoid=true ...

Hide the jetty config file

We could move the jetty config file into the jar file and read the config file from Jar file. How to access from jar file has some choices:

Choice 1: "jar:file:../lib/Ardmore.jar!/com/avocent/amt/ardmore/serverconfig.xml"

Resource configurationResource = Resource.newResource(System.getProperty( SERVER_CONFIG_XML, DEFAULT_CONFIGURATION_LOCATION));

server = new Server(configurationResource);

Choice 2: InputStream resourceAsStream = this.getClass().getResourceAsStream("/com/avocent/amt/core/server-config.wsdd");

Make web application read only

We could war the web application folders.

<target name="war.single.war" depends="">

<war warfile="${singlewar.webapp.root}/${deploy.webapp.name}.war" webxml="${singlewar.webapp.dir}/WEB-INF/web.xml">

<fileset dir="${singlewar.webapp.dir}" />

<manifest>

<attribute name="CSS-Server-Version" value="${product.version}"/>

<attribute name="Build-Number" value="${build.number}"/>

</manifest>

</war>

<copy todir="${release.base.dir}">

<fileset dir="${singlewar.webapp.root}">

<include name="*.war" />

</fileset>

</copy>

</target>

Remove context list

SOLUTION:

Add the “/” root context and return and intercept the call and don’t return.

HttpContext context = server.addContext("/");

context.addHandler(new AMSGNotFoundHandler());

Suppress Powered by Jetty button

Customize the jetty 404 error message. Same as above

Aliases and Symbolic Links

Jetty by defaults runs in a mode where all file accesses are checked for aliases, such as case insensitivity, short names, symbolic links and extra characters (Eg %00). If a resource is an alias, then it is treated as not found.

Alias requests are a security problem because webapplication security constraints are applied with case sensitive URL patterns. For example, if a security constraint is place on a /mySecretFolder/* and alias checking was not implemented then on a win32 system the following requests could retrieve files from that URL:

o /MySeCrEtFoLdEr/secret.html
o /mysec~a0.dir/secret.html
o /mySecretFolder/secret.html%00

File name aliases come in many forms including case insensitivity, VMS version numbers, Unix symbolic links, 8.3 short names, etc. While some of these aliases (eg symbolic links) are deliberate, there is no general way to tell this in portable 100% java.

Jetty detects aliases by comparing the files absolutePath with its canonicalPath. If the JVM reports these as different an alias is assumed and the resource treated as not found.

SOLUTION:

Alias checking can be turned off by setting the system parameter org.mortbay.util.FileResource.checkAliases to false (see jetty.xml for an example of how to do this in XML configuration). If alias checking is not used, then greater care is needed when designing security constraints. It is recomended that a restrictive constraint be applied to a whole subtree of URL space and then selective constraints be applied to relax security only for specific URLs.

REFERENCES:

http://jetty.mortbay.org/jetty/faq/

http://jetty.mortbay.org/jetty/tut/HttpServer.html

Tony