Re: CGI security problem:Netscape 6.X: browser session security weakness in client

hackmare,

I don't consider this any more of a security risk than any other long running browser. All good session tracking should take into account inactivity. All good security-consience apps should never expose private information based on cookie values alone. It's one thing to show XXXX-XXXX-XXXX-1234 for credit card numbers based on cookie info, it's quite another to allow that value to be changed or allow shipping addresses to be changed based on cookie values alone - when dealing with private info always force re-authentication

Also, you're just asking for trouble if you're using a random string generated by the browser for session ids (is this even true?). You, as a web programmer, have no control over that number (bad thing) and run the risk of session id collisions (very bad thing). All good apps would generate their own session id and send that back to the browser via cookie (and via URL mangling just in case the user will not accept cookies).

Now can someone still hijack a session? You bet your life they can. It's just a reality of the biz and will always be that way. Can you do a lot to make that more difficult - Absolutely. MD5'ed sessionids can help tremendously - forcing re-authentication when displaying or allowing changes to private information is a must and never relying on browser generated info is a commandment.

Since you can never depend on a user exiting the browser in the first place - this behaviour with NS6.X should not throw any web dev into a tizzy.

-derby

Comment on Re: CGI security problem:Netscape 6.X: browser session security weakness in client

Replies are listed 'Best First'.

Re: Re: CGI security problem:Netscape 6.X: browser session security weakness in client
by hackmare (Pilgrim) on Feb 06, 2002 at 01:18 UTC

I do not see the problem with NS6.X as a strength of authentication issue as much as an issue in user psychology and compatibility with user behaviour. When users shut down their program, they think that the program is done (this is the basic assumption of all users, helped by years and years of GUI design, which did not maintain state, and which had the program non-functional when turned off). If it turns out that the program did not shut down and it cost the user piles of money, then we get blamed for the poor programming. If there is too much risk of this happening to be financially worthwhile for our mployers/clients, then we feel negative consequences.

And let's say we set a go-stale limit of 30 minutes. Is that good enough? Would you leave your webmail account open for 30 minutes on a public server? Whad will you do if you go to a public machine, it uses NS6.1, and you don't have reboot authorization? Is this not a problem for you? What about your online banking app? Granted, these apps usually have logout functionality, and we should use that more than we do.

I guess that training the users to use the logout functionality will now be really important.

When a user shuts down their NS6.1 session on a public access machine, for example, and goes home, then the browser is still active and the next user has full access to the password-protected content. This is nothing but more work for all of us.

The problem we are facing here as web designers is that if we force users to reauthenticate too often they get irritated, and if we wait too long then we are at risk from people borrowing their access rights on the machine. So we train them to turn off their browser when they are done as a way for them to ensure that the session is closed. Now it turns out that when you shut down NS, it doesnt shut down and keeps all your active session information in ram until the hardware is rebooted.

This is a new security problem for us. We now have a piece of software that acts contrary to accepted behaviour of stopping when being closed by the user.

Considering that this functionaltiy seems to have been added in response to the slow startup time of the mozilla code is at the very least ironic!!

[reply]