Grails

Remove JSession ID: it's a security risk and creates many practical issues

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.0.3
  • Fix Version/s: 1.1-beta1
  • Component/s: None
  • Labels:
    None

Description

I'd like to disable URL-based sessions completely, for a variety of reasons – both security (please – hijack my session! Just go to this URL!) and practical (hoses up my webtests by mangling URLs).

In order to do this, I did a "grails install-templates", and then edited ./src/templates/war/web.xml to implement the filter supplied at "http://randomcoder.com/articles/jsessionid-considered-harmful" (which also has a nice summary of issues associated with it, and good comments).

I asked if I should package this as a plugin, and Marc Palmer suggested JIRAing the whole JSessionID idea, since it's a relatively new addition and it has so many fundamental problems. He statement was – "It has caused me nothing but trouble also - for example you have to strip it when generating links to feeds. "

So, the request is to remove the JSessionID functionality completely, or at least to default to it being off and forcing users to turn it on explicitly.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Robert Fischer added a comment -

Adding this to web.xml:

<context-param>
<param-name>org.mortbay.jetty.servlet.SessionURL</param-name>
<param-value>none</param-value>
</context-param>

Just gives you this tacked to the end of your URLs:

";none=fokgrnvhr037"

So the filter[1] is necessary in Grails.

[1] http://randomcoder.com/articles/jsessionid-considered-harmful

Show
Robert Fischer added a comment - Adding this to web.xml: <context-param> <param-name>org.mortbay.jetty.servlet.SessionURL</param-name> <param-value>none</param-value> </context-param> Just gives you this tacked to the end of your URLs: ";none=fokgrnvhr037" So the filter[1] is necessary in Grails. [1] http://randomcoder.com/articles/jsessionid-considered-harmful
Hide
Permalink
Mingfai Ma added a comment -

-1
Jetty configuration should do the job. It works in my environment to disable URL rewrite created with response.encodeURL. Perhaps we need to update to the latest Jetty 6 library.

for reference:
http://grails.markmail.org/search/list:user#query:list%3Auser+page:2+mid:ciesjb4enyfghezz+state:results
http://grails.markmail.org/search/list:user#query:list%3Auser+page:1+mid:t6z3zveg5x6m5ro6+state:results

Show
Mingfai Ma added a comment - -1 Jetty configuration should do the job. It works in my environment to disable URL rewrite created with response.encodeURL. Perhaps we need to update to the latest Jetty 6 library. for reference: http://grails.markmail.org/search/list:user#query:list%3Auser+page:2+mid:ciesjb4enyfghezz+state:results http://grails.markmail.org/search/list:user#query:list%3Auser+page:1+mid:t6z3zveg5x6m5ro6+state:results
Hide
Permalink
Robert Fischer added a comment -

@Mingfai

What's your environment? I'm on a standard Grails 1.0.3 install.

And what are you doing to disable URL rewrite? Anything more/different than adding that context param into web.xml[1]?

And have you tried generating a link with <g:createLink>? That's where I'm getting ";none=fokgrnvhr037".

[1] http://jira.codehaus.org/browse/GRAILS-3364?focusedCommentId=147262#action_147262

Show
Robert Fischer added a comment - @Mingfai What's your environment? I'm on a standard Grails 1.0.3 install. And what are you doing to disable URL rewrite? Anything more/different than adding that context param into web.xml[1]? And have you tried generating a link with <g:createLink>? That's where I'm getting ";none=fokgrnvhr037". [1] http://jira.codehaus.org/browse/GRAILS-3364?focusedCommentId=147262#action_147262
Hide
Permalink
Jason Morris added a comment -

+1, but it needs to be something that is optional (for those who wish to keep it), and ideally more granular than on/off.

