Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

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

by hackmare (Pilgrim)
on Feb 04, 2002 at 12:06 UTC ( [id://143215]=perlmeditation: print w/replies, xml ) Need Help??

This is not a perl problem per say, but has some profound security consequences on perl cgi scripts which use the session id to authenticate a user (such as any password-enabled page)

Subject: netscape 6.x browser wrecks session tracking framework for CGI scripts which use the session ID to identify a given user session.

Here's the short of it:

One of the features of NS6.X is that it has a workaround to circumvent the slow loading of the application on your desktop which keeps NS running on the background. This effectively causes NS to start on launch of the OS (or at least in windows).

Here's the problem:

Aas long as windows is up, even if you close NS, it remains active in the background. This means that any authentication you have performed on any sites you are using are still valid unless other authentication tokens such as inactivity are used.

So what does this mean to me, the perl coder?

Well, this means that as long as the machine is not rebooted, all password-protected sites the user has accessed are available to anyone who uses the machine, even if the user has shut down their browser. This means that on the script side, we can not assume that the session ID means anything anymore when parsing security tokens. let's face it, there are plenty of users out there that leave their PCs unattended for a little while. And since most machines stay on indefinitely, this means that it is reasonable to assume that we can not assume that the sessino ID is valid any more at all since it may span months.

And this means that NS6.X is self-dooming to stay off the enterprise system architecture for now as this is too much of a security bug.

Workaround?

All I can think of as a workaround is to add time-dependent tracking to all security, and to make the time-to-live of the cookie as short as possible. Of course, both these options have always existed,

What's he talking about?

Whenever you authenticate (log in) into a site, a cookie is placed on your browser that it passed through automatically and is used by the server to verify tha you are not being spoofed by another machine. This simple authentication cookie is based on the session ID of your browser, or a unique string randomly generated by the browser on launch. With NS6.x, as long as your OS is up, that session ID does not change, no matter how many times you close NS.

Further reading:

Here's an article on session management using perl

Replies are listed 'Best First'.
Re: CGI security problem:Netscape 6.X: browser session security weakness in client
by derby (Abbot) on Feb 04, 2002 at 13:56 UTC
    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

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

Re: CGI security problem:Netscape 6.X: browser session security weakness in client
by AidanLee (Chaplain) on Feb 04, 2002 at 14:04 UTC

    Something else to consider is that you also don't want your session to be *only* time-based. People (using non N6 browsers) expect that when you close your browser, the session goes away. The fact that if you add an expire date to your cookie, you can't *also* have it destroyed when the browser is closed. So you may want to consider (as I have) a two pronged session:

    1. A cookie that expires in a given time frame (~20 min is good)
    2. A cookie with no timestamp, which the browser understands is to be destroyed when the last browser window is closed (except, as hackmare notes, on N6)

    This requires the user to have both cookies to have a valid session.

    It would also probably be worthwhile to point this issue out to the Mozilla crowd. They could possibly patch the browser to clear the session cache out when all windows are closed.

Re: CGI security problem:Netscape 6.X: browser session security weakness in client
by thraxil (Prior) on Feb 04, 2002 at 15:21 UTC

    the great thing about open source projects is that they often fix problems that they know about (unlike certain other software companies). so why not submit a bug report?

    anders pearson

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://143215]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (5)
As of 2024-03-28 12:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found