tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Gregory" <Rob.Greg...@ibsolutions.com>
Subject RE: Tabbed browsers sharing session - work around.
Date Tue, 05 Oct 2010 09:03:49 GMT
Chris,
See comments below:-

> Rob,
> 
> On 10/4/2010 7:27 AM, Rob Gregory wrote:
> > Using the hostname doesn't really guarantee a unique session for example
> > if I click new tab and paste the URL into the new window I suspect the
> > browser will see the same session from the first tab.
> 
> Note that you haven't changed the hostname in this case: you've just
> cloned a browser window (or "tab" if you prefer to call it that).
> 
> > In our application
> > the user can then change the environment with disastrous consequences
> > when updating the database.
> 
> Sounds like you need to be pretty careful. Is it possible you've built a
> fragile application?

Some legacy parts of the application became fragile when the browsers started sharing sessions
and this fix has been implemented to work around that fact.

> 
> > Did you implement anything to stop the
> > session sharing at this level. What I did was to use the window.name
> > attribute to allow tracking of browser instances and compare this when
> > doing the session timeout checking and this way I am able to redirect
> > any further browser opens into new sessions.
> 
> That's pretty fragile: relying on client-side javascript for anything
> security-related is very foolish.

I do not rely on javascript for security, it is used to provide a means of tracking open browser
sessions.
The worst a client could do would be to remove the window.name which would result in a new
session being generated. 

> 
> > With the exception of WEB-INF (which was due to tomcat no longer seeing
> > that as a WEB-INF call because I have my unique-id in the path) do you
> > see any security faults in what I am doing?
> 
> Many: disabling javascript on the client side will break your security.
> An attacker overriding the javascript will break your security.

The application has been security audited and after fixing a few issues is now very much secure.
Disabling javascript wouldn't break the security model but we do require javascript to be
enabled for correct functionality. 

To clarify I do not rely on javascript for anything security related and purely use this as
a means of detecting the user has an existing browser window open. The window.name property
is the only way to determine unique browser instances at the moment and even this is flawed
if the browser is opened by a hyperlink containing a named target! I think browser manufacturers
need to address this issue and provide some unique identification between browser requests.
Until then I have no choice but to work-around this session sharing.

Thanks again for your input,
Rob

> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkyqDOQACgkQ9CaO5/Lv0PBbSACfVhscYMSd4q13ivnaz4k6LdeQ
> ZmgAoKSUg6VkjFxyFr47j1260++fjhre
> =ct/x
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org

Mime
View raw message