For example, I generate a sitemap.xml with a GSP, which uses <g:link> tags, and that means that GoogleBot etc (which don't use cookies) get the jsessionid appended to the URLs. Not good.

I had to create my own version of the <link> tag that calls g.link(), checks the user-agent header to identify search engines, and then strips the jsessionid if it is a search engine. It would be much cooler if I could control that through Config.groovy or similar, and have <g:link> etc respond accordingly.

I would say you need to be able to switch it on/off globally; for Search Engines only; or for specific pages (e.g. sitemaps) only.

Show
Jason Morris added a comment - +1, but it needs to be something that is optional (for those who wish to keep it), and ideally more granular than on/off. For example, I generate a sitemap.xml with a GSP, which uses <g:link> tags, and that means that GoogleBot etc (which don't use cookies) get the jsessionid appended to the URLs. Not good. I had to create my own version of the <link> tag that calls g.link(), checks the user-agent header to identify search engines, and then strips the jsessionid if it is a search engine. It would be much cooler if I could control that through Config.groovy or similar, and have <g:link> etc respond accordingly. I would say you need to be able to switch it on/off globally; for Search Engines only; or for specific pages (e.g. sitemaps) only.
Hide
Permalink
Robert Fischer added a comment -

My main concern is security (with practicality coming in second). Anyone sharing a link with your JSessionID in it are basically handing away their session. Users simply aren't savvy enough to avoid doing this[1], so you're basically asking for trouble by allowing the user to do this. And it's something that's easy enough to overlook if you're using a browser with cookies enabled for testing – I certainly overlooked it until I started doing webtests and it broke my XPath.

Given all this hassle, the JSessionID should at least default to off in Grails.

[1] http://twitter.com/broady/statuses/912809606

Show
Robert Fischer added a comment - My main concern is security (with practicality coming in second). Anyone sharing a link with your JSessionID in it are basically handing away their session. Users simply aren't savvy enough to avoid doing this[1], so you're basically asking for trouble by allowing the user to do this. And it's something that's easy enough to overlook if you're using a browser with cookies enabled for testing – I certainly overlooked it until I started doing webtests and it broke my XPath. Given all this hassle, the JSessionID should at least default to off in Grails. [1] http://twitter.com/broady/statuses/912809606
Hide
Permalink
Graeme Rocher added a comment -

jsessionid now disabled by default in Grails 1.1. To re-enable set

grails.views.enable.jsessionid=true

In Config.groovy

Show
Graeme Rocher added a comment - jsessionid now disabled by default in Grails 1.1. To re-enable set grails.views.enable.jsessionid=true In Config.groovy
Hide
Permalink
Robert Fischer added a comment -

Thank you very much for fixing this.

Show
Robert Fischer added a comment - Thank you very much for fixing this.
Hide
Permalink
Gerhard Stuhlpfarrer added a comment -

i have a usecase where i have to deal with clients which do not accept cookies, so i reenabled the jessionid in a grails 1.1.1 application as described above.
This works as expected with jetty, the jessionid is appended to the url if the client does not accept cookies.
But there seems to be a problem with this feature in combination with tomcat 5 and 6, there is always a new session created ...

To reproduce create a new grails project with a single domain and generate-all, war and deploy to tomcat.
Then try some crud operations (with a client where cookies are disabled!) on the deployed app and you will see that the jsessionid is changing from one page to another.

For verification purpose i tried the same with grails 1.0.4 -here it works as expected...

Show
Gerhard Stuhlpfarrer added a comment - i have a usecase where i have to deal with clients which do not accept cookies, so i reenabled the jessionid in a grails 1.1.1 application as described above. This works as expected with jetty, the jessionid is appended to the url if the client does not accept cookies. But there seems to be a problem with this feature in combination with tomcat 5 and 6, there is always a new session created ... To reproduce create a new grails project with a single domain and generate-all, war and deploy to tomcat. Then try some crud operations (with a client where cookies are disabled!) on the deployed app and you will see that the jsessionid is changing from one page to another. For verification purpose i tried the same with grails 1.0.4 -here it works as expected...

People

Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.1#660-r161644) | Report a problem
Powered by a free Atlassian JIRA open source license for Grails project. Try JIRA - bug tracking software for your team.