6

I manage a couple of twitter accounts for businesses/websites that are separate from my personal account. For simplicity, I prefer to log in from an incognito window so that I don't need to log out of my primary (personal) twitter account.

I was shocked when I recently logged into one of the secondary accounts in an incognito window, closed the window, and later was logged into that secondary account when visiting twitter in the non-incognito main window.

I did some testing, and found that the auto-login occurs regardless of whether I'm currently signed in to twitter or not in the main browser session, any time I sign in via the incognito window. If I leave the incognito window open and log into a different account, the primary browser session also switches to that twitter account.

After some additional poking around, I decided to disable any extensions I had enabled in incognito mode, to determine if that was related. The problem disappeared with all extensions disabled. The only 2 extensions I had given permission to operate in incognito mode were Adblock and HTTPS Everywhere. I enabled each of them individually, and the problem only occurs when HTTPS Everywhere is enabled. I further established that the problem only appears to happen on Twitter. Logging into a different Facebook, Gmail, or Reddit account in incognito mode (with HTTPS Everywhere enabled) did not affect the login status in the primary browser session.

Obviously, this is a security concern, especially for a privacy-oriented extension to be leaking session data. Specifically, I am wondering:

  • How does HTTPS Everywhere help Twitter escape the incognito mode "sandbox"?
  • Why does this happen with Twitter but no other sites?
  • In what ways could a malicious website exploit this bug to steal or alter user credentials?

Note: this does not happen in Firefox using Private Browsing Mode with HTTPS Everywhere enabled.

nhinkle
  • 203
  • 1
  • 9
  • Note: I just found this related question, http://security.stackexchange.com/q/39898/, however the OP there was using a non-standard 3rd-party build of Chromium, and is ultimately asking different questions about the same problem. – nhinkle Feb 11 '14 at 05:45

2 Answers2

6

I'm the maintainer of HTTPS Everywhere and just merged a pull request fixing this issue. It should be in the next release (out in 1-2 weeks). For future reference, submitting these to Github means they'll get fixed sooner :). (https://github.com/efforg/https-everywhere)

Yan Z
  • 136
  • 6
  • 1
    I actually did submit it to Github - see my original answer below in which I said "I have resubmitted the bug report to the project's GitHub bug tracker". Thanks for fixing the issue and letting us know about it! – nhinkle Apr 05 '14 at 07:49
  • 1
    @nhinkle Indeed! I saw it a while back but was behind on merging until now. – Yan Z Apr 05 '14 at 20:03
4

I found an HTTPs Everywhere bug report explaining why this happens:

This appears to be an Chrome API bug. We're getting the onCookieChanged event, and the cookie we get in that event has a storeId of 0 regardless of where it comes from (Incognito or not). We then turn right around and set the secure flag on the cookie and issue a cookies.set(cookie). Since the storeId is still the default store, the cookie leaks to normal mode.

It's not clear why it seems to happen to some sites and not others, but other sources on the web have confirmed that the problem appears reliably with Twitter. It's possible that HTTPs Everywhere only modifies the cookie if the secure flag isn't already set, and that other major websites are setting the secure flag on their cookies already, while Twitter is not. Additional research on this would be welcomed.

I have resubmitted the bug report to the project's more-used GitHub bug tracker, and included a recommendation to detect incognito mode and not rewrite cookies when operating in incognito mode.

nhinkle
  • 203
  • 1
  • 9