
Why Google+ Gets a “+1″ for Browser Security - iuguy
http://www.barracudalabs.com/wordpress/index.php/2011/07/21/google-gets-a-1-for-browser-security-3/
======
AgentConundrum
> _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.

~~~
joelhaasnoot
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
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
> 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.

------
cstuder
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.

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

[http://www.isecpartners.com/storage/white-papers/web-
session...](http://www.isecpartners.com/storage/white-papers/web-session-
management.pdf)

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

------
zobzu
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&...](https://bugs.webkit.org/buglist.cgi?keywords=XSSAuditor&resolution=---)

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.

~~~
justinschuh
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.

------
iuguy
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
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!

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

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

~~~
zobzu
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
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.

------
Wilya
"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
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
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/>).

~~~
drivebyacct2
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
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!

~~~
drivebyacct2
The security warning was the alarming red one generated by Chrome, but for the
Facebook site and domain. I can't tell you if it was for the root domain or
www, and I'm afraid I do not recall the error. I get a bit confused with
Chrome (because it has various levels of warnings for various types of things
(the page itself, scripts, stylesheets, etc) and it doesn't help that I'm on
the dev channel, but sometimes I get the full blown red warning, sometimes I
get the red X through the https in the url bar and sometimes I get "Insecure
Script was Blocked" which occurs strangely, when I receive notifications.

I honestly don't remember where I reported this before, it was not at the link
you've offered above. I've got that bookmarked now. Like I said, if I have
someone to contact or the whitehat link you mentioned, I will be sure to get a
more detailed list of what happens when it occurs again.

Thanks.

