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 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
>>> b = unquote(unquote(a))
>>> c =
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.)
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
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).
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.
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
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
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.
Hosted and sponsored by Secunia - http://secunia.com/
- Impossible to Maintain Secure Session With Twitter.com Web Interface Chris Palmer (Apr 29)