Performance of attracting interest is one of a very small number of well known sites running both Windows 2000 and Windows 2003 in a load balanced pool, and has become a tempting target for people to use as a straw in the wind towards the relative performance of the two operating systems. One person mailed us saying he thought that the Intel site's response time had slowed since Intel started using Windows 2003, and asked for confirmation and explanation.

The performance of shows a saw tooth formation, with some responses consistently longer than others. Matching up the response times with the corresponding server signatures actually does confirm that the responses served by Microsoft-IIS/6.0 are consistently longer than those served by Microsoft-IIS/5.0.

Analysing the response time graph more carefully shows that the connection time and time to serve the first byte are consistent across the two sets of servers, but the time to serve the complete request is significantly higher on the Microsoft-IIS/6.0 servers.

Response times in seconds from to 
London at Mid-day on 16 Jan 2003 by web server

It is important to appreciate that the difference need not be directly caused by the system software. Other plausible reasons could include;

  • The hardware specification of the Microsoft-IIS/5.0 machines may be faster than those running Microsoft-IIS/6.0
  • The configuration of the systems is likely to be different
  • From looking at the tcp/ip characteristics, we think it is likely that the front page is served dynamically, and  the migration of the application that generates the dynamic content may have introduced a performance penalty
  • The configuration of the local network at  Intel may have disadvantaged the Microsoft-IIS/6.0 machines in some way.

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.

Security Advisory 2001-01.1 – Predictable Session IDs

Vulnerable Products:

Java Application Servers based on Sun's reference implementation of the Java Servlet Developers Kit (JSDK 2.0), without enhancements to the session management code, may be vulnerable.

The following products are affected:

Other products may be vulnerable - vendors of such products should check their session management handling, based on the information given below or by contacting Netcraft for further information.

Not Vulnerable:

Products based on JSDK V2.1 (onward), which uses a different algorithm, or products that conform to the 2.x Java Servlet API but use custom session management code.


Hijacking of user sessions


Websites using vulnerable products as stated above

Revision history:

Released to Vendors: 6th November 2000
Public Release: 16th January 2001


Many websites support the idea of user sessions - each user connecting to the site is issued with a unique session ID, which is then used to identify all subsequent requests made by that user, either encoded in the URLs, or as a cookie. The server can then store data for each user session, for instance the state of a web shopping cart. Session IDs are also often used to control access to sites requiring a login; instead of sending the username/password with every request, the site issues a session ID after the user logs on, which identifies the user for the rest of the session.

With some server session management systems, it is possible for a user who can connect to the server and get a session ID, to guess other users' session IDs. If successful, the attacker can then view any page, take any action, post to any form etc, that the real user of that session could.

This attack requires no IP spoofing or session snooping. It works against sites using SSL. Netcraft has successfully proven this attack against machines using cookie-based and URL rewriting-based session management.


From a security point of view, the important properties of a session ID should be that it is unique, and it is not possible for one user to guess another user's session ID.

One way to ensure uniqueness is to include a session counter or timestamp in the session ID. In particular, for the sites we found to be vulnerable, the session ID included:

  • A session counter
  • The IP address of the server
  • A value made by combining the date, session counter, and current system time in milliseconds (we'll call this the timestamp)

This certainly appears sufficient to ensure uniqueness. However, if one user can get this information out of his session ID, he can clearly use it to guess other users' session IDs.

Encoding of Session IDs

For servers Netcraft has identified as vulnerable, the session ID is encoded using a simple rule. 5 bits at a time are taken from the binary session ID; these 5 bits form a number between 0 and 31. Numbers 0-25 are encoded with the corresponding letters A-Z; numbers 26-31 are encoded by the digits 0-5 respectively. It's a kind of "base32" encoding - which can be decoded trivially.

Here's a typical session ID being decoded:

$ echo -n "FGAZOWQAAAK2RQFIAAAU45Q" | ./ -d
29 81 97 5a 00 00 15 c8 c0 a8 00 01 4f 7e

This breaks up as: (all integers are in network byte order)

  • Bytes 0-3: Timestamp
  • Bytes 4-7: Session count
  • Bytes 8-11: IP address of the server issuing the session ID
  • Bytes 12-13: Random number (or zero, see below)

The Attack

We now know everything we need to try to hijack another user's session. The timestamp is always increasing, the session count simply increments, and the internal server IP address is constant. If we make two requests to the server, and the session count of the second request is more than 1 higher than the session count of the first, then we know that another session has started in between. We know also that the timestamp of that session will be between our two timestamps.

The two "random bytes" might have been a stumbling block, but:

  • The random bytes are not used by all servers, in which case they are zero.
  • For many servers tried, the random bytes are only generated when the server is started; they are the same for all user sessions.

For example, a couple of consecutive session IDs from a website might be something like this:

$ perl -e 'print "HEAD / HTTP/1.0\n\n"' | \
nc 80 | grep sessionid
Set-cookie: sessionid=FGAZOWQAAAK2RQFIAAAU45Q;path=/
SessionID gives: Thu Oct 12 12:34:06 2000,
session count = 5576, IP Address =
Extra = 4f (79) 7e (126)
$ perl -e 'print "HEAD / HTTP/1.0\n\n"' | \
nc 80 | grep sessionid
Set-cookie: sessionid=FGFLIHYAAALJVQFIAAAU45Q;path=/
SessionID gives: Thu Oct 12 12:38:44 2000,
session count = 5786, IP Address =
Extra = 4f (79) 7e (126)

Note that all session IDs in this report were obtained from real servers, but have been modified to avoid naming those servers. The name of the session ID is usually, but not always, "sessionid", "sesessionid", "JSESSIONID" or "jwssessionid".

The random extra bytes don't seem to be very random, but you do need to watch out for load-balanced servers, as each will have different counts and random elements.


Once an attacker has guessed another user's session ID, they have full access to that user's session (assuming the session ID is the sole identifier for session management and security purposes, which it is on many sites). If the service provides a means of "logging out", then the session ID is only useful until the real user logs out. Until then you can (typically) view any page, take any action, post to any form etc, that the real user can on the site. And the real user will be unaware of this (until some action you take has a visible result to the real user). Basically, it's very bad news.

Of course, the fact that the session IDs leak your internal IP addresses and, perhaps more importantly from the business point of view, the server's session count (easy way to track the popularity of competitors' sites) is in itself a cause for concern.

Testing Vulnerability

There are a large number of servers on the Internet using session ID cookies or URL re-writing encoded in this fashion. The easiest way to identify such sites is to find a page on the site which generates a session ID (often this is either the home page, or the page which processes logins), then make a few requests to this page, and compare the session IDs, looking for the incrementing session count.

Netcraft is reluctant to give a more exact test here, because it could lead to a false sense of security for administrators whose sites don't display the behaviour described above. Netcraft has seen some variations on the basic theme (e.g. some servers have longer session IDs than those described here, but the extra data appears constant).


  • There should be some real random input to the session IDs if they are to be used as the sole means of session tracking and management.
  • Any meaningful data being used in session IDs should be one-way encrypted. You shouldn't be trusting users to play fair with this information.

Recent versions of Sun's Java servlet code (from version 2.1) use a new session ID system, which includes a large random component. However, developers building application servers should enhance the code to make the session count inaccessible.

The Apache Tomcat project, starting with Tomcat version 3.2, uses a secure random number generator, and maintains uniqueness of session IDs without leaking the session count.

Vendor Patches and Comments


Bug numbers:

Dynamo 5.1, Dynamo 5.0 Patch 2 - Bug #29826
Dynamo 4.5.1 Patch 5 - Bug #25925
Dynamo 4.1.0 Patch 9 - Bug #31956
Dynamo 4.0.1 Patch 4 - Bug #31957
Dynamo 3.5.1 Patch 8 - Bug #32277

Versions affected:

Dynamo 3.5.1, Dynamo 3.5.1 Patch 1 through 7
Dynamo 4.0.1, Dynamo 4.0.1 Patch 1 through 3
Dynamo 4.1.0, Dynamo 4.1.0 Patch 1 through 8
Dynamo 4.5.0, Dynamo 4.5.0 Patch 1 through 5
Dynamo 4.5.1, Dynamo 4.5.1 Patch 1 through 4
Dynamo 5.0, Dynamo 5.0 Patch 1

Versions not affected:

Dynamo 5.1, Dynamo 5.0 Patch 2 and all future releases
Dynamo 4.5.1 Patch 5 and all future releases
Dynamo 4.1.0 Patch 9 and all future releases
Dynamo 4.0.1 Patch 4 and all future releases
Dynamo 3.5.1 Patch 8 and all future releases

Patch location:

Available to registered users in the support area on, under "Dynamo Patches".

Dynamo 5.1, Dynamo 5.0 Patch 2, Dynamo 4.5.1 Patch 5 are available as of 20th December, 2000.

Dynamo 3.5.1 through 4.1.0 patches should be available in mid-January 2001.


"With V2.x, we have always had hooks in the HttpSession support to allow applications to associate authentication information with a session and prevent access to that session if the right credentials are not provided. For customer applications who could not do this, we earlier this year provided a V2.x patch which further 'randomizes' the session ID, using a triple DES encryption ID generation algorithm.

With V3.x, we feel we have always prevented this issue - There is built in coupling between the HttpSession and WebSphere security, where authentication is automatically associated with the session and thus is used to prevent all unauthenticated access. One can review the WebSphere documentation to review all the various means available for securely maintaining this authorization."

E-fix PQ47663 is now available for version 3.02 and 3.5.x of WebSphere. For version 2, ask WebSphere support for the "version 2 HttpSession ID randomization change".

Sun Microsystems

For Java Web Server 1.1.1 or 1.1.2, first upgrade the Java Web Server and than install the appropriate patch:

Version 2.0 Patch 4

Version 1.1.3 Patch 4

Patches available from


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.


For more information on Netcraft security services, please see