Why Google+ Gets a “+1″ for Browser Security

http://www.barracudalabs.com/wordpress/index.php/2011/07/21/google-gets-a-1-for-browser-security-3/

by _b8r0 • 15 years ago

107 26 15 years ago

_b8r0• 15 years ago

What's interesting to me is that even though G+ is a lot younger and has a much smaller feature set compared to Facebook, Google appear to be putting security in from the ground up. Facebook on the other hand are desperately lagging behind in this way.

wgx2• 15 years ago

That's the benefit of hindsight. Facebook was built as a startup and grew fast. G+ is being developed in a fully-fledged company with way more resource.

Agree, though that Fb could be working harder on this!

SkyMarshal• 15 years ago

Google is wisely prioritizing eliminating as much of the downside as possible. They're also able to, since G+ has the staying power that FB may not have felt they had in their early days.

cstuder3• 15 years ago

Is there an up-to-date best-practices guide to implement websites using HTTPS and cookies securely?

I hear a lot of stuff discussed in this article and in the discussions about HN-HTTPS (http://news.ycombinator.com/item?id=2909102) which is all new to me.

cstuder3• 15 years ago

Nobody? The current number of upvotes suggests that I'm not the only one with these problems...

dguido• 15 years ago

We (iSEC Partners) have a whitepaper on the topic that explains most of the basics.

http://www.isecpartners.com/storage/white-papers/web-session...

cstuder3• 15 years ago

Thank you very much, I'll have a look at it.

wgx2• 15 years ago

Related: SPDY - Google's always-encrypted application-level protocol to augment HTTP:

http://en.wikipedia.org/wiki/SPDY

zobzu2• 15 years ago

I would rather see SCTP, I mean, something standard, than a hack up on top of existing protocols, even if that's slower to implement.

Now then again SPDY is indeed fast and encrypted

This is also interesting:

https://bugzilla.mozilla.org/show_bug.cgi?id=spdy

andfarm• 15 years ago

SCTP is at a different layer of the network stack -- it's a replacement for TCP, not for HTTP. As such, it's much more difficult to deploy, as it currently requires a kernel extension in most OSes, and can't traverse most firewalls.

Also, it isn't encrypted. So there's that too.

zobzu2• 15 years ago

There are a lot of good things there but the author seems to be looking at it like "there's a bunch more headers on G+ ITS BETTER!"

Unfortunately it's not true. For instance, G+ does not use X-Content-Security-Policy (https://wiki.mozilla.org/Security/CSP/Specification) and uses X-XSS-Protection instead, which is a solution not exactly designed properly. (Noscript is a slightly better implementation, but since its client side, no dice)

You can also check this at Wekbit: https://bugs.webkit.org/buglist.cgi?keywords=XSSAuditor&...

Many G website just disable that filter afaik because sometimes it can be misused by the attacker.

I suppose that Chrome will eventually support X-Content-Security-Policy or something similar and then G sites will switch to that.

mike-cardwell• 15 years ago

Current versions of Chrome support CSP, but by using the X-WebKit-CSP header. Once they are happy with the implementation, they will use the correctly named header.

justinschuh• 15 years ago

You seem to be confused here. CSP and the XSS auditor are not mutually exclusive; you can certainly use both and one can cover areas missed by the other. Also, in terms of market share the XSS auditor is going to be supported by a bigger user base than CSP. It's also important to note that the XSS auditor is disabled on other Google sites primarily because it hasn't been tested for compatibility--not because it can be misused by an attacker.

As for CSP support in Chrome, it's currently available if you set a vendor-specific header. (That's the normal way to handle an experimental standard that's still in flux.) My personal opinion on CSP is that it's a bit of an overly complicated mess. We didn't plan to implement it in Chrome/WebKit until very recently, mainly because Mozilla got some major sites on board. In the end, we decided users would be better served by CSP (warts and all) than by any attempts at yet another standard.

AgentConundrum• 15 years ago

> Facebook SSL: Optional and not default

Not only is it not the default, but it's hard to keep enabled for a good chunk of users. If you try to go to an app page[1], for example, you will be informed that SSL cannot be used. To continue, you need to disable SSL not only on pages that app uses, but the entire site. It doesn't get re-enabled when you leave the app.

[1] I don't know that this is true for all app pages, but it's definitely true for at least one of the most popular apps on Facebook.

ZoFreX• 15 years ago

About half the special offers / competitions run through Facebook seem to necessitate turning off SSL, which is a real shame. So far I've been leaving it on and giving my cash to other companies.

joelhaasnoot• 15 years ago

Not a FB app developer, but my naive experience is that not all apps are hosted on a domain with SSL available. If it's not on an SSL domain, it brings up a box asking you if it's ok to disable HTTPS.

mtogo• 15 years ago

Which is a problem, why not just force all app developers to use SSL?

Additionally, the button disables SSL forever, rather than just while you're using the broken app.

thechangelog• 15 years ago

This is changing as of October 1, when FB will require all apps to be served over SSL. They've been warning devs for months that the change is coming.

Wilya• 15 years ago

"Unfortunately, not all of these headers are supported in all browsers, meaning any of you still using IE6 won’t be able to take advantage of these headers."

That would be a plausible explanation for the fact that they use a user-agent based whitelisting. If one's protections rely on client-side features, it's a bit more understandable (though I still find it a bit weak) to try to enforce use of a browser that implements them.

drivebyacct23• 15 years ago

Not only that, Facebook serves it's JavaScript from a static content server that is not secured using SSL, or when it is, it's a bad certificate. Combined with Chrome's aggressive insecure script blocking, Facebook is a nightmare to use.

tl;dr: If you think you're secure because Facebook says HTTPS, you're completely wrong. If I'm on your network, I can inject javascript just as happily as if facebook were loading over http.

This has been reported and ignored, as one might guess.

mkjones2• 15 years ago

Hey, I work on security at Facebook, and when you've turned on HTTPS mode you definitely should not be pulling javascript from anywhere over HTTP (and of course our CDNs should all have valid certificates!). You're correct that this breaks a lot of the security that HTTPS offers. Do you have an example packet capture or list of HTTP CDN URLs that were referenced when you were in HTTPS mode? Or of the domain with an invalid certificate? I'll try to get that fixed ASAP.

I'd also love to debug your report getting ignored - do you know where you submitted it? We take white hat reports pretty seriously and I know I've seen a number of them resolved in less than a day after being reported. Check out https://www.facebook.com/whitehat to report stuff in the future (we'll even pay a bounty of $500 for most properly-disclosed security bugs: https://www.facebook.com/whitehat/bounty/).

drivebyacct23• 15 years ago

I'll take a capture next time and grab the <head> tag from the body. The biggest problem is that it's very sporadic. Some days it will work perfectly with no warnings and exceptions. Earlier today though, I got the "Security Warning" from Google and improper certificate (not even on the static assets) on a network that I trust to a high degree.

nbm• 15 years ago

Are you sure this is still happening? I loaded a few pages, and every resource on those pages was served over HTTPS (and I got no errors, and I'm using Chrome). If you can either reproduce it still, or have any further information, I know a few people here who would like to hear about it.

Why Google+ Gets a “+1″ for Browser Security

Related Stories