

Is Gmail Safe? How do you protect yourself from these kind of attacks?  - arunsharma
http://www.makeuseof.com/tag/breaking-gmail-security-flaw-more-domains-get-stollen/
Do you trust your gmail ? How do you protect yourself from these kind of attacks ?
======
dc2k08
His advice is good and probably worth implementing. one thing though..

> Make sure to upgrade your domain to private registration so that your
> contact details don’t show up on WhoIS searches. If you’re on GoDaddy I’d
> recommend going with Protected Registration <

I thought some WHOIS services offered the ability to view cached pages of all
previous contact details, no ?

~~~
tortilla
Yeah, for a fee, you can find historical registration info and other goodies:

<http://www.domaintools.com/>

------
rksprst
Can one of the google employees here ask one of their gmail buddies about
this?

------
arunsharma
<http://blogs.zdnet.com/security/?p=554> It looks like the gmail team has
created a fix and pushed the fix. It suggests that you keep checking your
filters to see if you been rigged as the fix wouldn't fix it (pun intended).

~~~
m0nty
That's from a year ago. I think TFA is speculating about the same kind of
vulnerability, but active now. It _is_ just speculation, though.

------
ramchip
"...including 2 malware monitors, an antivirus and 2 firewalls" In case the
attack is too strong for the first firewall?

~~~
arunsharma
:D 2 firewall wouldn't help at all. Use one - the best one .

------
bedarkened
Seems like the simple solution would be for Google to require
authentication/SSL to create a filter.

------
syntax-case
I guess the solution is to use Gmail in a separate browser profile that you
won't use for anything else.

<http://support.mozilla.com/en-US/kb/Managing+profiles>

~~~
technoguyrob
And the Gmail engineers should add an opt-out "high security" mode that checks
the referer to make sure the form submission is coming from Gmail itself and
not some outside website. This way people who like to use custom/blank
referers can ignore this security concern if they want, and all the rest of us
can prevent the risk of this problem.

EDIT: Or how about just adding an in-line Javascript variable? Say, on all
Gmail pages, you could embed this in the page:

    
    
       <script>var SECURITY_KEY = "918028cd79a5ba47e83e6ba68d036ca3";</script>
    

And then when sending AJAX or form requests in the background, make sure to
include that as a request parameter. That way, even if the user has the right
authentication cookies, external websites won't be able to fool Gmail into
thinking they are Gmail.

Really, this doesn't seem like a very hard problem to solve...couple lines of
code...

~~~
kwamenum86
Is this solution scalable though? Are you saying that they should store this
key on the server side for each instance of gmail and then check every single
AJAX request to see if the key is present?

~~~
immad
That doesn't sound unscalable. It's pretty linear scaling, they already store
information per logged in user anyway.

~~~
kwamenum86
They store information per logged in user but are they performing some type of
lookup information for every single AJAX request? I opened up a chat box and 7
HTTP requests fired off. I have no clue what these are for, but are each one
of those validated and could they be quickly? During typical gmail usage
several requests are fired off in the background for simple and seemingly
trivial user actions like the one mentioned above.

EDIT: ...and after I was done typing the message above I returned to gmail and
15+ more requests has been fired off without me doing anything. The message
took well under a minute to type. Seems like a lot of validation would have to
be done.

~~~
technoguyrob
The same key can be used for each session...when the Gmail page is being
generated, I am saying this embedded in-line key can be associated TO the
user's cookie, so that there is a one-to-one correspondence between this
"Javascript cookie/session variable" and the user's actual cookie. There is no
problem whatsoever. The only thing to be done is the exact same authentication
that Google has to do to determine from which authenticated user chat requests
are coming from (or any other AJAX request sent to Gmail).

EDIT: To answer your question of "are they doing some kind of lookup for each
AJAX request?" Well _of course_ , since they already have to _look up_ a
user's ID, account information, etc. based on the cookie they send.

~~~
kwamenum86
Agreed they have to authenticate but I don't think they perform a lookup on
every single request. They probably use a key but it is more likely this key
(let's call it the AJAX key) is generated from the user's dat (id, ip,
whatever else) using some hashing function on the back-end. When the server
receives a request it can check to see if a request is valid by re-generating
the AJAX key from the requests meta data (header or whatever other data sent
with the request for authentication purposes). This is much quicker and more
scalable than a lookup for every request and its just as secure. Even if
someone guesses your key generation method (which should be HIGHLY unlikely)
you can simply change it and it will work for all users immediately, even ones
who are logged in already.

Now maybe they are performing a lookup for each request but I just do not see
how they can handle the load, or why they would want to given the alternative
I just suggested. Google sends a ridiculous amount of data back to their
servers during a Gmail session. I haven't examined the traffic extensively but
open up a chat box in gmail and the Firebug console at the same time. Click
anywhere in the chat box. See the request that fires off int he console? That
happens EACH TIME you click ANYWHERE in the box. I guess they are doing some
type of clicking heat map or something I don't know, but whatever they are
doing it requires sending potentially 1+ AJAX requests per second for many
users.

I am not knowledgeable enough to tell you how much is too much for a
server/file system/database to handle quickly (~150 ms per request for
millions of requests at once) so maybe the situation I just described is not
as bad as I made it seem.

