Security Advisory 2001-11.1 - JRun SSI Request Body Parsing

Vulnerable Products:

JRun Java application server from Allaire. All current versions (with latest security patches as of November 2001) are believed to be affected, including 2.3.3, 3.0, and 3.1.


Revealing of source code to Java Server Pages, and other protected files inside the web root.


Web sites using vulnerable products as stated above

Revision history:

Vendor notified: 22nd October, 2001
Initial security bulletin created: 23rd October, 2001
Vendor workaround released: 27th November, 2001
Security bulletin published: 28th November, 2001


JRun supports a number of different technologies for dynamically generated content, most importantly Java Server Pages. One lesser-used feature is the support for Server Side Includes (SSI); this is a much simpler language than JSP, which is primarily for including the text of other files on the server (for instance adding standard headers or footers to otherwise static pages), and also supports invoking servlets. By default, the file extension .shtml is assigned to the SSI handler.

Unfortunately, a flaw in the server side component that processes requests for SSI pages means that user supplied data can be included in the SSI processing. A remote user can submit requests containing data which will be processed by the SSI filter; as a result the user can cause the server to execute arbitrary SSI code.


When a request for an SSI page is submitted to the server, and the page does not exist, the SSI handler "falls back" on the body of the HTTP request itself. Usually an HTTP request does not contain a body, but a malicious user can easily construct a request with a body containing SSI commands. These can be used to include the source to other files on the server. For example, a request such as:

GET /nosuch.shtml HTTP/1.0
Content Length: 38
<!--#include virtual="/index.jsp"-->

would return the source of the index.jsp page (subject to SSI processing - so servlet tags may be replaced, but most JSP source would be passed through unmodified). It should be noted that the include directive does not go through the usual URL processing - for example includes of .jsp files are not done by the JSP handler, hence the source code to .jsp's can be obtained. It also bypasses any access controls enforced by the web server (so files in protected directories such as the /WEB-INF/ directory can be accessed). However, it was not possible to access files outside of the web root in the cases that Netcraft tested.

Netcraft also verified that it was possible to execute Java servlets on the server using this vulnerability. As it is common to expose these via the /servlet/ URL mapping, this does not give the attacker any new advantage in the normal setup but could be considered a problem by sites that have disabled the /servlet/ mapping.


As a workaround, sites using JRun can disable the SSI support on the web server, as this is not required for any other features of the server including Java Server Pages, so few sites actually require this functionality. This involves both disabling the .shtml extension mapping to SSI handling, and the /servlet/ method of invoking the servlet which does SSI processing (the latter can be done by either disabling the /servlet/ mapping if it is not used, or by blocking access to the particular servlet affected - allaire.jrun.ssi.SSIFilter for JRun 3.x, com.livesoftware.jrun.plugins.ssi.SSIFilter on JRun 2.3.x). See the security bulletin from Allaire for detailed information on making this configuration change.

Vendor Patches and Comments

Allaire have responded promptly to Netcraft's initial report of this problem. They have confirmed that this is a security problem in the JRun versions listed. A patch is expected to be included in the next rollup patch for JRun. In the meantime they have released a security bulletin to notify customers of this problem, and advise a workaround by disabling SSI.


This information is provided on an AS IS basis in the hope that it is useful in securing vulnerable computer systems; however Netcraft cannot guarantee its accuracy or accept responsibility for any damage resulting from the release of this advisory.


This is one of many vulnerabilities tested by Netcraft's security testing services. Please see for more information.

Crypto Regulations Cast Long Shadow

Recently, the strength of SSL key lengths has been the subject of heated debate in security circles, after Nicko van Someren disclosed that he is able to break 512-bit keys in around six weeks, using conventional office computers.

The analysis focuses on the key length used for the server’s public key (the key which is used to prove the authenticity of the server to web browsers). The longer the key, the harder it is for an attacker to break the key - if this key is broken, it can compromise both past and future secure browsing sessions, and allow the attacker to impersonate the server. Most experts currently recommend a key length of at least 1024 bits as secure and some of the strongest debate has concerned the perceived safety of these 1024 bit keys.

However, a more timely aspect to the work is to highlight the number of SSL servers currently in use on the internet, and their geographical location.

Although US export restrictions on strong cryptography have been relaxed in recent years, data collected as part of our SSL Server Survey shows that the US export legislation and locally acted legislation to restrict the use of cryptography in countries with repressive or eccentric administrations, does still cast a shadow over the security of ecommerce even years after the acts have been repealed.

CountryPercentage of sites
with short keys
USA 15.1%

Internet-wide, around 18% of SSL Servers use potentially vulnerable key lengths. However, these tend to be concentrated in geographical areas outside the United States and its close trading partners. In the US, where over 60% of SSL sites are situated, and Canada only around 15% of sites are using short keys. In most European countries over 25% are still using short keys, and in France, which had laws restricting the use of cryptography until relatively recently, over 40% of sites are using short keys.

US export regulations (described in detail by the crypto law survey) have had a discernable impact in slowing use of strong cryptography outside of the States. One reason export grade cryptography remains quite common is that the relative weakness of the server’s choice of cryptography is not obvious to the end user, so there is so little pressure to make the change. Browser developers are in a position to help change this, perhaps by displaying a graded indication of key length rather than the present lock symbol displayed on all SSL sessions regardless of strength.