Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Mitigating Static Session ID on WebLogic 12c application

 
Ranch Hand
Posts: 217
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there a fix on the server side which can be applied to WebLogic 12c which will take care of a Static Session ID vulnerability?
 
Saloon Keeper
Posts: 24517
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I haven't run WebLogic recently enough to be certain that they don't have some sort of feature I don't know about, but I can tell you what happens in Tomcat for comparison.

Tomcat uses jsessionid as its way of managing HttpSessions. It is passed back and forth between client and server on every session-related web request and can be passed either as a cookie or - if cookies are not possible - via URL rewriting.

The jsessionid value is a "random number". That is, it serves as a hash key to locate the specific client's HttpSession object in Tomcat's HttpSession collection. There is no meaningful information in the jsessionid itself.

More importantly, it is not a static ID. You cannot safely cache a jsessionid even between closely-spaced request/reponse cycles. The client must always request using the jsessionid returned from the previous response.

Why I give no guarantees that Tomcat won't change the jsessionid value at random moments just for the fun of it, the one time when it will definitely change is when you switch from HTTP to HTTPS. That means that you cannot steal a jsessionid from an unencypted request and use it to make a secured (encrypted) request. And if you are making encrypted requests using cookies, the new jsessionid is encrypted just like all the other cookies are and thus cannot be seized and used by an attacker. Unless they've managed to break encryption. In which case, you're doomed anyway.

Since the jsessionid is just a hash key with no inherent meaning, changing the key simply changes the hash value for finding an HttpSession and doesn't affect the HttpSession itself.

As far as I'm aware, all JEE servers have this strategy - or should! So the issue of the session ID being static shouldn't apply to JEE servers. At least if "static session ID" means HttpSession key.
 
reply
    Bookmark Topic Watch Topic
  • New Topic