by Ray Kelly, Manager of Client Side Technologies
Launching a new Web app today comes with a few certainties, and one of them is, “I will be a target for hackers” for sure. So when an app as large and as high profile as Google+ launches, it will surely be one of the top targets for malicious activity. This happened to Facebook the more popular it grew and it still is a favorite platform for malicious activity. I did some analysis of the HTTP traffic between Google+ and the browser and found that Google is off to a good start in regards to browser security. Below are several take-aways:
Only SSL!
All Google+ traffic is sent over SSL and non SSL is not even an option. This protects users’ traffic from getting sniffed and their sessions from being hijacked. It is good to know that Google understands that sensitive information is being shared and SSL is really the only option for transmitting data.
Secure Headers
Here is what a typical response looks like from Google+:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 184942
Set-Cookie: ULS=somehash; Path=/; Secure; HttpOnly
Date: Fri, 15 Jul 2011 14:29:05 GMT
Expires: Fri, 15 Jul 2011 14:29:05 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
There are a few headers in this response that are specific to browser security, for example:
Set-Cookie Secure – This tells the browser to only send cookies over a secure (SSL) connection. So if the site happens to hit a page that is not SSL, then the cookie will not be sent.
Set-Cookie HttpOnly – This prevents the cookie from being accessed by client side script.
Both of these cookie attributes help to prevent session hijacking by only sending cookies when appropriate.
X-Content-Type-Options: nosniff – This prevents “mime” based attacks. The header instructs the browser not to override the response content type. For example, some browsers try to be smart by deciding for themselves if the content is really is text/html or an image. So with the nosniff option, if the server says the content is text/html, then the browser needs to render it as text/html.
X-Frame-Options: SAMEORIGIN – This tells the browser to only render frame pages from the URL hosting the main page. This prevents Clickjacking attacks against the user. Clickjacking is a browser-based attack that tricks the user into clicking on one thing but then performs a different action, such as following a user on Twitter.
X-XSS-Protection: 1; mode=block – This allows the browser to detect a cross site reflection attack. If the browser sees a potential reflection attack, it will prevent the page from rendering in the browser. Instead, you will see something similar to this depending on the browser:
What about Facebook?
While these preventions are by no means ground breaking or new, the fact that Google is thinking about and using them is a good step. In contrast, let’s look at a typical Facebook response:
HTTP/1.1 200 OK
Cache-Control: public, max-age=604800
Content-Type: application/x-javascript; charset=utf-8
Expires: Fri, 22 Jul 2011 14:46:37 GMT
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
X-Frame-Options: DENY
Set-Cookie: _e_syaN_0=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com; httponly
X-FB-Server: 10.52.238.45
X-Cnection: close
Date: Fri, 15 Jul 2011 14:46:37 GMT
Content-Length: 24032
It is surprising that Facebook has not taken the same simple precautions that Google+ has taken. Here, we can see the differences:
|
Secure Cookie |
Nosniff |
XSS Protection |
X-Frame |
HttpOnly Cookie |
SSL |
| Google+ |
Yes |
Yes |
Yes |
Sameorigin |
Yes |
Yes |
| Facebook |
No |
No |
No |
Deny |
Yes |
Optional and not default |
In fact, just yesterday Microsoft’s Vulnerability Research team released advisory MSVR11-007: “Clickjacking Vulnerability in Facebook.com Could Allow Account Compromise”. According to the advisory, Facebook has resolved the issue. I did another check of the headers and still did not see any change to the response. It is possible that Facebook closed the hole on the server side with input validation in order to prevent the malicious data from entering their database, but they still did not implement the simple browser precautions that Google+ has. Here is the link to the official MSVR advisory:
http://www.microsoft.com/technet/security/advisory/msvr11-007.mspx
The folks from SecTheory/WhiteHat Security have an excellent write-up on Clickjacking. For detailed information on this vulnerability visit:
http://www.sectheory.com/clickjacking.htm
Conclusion
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. What’s this mean for you? Make sure you are using an up-to-date browser to take full advantage of these protections.
Do these security measures make Google+ impervious to malicious activities? Absolutely not. Is it a good start? Yes, it is. And further, it is good to see an app make its debut with security in mind. It actually gives us Infosec folks a bit of hope that developers are listening and doing the right thing.
