[<prev] [next>] [day] [month] [year] [list]
Message-Id: <B48BBFF9-4D8B-4BAC-A4CA-E8200C3E1EBD@emerose.com>
Date: Sat, 1 May 2010 13:47:22 -0700
From: Sam Quigley <quigley@...rose.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Impossible to Maintain Secure Session With
Twitter.com Web Interface
> iSEC Partners Security Advisory - 2010-001-twitter https://www.isecpartners.com
>
[…]
> 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
> session.
>
Also worth noting that, until yesterday, all SSL pages (including sensitive ones like /oauth/authorize) loaded Javascript from maps.google.com without using SSL. Like the issue iSEC identified above, this has now been fixed.
Also yesterday, they (finally) disabled unsafe SSL renegotiation, thus blocking the credential-stealing attack identified by Anil Kurmus last November.[1]
So: progress. Unfortunately, they still support SSLv2 and a variety of weak ciphers[2] — so there's still room for improvement.
-sq
[1]: http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.html
[2]: https://www.ssllabs.com/ssldb/analyze.html?d=twitter.com&s=168.143.162.36
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists