Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Impossible to Maintain Secure Session With Twitter.com Web Interface
From: Chris Palmer <chris () isecpartners com>
Date: Wed, 28 Apr 2010 14:05:18 -0700

iSEC Partners Security Advisory - 2010-001-twitter https://www.isecpartners.com

Twitter - Insecure session management

Vendor: Twitter
Vendor URL: http://www.twitter.com
Severity: High (allows unauthorized hijacking of accounts)
Author: Chris Palmer <chris[at]isecpartners[dot]com>

Vendor notified: 2009-12-18
Public release: 2010-04-27
Advisory URL: https://www.isecpartners.com/advisories/2010-001-twitter.txt


It is impossible to maintain a secure session with Twitter, for multiple reasons. Additionally, once a session has been 
hijacked, it is possible for the attacker to maintain control over the account (not just the session) indefinitely, 
unless the user changes their password. This is because the session cookie has the same lifetime as the password.

The lack of HTTPS means that users are highly likely to leak their long-lived cookie, their passwords, and their direct 
messages to passive and active network attackers.

In light of the 17 Dec DNS hijacking attack, which may have caused many users to inadvertently send their _twitter_sess 
cookies to the attacker's site, this problem is especially severe -- the attackers may currently have long-lived 
authenticators for a large number of Twitter users. Therefore, Twitter users should either change their passwords, or 
Twitter should change the session management mechanism so that cookies stolen yesterday no longer work today.

Please note also that I discovered these issues purely through non-invasive means; specifically, I only observed my own 
HTTP traffic using an HTTP proxy (WebScarab). I never sent any malicious requests to Twitter or attempted to compromise 
Twitter in any way.

Specific vulnerabilities and suggestions for remediation follow.

Cookie Lifetime Details

