1

For chrome and android stock browser, JSESSIONID cookie parameter are not removed even on browser close. As most of the websites are tracking customer session with JSESSIONID cookie which is having expire time of session, is not being removed from browser memory even browser closes.

Due to that, when we are accessing the webpage again, first request is sent with existing session cookie value.

If application is running with multiple servers for load balancing, request is sent to same server all the time. Is there any solution to solve the issue?

Reference Link : Cookie issue

Srini
  • 348
  • 1
  • 2
  • 17
  • I edit my question. If request is sent with out any existing session cookie, server is randomly pickup based on load availability. This is not happening if first request is sent with existing session cookies. – Srini Apr 24 '15 at 18:35
  • 1
    What kind of load balancer do you use? Maybe it is possible to configure it in a way to discard expired session cookies? ... I just realize that the cookie expiration date is unfortunately not sent with an HTTP request :-/ – tiguchi Apr 24 '15 at 18:37
  • This is a security issue with latest stock and chrome browsers. If user close the webpage or application without properly logoff, customer jsessionId is exposed and leads to vulnerability issue. To avoid that, we are trying to remove the session cookie on browser close. It is properly taken care by other browsers link opera, safari, firefox.. but not in chrome browsers. – Srini Apr 24 '15 at 18:41
  • I see, however you also need to make sure your backend is secure and it must not act on an expired session ID. As a workaround you could set an additional cookie that specifies the session expiration date. If possible try to configure the load balancer to validate the expiration date. If it determines that the session expired you can let the load balancer strip out the session cookie from the request, if possible. – tiguchi Apr 24 '15 at 18:44
  • 1
    As a safety measure we can remove jsession ID manually on every page launch. But ideally, manual modification of jsession ID is not advisable. With the above issue, if user is connected with one server, on every launch same server connection is established. If the particular server is down, there is a possibility of impact for the user. As generic solution for both security flaw and load balancing, session cookie needs to be cleared on browser close. Please provide any generic solution to achieve this. – Srini Apr 24 '15 at 18:54
  • I will try the possibility of removing jsession id on every launch of the webpage. It would be great if there is any generic approach to remove session cookie on browser close without having any manual modification of session specific cookies. – Srini Apr 24 '15 at 19:00
  • 1
    I believe you are trying to solve the core issue from the wrong end. You cannot trust user input. A cookie with a session ID is user input that can be arbitrarily crafted. Your back end must make sure that all user input meets your expected criteria. One criteria is that session IDs must not be expired. So instead of trying to let the browser (user client) discard expired session cookies, your backend must discard expired session _data_. If you are using JSP tech then read the following SO answer: http://stackoverflow.com/questions/14445024/how-to-validate-invalidate-sessions-jsp-servlets – tiguchi Apr 24 '15 at 19:15

1 Answers1

1

As this is known security bug in latest browsers, issue is getting resolved by removing session cookies manually on every launch of the application.

Even if the server is already taken care of expired session, connection establishment with server needs to be dynamic based on load availability in each server. As server name also stored in cookie and this value is not removed even browser / application is getting closed, first request on every application launch will connecting to the same server which is connected earlier.

Because of this, load balancing is getting failure because of unremoved cookies.

Eventhough this is technically reliable workaround, i hope in upcoming chrome browser versions will resolve this issue permanently similar to safari/IE browsers.

If anyone find out permanent solution, please share your findings as well.

Srini
  • 348
  • 1
  • 2
  • 17