The Problem with JSessionId

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

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 mysecuresite.com?jsessionid=123 and you navigate to evilsite.com, evilsite.com can now your sessionId, but not your cookies.

3/
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 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.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Replicated and Partitioned Caching