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

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

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.