Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

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 ( #143516=note: print w/replies, xml ) Need Help??


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

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.

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!!

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://143516]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (4)
As of 2020-02-19 00:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What numbers are you going to focus on primarily in 2020?










    Results (80 votes). Check out past polls.

    Notices?