Re: [OT] If you use gmail
On Mon, 15 Dec 2008 00:32:05 +1300
Chris Bannister <mockingbird@earthlight.co.nz> wrote:
> Hi,
>
> http://www.webmonkey.com/blog/Why_You_Should_Turn_Gmail_s_SSL_Feature_On_Now
I can't say that I have a really good understanding of the issues, but
I believe that the article is not as clear as it might be. It claims
that:
"How do you know a connection is secured by SSL? The handy “s” after
“http” will tell you. For example, https://mail.google.com is encrypted
while http://mail.google.com is not. You can force an encryption by
adding the “s” yourself, or by turning on “Always use https” from the
Browser Connection settings of your Gmail account."
This implies that using the https url is sufficient for security, but
Mike Perry, the hacker that the article largely relies on, has taken
pains to repeatedly explain that this is not so:
"As I presented in my Black Hat and DefCon talks on Securing the Tor
Network, it turns out that using https for accessing mail.google.com
is not sufficient to protect you from many "Sidejacking" attacks. The
'GX' authentication cookie for mail.google.com is set to be
transmitted for any type of connection (http or https). This is the
only cookie one needs to authenticate to gmail.
This "Any type of connection" property allows an attacker execute a
cross site request forgery attack to inject spoofed
'http://mail.google.com' content elements or meta-refresh tags into
ANY WEB PAGE loaded by a user. Repeat: the user does NOT have to be
using gmail at the time, they just need to have a valid 'GX'
authentication cookie from a prior login, and then visit ANY WEBSITE.
Upon fetching/executing these injected elements, the browser will
transmit the 'GX' cookie in the clear for the load of the spoofed
element."
http://seclists.org/bugtraq/2007/Aug/0070.html
"Vulnerability 2: HTTPS but Insecure Cookies
This is the vulnerability I announced in my Bugtraq post last year, and
the one I featured in my DEFCON talk. Basically, it revolves around the
fact that cookies have two modes: secure and insecure. If a cookie is
insecure, a browser will transmit it for plain old http connections,
and an active attacker can then inject a set of http images for sites
that they want cookies for, and the browser will happily transmit
cookies for these sites unencrypted, allowing their capture. This
attack can even be automated for the majority of sites without the need
for a list of targets (though a list of targets can also work just fine
against these sites as well, to capture their cookies for every IP on
the network). I describe the automated process in both the core logic
post, and the original writeup post of CookieMonster."
http://fscked.org/blog/overview-web-mitm-vulnerability-surface
> Chris.
Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Reply to: