One little-known feature of the Java Servlet Spec allows for encoding session identifiers in URLs. In theory, this allows browsers without support for cookies to maintain session state with your website. In practice, however, there are several problems with this approach:

Every link on your site needs manual intervention

Cookieless sessions are achieved in Java by appending a string of the format ;jsessionid= SESSION_IDENTIFIER to the end of a URL. To do this, all links emitted by your website need to be passed through either HttpServletResponse.encodeURL() , either directly or through mechanisms such as the JSTL <c:out /> tag. Failure to do this for even a single link can result in your users losing their session forever.

Using URL-encoded sessions can damage your search engine placement

To prevent abuse, search engines such as Google associate web content with a single URL, and penalize sites which have identical content reachable from multiple, unique URLs. Because a URL-encoded session is unique per visit, multiple visits by the same search engine bot will return identical content with different URLs. This is not an uncommon problem; a test search for ;jsessionid in URLs returned around 79 million search results.

It's a security risk

Because the session identifier is included in the URL, an attacker could potentially impersonate a victim by getting the victim to follow a session-encoded URL to your site. If the victim logs in, the attacker is logged in as well - exposing any personal or confidential information the victim has access to. This can be mitigated somewhat by using short timeouts on sessions, but that tends to annoy legitimate users.

What you can do

For the vast majority of web sites, requiring cookies to store session state is not a major problem. It is probably safe to disable URL-based sessions entirely. At a bare minimum, session identifiers need to be hidden from search bots to avoid the repercussions detailed above. Unfortunately, the servlet spec does not provide a standard way to disable the use of URL-based sessions and many servlet containers do not provide a mechanism to disable them either.

The solution is to create a servlet filter which will intercept calls to HttpServletRequest.encodeURL() and skip the generation of session identifiers. This will require a servlet engine that implements the Servlet API version 2.3 or later (J2EE 1.3 for you enterprise folks). Let's start with a basic servlet filter:

package com.randomcoder.security;

import java.io.IOException;

import javax.servlet.*;
import javax.servlet.http.*;

public class DisableUrlSessionFilter implements Filter
{
  public void doFilter(
      ServletRequest request,
      ServletResponse response,
      FilterChain chain)
  throws IOException, ServletException
  {
    // TODO add filter logic here
  }

  public void init(FilterConfig config)
  throws ServletException {}

  public void destroy() {}
}

We don't need to be concerned with the init() and destroy() methods; let's focus on doFilter() . First, let's exit quickly if for some reason the current request is non-HTTP, and cast the request and response objects to their HTTP-specific equivalents:

if (!(request instanceof HttpServletRequest))
{
  chain.doFilter(request, response);
  return;
}

HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;

Next, let's invalidate any sessions that are backed by a URL-encoded session id. This prevents an attacker from generating a valid link. Just because we won't be generating session-encoded links doesn't mean someone else won't try:

if (httpRequest.isRequestedSessionIdFromURL())
{
  HttpSession session = httpRequest.getSession();
  if (session != null) session.invalidate();
}

To disable the default URL-encoding functionality, we need to wrap the existing HttpServletResponse object. Fortunately, the Servlet API provides just such a class ready-made in HttpServletResponseWrapper . We could subclass it to provide our own handling, but this is a trivial enough change that an anonymous inner class will do nicely:

HttpServletResponseWrapper wrappedResponse
    = new HttpServletResponseWrapper(httpResponse)
{
  public String encodeRedirectUrl(String url) { return url; }
  public String encodeRedirectURL(String url) { return url; }
  public String encodeUrl(String url) { return url; }
  public String encodeURL(String url) { return url; }
};

You may notice that we have overridden four methods, not one. encodeRedirectURL is used to encode redirected URLs, which can sometimes require different logic to determine if session identifiers are required. The other two methods are deprecated, but are included here for completeness.

Finally, we need to pass the original request and our response wrapper to the next filter in the chain:

chain.doFilter(request, wrappedResponse);

Our servlet filter is now written, but we still need to tell our servlet container about it. For this, we need to add the following to web.xml :

<filter>
  <filter-name>
    DisableUrlSessionFilter
  </filter-name>
  <filter-class>
    com.randomcoder.security.DisableUrlSessionFilter
  </filter-class>
</filter>

...

<filter-mapping>
  <filter-name>DisableUrlSessionFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

This registers our filter with the servlet container, and maps it to all requests. For best results, the filter mapping should be placed above any other filter mappings to prevent any calls to encodeURL from slipping through.

Resources

• DisableUrlSessionFilter.java
• web.xml

Update: This site offers some additional advice using mod_rewrite. Thanks, Darren!

Update: Fixed reference to encodeUrl(). As pointed out below, this is found in HttpServletResponse, not HttpServletRequest.