7 ms·

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

107 points by iuguy 15y ago

iuguy 15y 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.
- wgx 15y 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 15y 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.
cstuder 15y 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 http://news.ycombinator.com/item?id=2909102) which is all new to me.
- cstuder 15y ago
  Nobody? The current number of upvotes suggests that I'm not the only one with these problems...
- dguido 15y 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-management.pdf http://www.isecpartners.com/storage/white-papers/web-session...
  - cstuder 15y ago
    Thank you very much, I'll have a look at it.
wgx 15y ago
Related: SPDY - Google's always-encrypted application-level protocol to augment HTTP: http://en.wikipedia.org/wiki/SPDY http://en.wikipedia.org/wiki/SPDY
- zobzu 15y 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 https://bugzilla.mozilla.org/show_bug.cgi?id=spdy
  - andfarm 15y 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.
zobzu 15y 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 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&resolution=--- 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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.
    - ceejayoz 15y ago
      > Which is a problem, why not just force all app developers to use SSL? The developer console on Facebook says this will be the case on October 1.
- thechangelog 15y 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 15y 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.
drivebyacct2 15y 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.
- mkjones 15y 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 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/ https://www.facebook.com/whitehat/bounty/).
  - drivebyacct2 15y 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.
    - mkjones 15y ago
      Cool, thanks for the follow-up. Was the "Security Warning" you're talking about from google.com, or from facebook.com? If facebook, do you know what the specific domain was that caused the error (and the reason for the error)? Also, I'm curious where you reported this before? If there's an issue causing security bug reports to get dropped, that's something I want to fix ASAP. Thanks!

107 points by iuguy 15y ago

iuguy 15y 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.

wgx 15y 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 15y 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.

cstuder 15y 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 http://news.ycombinator.com/item?id=2909102) which is all new to me.

cstuder 15y ago
Nobody? The current number of upvotes suggests that I'm not the only one with these problems...
dguido 15y 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-management.pdf http://www.isecpartners.com/storage/white-papers/web-session...
- cstuder 15y ago
  Thank you very much, I'll have a look at it.

wgx 15y ago

Related: SPDY - Google's always-encrypted application-level protocol to augment HTTP: http://en.wikipedia.org/wiki/SPDY http://en.wikipedia.org/wiki/SPDY

zobzu 15y 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 https://bugzilla.mozilla.org/show_bug.cgi?id=spdy
- andfarm 15y 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.

zobzu 15y 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 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&resolution=--- 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 15y 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 15y 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 15y 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 15y 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 15y 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 15y 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.
  - ceejayoz 15y ago
    > Which is a problem, why not just force all app developers to use SSL? The developer console on Facebook says this will be the case on October 1.
thechangelog 15y 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 15y 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.

drivebyacct2 15y 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.

mkjones 15y 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 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/ https://www.facebook.com/whitehat/bounty/).
- drivebyacct2 15y 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.
  - mkjones 15y ago
    Cool, thanks for the follow-up. Was the "Security Warning" you're talking about from google.com, or from facebook.com? If facebook, do you know what the specific domain was that caused the error (and the reason for the error)? Also, I'm curious where you reported this before? If there's an issue causing security bug reports to get dropped, that's something I want to fix ASAP. Thanks!