The _twitter_sess cookie is an encoded form of a Ruby object serialized with the Marshal library. It contains a field, 
password_token, that is a static function (presumably of the user's password). That is, it is the same across logins. 
This example shows how to decode my cookie in

      >>> from base64 import b64decode
      >>> from urllib import unquote
      >>> a 
      >>> b = unquote(unquote(a))
      >>> b
      >>> c = 
      >>> c
 () used{\x00:\x07id"%57e1f0c306234ba5724cadf7ff4f6f20'

This cookie works even after the user logs out using the http://twitter.com/logout action, and even after the user logs 
back in again to start a new session. The only way to invalidate this cookie is to change the user's password, which 
results in a new, equally long-lived password_token value.

(The above cookie should no longer work.)

Cookie Details

The _twitter_sess cookie is not marked with the Secure flag, meaning that the browser will reveal the cookie over HTTP 
connections as well as over HTTPS connections. This makes it possible for passive network observers to copy the cookie 
on any request to http://twitter.com, and for active network attackers to copy the cookie on forced requests to 

For example, on requests to http://www.google.com, the attacker can rewrite Google's response to be a 302 redirect to 
The browser will follow that link, revealing the cookie, and the attacker can rewrite Twitter's response to be a 
redirect back to http://www.google.com. The user may notice no strange effect at all, but the attacker has copied their 

Tools to conduct attacks like this and similar attack classes are freely available on the internet:


Attackers can also induce the plaintext transmission of the _twitter_sess cookie by including a reference in web pages 
they control to any URL pointing to any host in the twitter.com domain. For example, at a coffee shop that uses a 
"captive portal" to authenticate customers who want to use the wifi network, the attacker can include HTML like the 
following in the captive portal front page:

      <img src="http://whatever.twitter.com/a.jpg"; height="0" width="0" />

When the user's browser attempts to load this resource, it will include the user's _twitter_sess cookie in the request, 
revealing it to the network at large. The attacker can be an active network attacker, or the maintainer of the captive 
portal site.

Similarly, the help.twitter.com site is normally served over HTTP, and its HTTPS service uses an invalid SSL 
certificate. Thus, users wanting to read the help cannot avoid disclosing their cookie over the network.

Although reducing the scope of the _twitter_sess cookie's Domain attribute, which is currently set to .twitter.com 
(i.e. the browser will send it to any hostname under *.twitter.com or to twitter.com), would cause the 
"help.twitter.com" attack to fail, the attacker can still use http://twitter.com/a.jpg. Tightening the Domain attribute 
is most meaningful after the transport security problem has been solved (i.e.
using HTTPS and marking the cookie Secure).

HTTPS Details

Although it is possible to log into Twitter over HTTPS by explicitly navigating to https://twitter.com (note that the 
certificate used by www.twitter.com is not valid for that name), by default Twitter provides a log in form over HTTP. 
Thus, by default, most users will reveal their passwords and their session cookies in plaintext to passive attackers on 
the local network and on the internet.

However, even those users who explicitly navigate to https://twitter.com are redirected to http://twitter.com/ after 
authentication, thus revealing the user's _twitter_sess cookie to all passive observers on the local network and on the 
internet at large. People can again forcibly navigate to https://twitter.com in an attempt to narrow the time window of 
exposure, but it may be too late.

Fix Information:

These solutions each resolve part of the problem. I recommend using all of these means to completely resolve the 
vulnerabilities identified in this report. For more information about the problem of secure session management 
generally, see my prior work on secure session management:


Michal Zalewski's Browser Security Handbook is a crucial resource:


1. Canonicalize the main Twitter hostname to twitter.com. When people browse to resources in the www.twitter.com 
domain, reply with a 301 Moved Permanently to the equivalent twitter.com resource.

2. Use valid SSL certificates for www.twitter.com and for help.twitter.com.

3. Mark the _twitter_sess cookie Secure and HttpOnly. (HttpOnly protects the cookie against trivial XSS attacks, but is 
not a real solution to the problem. HttpOnly is thus optional, but Secure is necessary for

4. Make the Domain of the _twitter_sess cookie "twitter.com" (no leading "."), or leave it blank (equivalent). If you 
want to allow people to use either www.twitter.com or twitter.com, set the cookie twice, once in each domain.

5. Make the cookie short-lived instead of semi-permanent. In particular, the session identifier should be a large 
random number or some other non-static function.

6. For authenticated application functionality, use HTTPS exclusively.
Although arguably possible, it is extremely difficult to provide secure application functionality in the same domain as 
insecure functionality.

Vendor Communication:
2009-12-17: Twitter's DNS hijacked by "Iranian Cyber Army"


2009-12-18: Initial notification of Twitter

2010-01-25: Twitter requests 60 days to engineer a fix before advisory
            release. Twitter believes that the inability to log out problem
            is endemic to Rails apps using CookieStore, although iSEC has not
            found CookieStore applications to have this problem in all

2010-02-02: Some details of a phishing attack against Twitter are revealed
            in the press. Twitter advises some users to change their
            passwords to protect their accounts. However, *all* Twitter
            users need to change their passwords to invalidate any of their
            authentication cookies which any attacker may have stolen. For
            example, when Twitter DNS was hijacked, the attackers received
            and could have stored many Twitter users' cookies.


2010-03-24: iSEC informed Twitter of advisory release. Twitter asks for a
            further extension.

2010-04-23: Twitter asserts that several security fixes are in the
            engineering pipeline, including some dealing with HTTPS.

2010-04-26: Twitter asserts that it is now possible to maintain an HTTPS
            session if the session begins with HTTPS; i.e. users can
            navigate to https://twitter.com to start an HTTPS session.
            However, https://twitter.com/ contains HTTP resources, including
            a JSON response from http://twitter.com. An active network
            attacker could potentially use this weakness to insert their
            own code into the page and maintain control over the user's

2010-04-27: This advisory.

About iSEC Partners:
iSEC Partners is a full-service security consulting firm that provides penetration testing, secure systems development, 
security education and software design verification, with offices in San Francisco, Seattle, and New York.

info () isecpartners com

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
  • Impossible to Maintain Secure Session With Twitter.com Web Interface Chris Palmer (Apr 29)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]