Uh-Oh: Firefox’s Unique Session Cookie Behavior

By now, Opera’s invention of restoring tabs automatically is available in most browsers, but unlike every other browser, Firefox’s restored tabs retain session cookies for the domains of the saved tabs Firefox restores all session cookies as if the browser were never closed. This is handy in some ways, but dangerous in others:

It’s fooling web developers by breaking a very old and widely-known convention. Since Netscape’s original spec (around 1994) a cookie with an empty/missing expires was to be discarded “when the user’s session ends” (later clarified as “when the user agent exits” in RFC2109), and thousands of prominent web pages describe “session cookies” this way.

A common session design pattern uses a persistent cookie to establish low-level identity info and a session cookie for full authentication. Developers may not know that their full auth period may be lasting days or weeks, including trips to insecure wifi spots, browsing by multiple users, etc.

It’s fooling users. No one thinks of a single browsing “session” as encompassing several days of browser usage just because the same tabs were open, and users frequently read that they need to simply exit their browser to ensure their session is ended.

Recommendations

  • Be aware that Firefox session cookies can linger for days, despite the user having closed their browser.
  • Manage session timeouts on the server-side and/or via HMAC-signed timestamp values in the cookie contents (don’t let the client decide how long a session should last).
  • If you can, include secure in the cookie header. Firefox does not restore HTTPS session cookies. Realize that in later FF versions, “secure” cookies also are restored.
  • If you give out session cookies with unique names, have your application clean these up when they’re no longer needed. If you don’t, your Firefox users could suffer from…

Cookie Accumulation Torment

This annoying situation occurs when Firefox gains so many local cookies that the web server begins to deny all your requests. Deleting some or all these cookies is the only way to fix the issue because—yay—the problem session cookies persist across browser, and even OS, restarts.

Big Shibboleth Implications

If your Shibboleth-authenticating app maintains its own session, make sure that the “sign out” function searches for and deletes the local Shibboleth cookies (or that the SP sets only “secure” cookies). Otherwise this could happen:

  1. Jane “signs out”, closes Firefox, and lends her computer to Sally.
  2. Sally opens Firefox and clicks “sign in”.
  3. Sally is instantly authenticated into Jane’s account!

Jane’s application session was over, but Firefox allowed her Shibboleth session to live on.

Also, since Shibboleth gives out uniquely-named session cookies (prepended with _shibstate), failing to clean these up will lead Firefox users to the aforementioned torment. If the user has an app open all day every day, count on her gaining at least one cookie per day.

1 thoughts on “Uh-Oh: Firefox’s Unique Session Cookie Behavior

  1. Patrick says:

    I am interested in your Shibboleth Elgg plugin. I am curious where you left it and how much work would be required to get it to production.

    I ask as I require a SSO solution between an Elgg and Joomla and a TBD custom shopping cart solution. It may also require InfusionSoft integration.

    Feel free to contact me.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.