11–20 of 21 posts
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).
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 ?
"...including 2 malware monitors, an antivirus and 2 firewalls" In case the attack is too strong for the first firewall?
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 ?
Earlier quoted context omitted.
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 G…
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?
Earlier quoted context omitted.
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?
That doesn't sound unscalable. It's pretty linear scaling, they already store information per logged in user anyway.
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.
Earlier quoted context omitted.
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 G…
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?
See "Good Patterns & procedures to prevent CSRF": http://www.owasp.org/index.php/Reviewing_code_for_Cross-Site...
Earlier quoted context omitted.
That doesn't sound unscalable. It's pretty linear scaling, they already store information per logged in user anyway.
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 ment…
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.
Earlier quoted context omitted.
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 ment…
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 wh…
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.
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
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 G…