Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Problem with JSessionId

The Problem with JSessionId

An article on looks at the negative aspects of using the jsessionid technique for cookieless sessions in Java web applications. A Google search for "JSessionid" reveals sites such as Sun's Download Center using the technique. The article points a number of issues with doing so:
  • Every link must be generated with HttpServletRequest.encodeURL() or mechanisms such as a JSTL tag
  • Search engines penalize sites which have identical content from multiple unique URLs
  • The session is more easily spoofed by hackers
In response to this the author recommends requiring cookie support to store sessions. The article includes an example servlet filter to prevent the generation of session identifiers on urls.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Well ...

    by Dorel Vaida,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    o Every link on your site needs manual intervention

    Instead of writing the links as or whatever you'd easily write a custom tag which would append that jsessionid token to your URL.

    o Using URL-encoded sessions can damage your search engine placement ... and penalize sites which have identical content reachable from multiple, unique URLs. Well if it does that it's not that smart isn't it because they all know about JSESSIONID isn't it, and we all know that is not part of the useful information on a site. It should take into acount the web address and the query string. Or not ?

    o It's a security risk

    From what I know, being in the URL or as a cookie, any information is easy to read by a "man in the middle" if it's not encripted or if it's not transported over a secured channel (HTTPS).

    Now that's a tough one :-)

    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; }

  • Re: Well ...

    by dfg gd,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    1/ Tag for add jsessionid: Exact, most taglib does that very well.

    2/ The content *may* be different for different query string. So a search engine must take it into account.

    3/ If I navigate from a site to another, the previous query string is send, not the cookies. So it is different. If you are on and you navigate to, can now your sessionId, but not your cookies.

  • User awareness of url power

    by Marek Pulka,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    With url encoded session you should also make your non technical users aware of security risks of copying and pasting web pages/web page fragments to emails (as html). Every link in copied html with url encoded session is an opened door do web app. The door will often close after some time but email recipient may be quick.

    The story:
    Non technical manager of online store emails customer his purchase history/stats. Purchase history is copied and pasted from admin app. Customer only complains that system is insecure but he could be more evil ]:->

    For us it's obvious that such action is equal to give someone access to your session and authorize him to do everything you can do in web app, but it's not so obvious for nontechnical users.

    User unawareness is problem here but with session encoded in cookie (or another place like form hidden field) this security risk can be avoided.

  • Spoofing and security issues

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Spoofing has two sides: Trying to find a legitimate JSESSIONID, and trying to use someone else's existing JSESSIONID.

    The first (in a reasonable implementation) is no more difficult than breaking any cryptographic code. For example, a 16-character JSESSIONID employing just A-Z, a-z and 0-9 provides 47,672,401,706,823,533,450,263,330,816 combinations, meaning that with one million logged on users (i.e. one million legit JSESSIONIDs that could be found) and an attack rate of 100 unique JSESSIONIDs per second, it would take over seven trillion years on average to find a legitimate JSESSIONID.

    The second (again, in a reasonable implementation) should be prohibited based on other characteristics of the client connection, such as the IP address. While IP spoofing is theoretically possible, the ability to both grab a JSESSIONID while it is valid _and_ spoof an IP address is a pretty big task.

    The exception is when the attacker is behind the same NAT firewall as the victim, in which case the ability to grab a JSESSIONID is likely easy _and_ the IP address of the attacker is automatically the same IP address as the victim. There is no way to protect against this case except by explicitly requiring a persistent HTTPS connection in concert with the use of JSESSIONID.

    As a general rule of thumb, it is good to default to cookies, and only switch to JSESSIONID URL encoding when cookies are not supported, and only if the above considerations (and those listed elsewhere in this thread) do not apply.


    Cameron Purdy
    Tangosol Coherence: Clustered Replicated and Partitioned Caching

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p