Is something filtering 'document.cookie' in SO pages?

Question

My colleague and I are developing an annotation tool for web resources. One way The user can us the tool is to click a special bookmarklet to view the current page with annotations added. The bookmarklet works by sending the current page URL and the cookies for the page to a "page repeater" server, which fetches the real page (using the cookies) and modifies it to inject the javascript infrastructure for displaying annotations.

Today, we discovered that the page repeater doesn't work properly for StackOverflow pages. It seems that when the bookmarklet calls "document.cookie" to get the cookies for an SO page, it doesn't get all of the SO cookies. In particular, the "usr" cookie is missing. The net result is that the user appears to be not logged in.

There is nothing special about the "usr" cookie as far as we can tell. It is present in the browser's cookie store. It has the right domain and path, it is not marked as "secure", it has not expired, it doesn't have an overly long value. It just doesn't show up in the Javascript document.cookie property with the rest of them.

We've reproduced this on both Firefox 3.6. and the latest Chrome.

Can anyone explain what is going on?

Answer 1

The StackExchange "user" cookie (exact name varies by site) is Http-Only. Thus, it is not exposed (by compliant browsers, which are basically all of them now) in document.cookies.

We do this to prevent the classic javascript injection -> stolen user credential attack.

Answer 2

Eventually this stems from Stack Exchange using a custom (and as of today rare) approach to authentication as explained in Global Network Auto-Login:

So, we gave up on using third-party cookies. Instead, we use HTML 5 Local Storage for global authentication, at our centralized domain stackauth.com. Now, this does require a modern browser, though not unreasonably so: IE8+, Chrome, Safari, FireFox 3.6+, and Opera 10.61+ are all supported.

Please make sure to read the entire post, there might be some hints already, e.g.:

As with all things technically complex, there are some caveats. Global auth should work fine in the typical case — and even if global auth is completely down, it can never prevent you from logging into a site the traditional way. But please be advised that we may not be able to automatically log in you in, if …

• You’ve been to the target site recently without a global auth session (click the “login” link at the top of every page to force it)
  • You’re using some sort of anonymizer that interferes with HTTP Referrer
  • You aren’t using the same OpenId across all sites
  • You’re visiting a per-site meta without first logging into the parent (child metas don’t use global auth; they rely on identity coming from the parent site.)

[emphasis mine]

Finally, Kevins elaborate answer to How does SO's new auto-login feature work? covers many of the technically details potentially relevant here, e.g.:

Acknowledging this, we turned paranoia up to 11 and went full on "defense in depth*." If anything looks "weird" we bail, and the user degrades to using manual logins.

Things We Check

• Your HTTP Referrer is one of our sites
• Your IP has been held constant between subsequent requests to the SE-site and StackAuth
• The sites encoded in the tokens are correct
• The tokens are no older than X minutes (its really tight, but subject to change)
• Nonces are never reused

[emphasis mine]

Good luck!