The Social Media Security Podcast

A few months back, I recall security analyst Kevin Johnson musing that the security community often hears negative stories about hacks and vulnerabilities, but rarely does one see positive reports about the times when security works and black hats fail. I thought about this during the Month of Facebook Bugs, when I came across one application (My City) whose ASP.NET framework blocked my XSS attempts stone cold.

While it’s no secret that I don’t always see eye-to-eye with the leadership of Facebook, I wanted to take this post to give them a few shout-outs instead of critiquing. Amid all the negative reports about Facebook decisions, I have seen a few developments I find encouraging.

First, Facebook has taken action against deceptive advertisements and ad networks that harvest application credentials to access user information. While I’ve argued that some of these steps were long overdue and that Facebook could have done even more, I’m grateful that they did something and that they cracked down hard on credential hijacking.

Second, one of the main responses I’ve advocated for application problems is simply to better educate developers, and I would say that Facebook has done a much better job emphasizing security issues recently. (I’m not taking credit for the change, simply applauding it as a move I endorse.) Last month, Ryan McGeehan (Facebook’s manager for security incident response) posted an official blog entry reminding developers of important security issues, providing helpful resources on the subject, and announcing a new Platform wiki article with even more information. I know from experience that Ryan is a great guy who cares about security – he patiently fielded dozens of e-mails from me in September as I relayed details on the Month of Facebook Bugs. I’m thrilled to see a security section on the main documentation site for the Facebook Platform. By the way, Facebook also has a fan page with information on security, including a section dedicated to white hats – you can get your name there if you follow their responsible disclosure guidelines.

Finally, Facebook began enforcing new, stricter Platform policies today. Among the changes, developers are now required to

Provide a link to your privacy policy in the Info section of your Application Profile page and on every page of your application.

I was honestly surprised that Facebook would require a link on every page. After seeing quite disappointing results in my study on application privacy policies this summer, I congratulate Facebook on raising the bar. Many users may not notice the new links, but a encouraging developers to establish and advertise privacy policies is a step in the right direction.

While I’m not afraid to make noise about negative trends or privacy risks I see in services such as Facebook or Google Wave, at the end of the day, it’s nothing personal. I may disagree with the developers or executives at Facebook about product architectures or content sharing, but I think we can all agree that we want to protect end users. The three steps listed above certainly help that goal, so in that regard, kudos to Facebook.

“Security through obscurity” refers to the idea that content can be kept safe by making it hard to find rather than inaccessible without authorization. Many photo hosting sites use complicated URIs for uploaded pictures, making it very unlikely anyone would simply stumble across a particular picture by entering a random address. End users may think such a setup is reliable enough to keep their content private.

However, security researchers routinely criticize the notion that obscurity provides much security at all. Hidden content is often more easily found than people may suspect. Even if finding the content may not seem obvious, tricks often exist to work around a system’s obscurity and gain even targeted access to resources.

Case in point: Facebook’s photo albums. For years, the default level of access on new albums has been “Everyone.” Up until this week, many Facebook users apparently paid little attention to their privacy settings, and while someone could theoretically access a public photo album, the likelihood of someone guessing a legitimate album ID for a particular user seemed remote. Although many people (including this blogger) had pointed out that albums could be accessed given the file name of one photo within the album, that still required more knowledge than most would-be photo hunters would have.

But as Facebook has rolled out their new privacy model (a story I’ve not covered here as it’s been well documented elsewhere, and I’ve been posting relevant links on my Twitter), users are suddenly taking note of who can access what on their profiles. In an ironic turn of events, Mark Zuckerberg’s personal photo albums became easily accessible after the privacy switch. It’s likely Zuckerberg had set his albums to “Everyone,” but until now the list of albums was not included on someone’s profile unless you were their friend.

In the past, developers used Facebook’s API to access public albums for non-friends, but Facebook shut off that functionality. After the Zuckerberg story, Facebook apparently removed users’ photo album lists from the profiles of non-friends, once again resorting to a security through obscurity approach.

Once again, though, the new behavior has a simple workaround. Create a new web page and insert an inline frame with this URI: http://www.facebook.com/ajax/profile/tab.php?id=USERID&v=photos&iframe=true Replace the “USERID” part with a Facebook user’s ID number. Load your page and view the source of the iframe. You’ll see a block of HTML encoded within some JavaScript, and embedded in that HTML are links to the user’s photo albums that you can access. Note that loading the Facebook URI directly will not work – you must use an iframe.

I have no problems posting this as I’m not foiling any of a user’s privacy settings or somehow working around Facebook’s access restrictions. This trick only exposes albums that you can access based on the albums’ privacy settings. Of course, many Facebook users may be surprised to see which of their albums can be accessed by non-friends this way.

The lesson here is that on Facebook, “Everyone” really does mean everyone. Take the time to check all of your privacy settings and make sure nothing is set to “Everyone” that you wouldn’t want the entire Internet to see.

In fact, many would argue that you shouldn’t post anything on Facebook that you don’t want the entire Internet to see, since despite Facebook’s many privacy settings, much of your content has long been accessible via Facebook applications – and security issues with applications are well-documented.

Does that mean you should never use Facebook? At some point, we have to live our lives, and that always includes risks. The key is awareness – think about what you’re posting, understand the ramifications of your privacy settings, and stay current with changes in online security and privacy. Those steps are some of the most important in protecting your identity.

Update: As with API access before, Facebook issued a patch some time in the last five hours that blocks the trick I described for accessing public albums. Honestly, this doesn’t make much sense, since the albums are marked for “everyone.” If anything, it trains users to rely on security through obscurity.

Amusingly enough, while Mark Zuckerberg’s albums are still accessible by URI (according to reports, he made them public on purpose), some of the other Facebook employee albums that I had previously accessed are now inaccessible – meaning the album owner may have been trusting in security through obscurity until now as well.

Update 2 (12/15): At present, a slight adjustment to my previously posted trick once again enables access to a user’s public albums. Adding the parameter &__a=1 to the end of the old URI once again loads the album links (e.g. http://www.facebook.com/ajax/profile/tab.php?id=4&v=photos&iframe=true&__a=1 for Mark Zuckerberg’s albums). The parameter &sb= can be used to access multiple pages of albums (“sb” seems to be set to multiples of 4 or 5). Please note that you still need to use the iframe setup I described earlier. Anyone interested in further details or a demonstration can e-mail theharmonyguy via Gmail.

Keep in mind Facebook may block this version of the trick at any time. However, as I noted before, this only provides access to albums which users have marked as being for “everyone,” and thus should not even be required in the first place. If Facebook truly wants to make sharing content easier, why not simply provide a list of public photo albums on a user’s profile? The issue here is not a problem of privacy, but user expectations. Facebook has trained users to accept default settings on photo albums while thinking they’re not easily accessible. Making the albums hard to find gives an illusion of privacy and only delays any rude awakenings that may come from users who have inadvertently shared private photos.

Update 3: I may have spoken too soon last week; I just tried using the URI without &__a=1 and it still worked. Perhaps there was simply a glitch before when I thought the trick had been blocked.

In an amusing story earlier this year, a technology news reporter writing on a particular security problem unwittingly demonstrated the issue by publishing an article. ReadWriteWeb posted a story on cross-site scripting holes on McAfee’s web site, and the article included some sample code that could be used in an attack. Unfortunately, the New York Times syndicates some articles from RWW, including this one on XSS, and at the time did not filter code in RWW reports. Consequently, the sample code actually rendered in the New York Times version of the article, producing another example of cross-site scripting.

In broad strokes, a syndicated system occurs when one application or network loads content from another (one-way) while a federated system involves two applications or networks exchanging content in a fully interoperable fashion (two-way). RSS is a syndicated setup – your reader simply loads an XML feed from the site you subscribe to. E-mail is a federated system – many SMTP servers exchange messages with each other.

Both syndicated and federated systems have to deal with a potential security problem: outside content. Any time you load data (particualrly in a web application) that’s not under your control, you need to put in filters to avoid such issues as cross-site scripting. The problem here is not a matter of trust – I’m sure the New York Times considered ReadWriteWeb a trusted source. The problem is that other sources of content may not always provide what your application is expecting. Rather than assume the data’s formatted and encoded correctly, assume it’s not and take appropriate action. This is merely one example of the type of thinking security researchers routinely employ – and a mindset developers need to use more often.

I recently came across another minor example of syndication leading to XSS. The search engine Cuil recently announced that they were launching an opt-in feature to index the posts of your friends on Facebook and include those posts in your search results. Aside from the privacy ramifications (you may be surprised to learn that settings for uninstalled apps and Facebook Connect sites don’t seem to apply to Cuil’s search results), I wondered how secure Cuil’s implementation would be in practice.

Overall, the feature seems to work like most Facebook Connect sites, and thus poses no inherent security problems. However, I did find quickly that Cuil was not encoding the results from Facebook. That is, a friend could post a status saying, “testing <script>alert(document.cookie)</script>” and searching for “testing” in Cuil would load the alert dialog. Obviously the impact of such an attack would be minimal, as it requires jumping through a few hoops first, but it again illustrates accidental XSS via syndicated content. Note that XSS in a Facebook Connect application would open the door to a FAXX-style attack.

An example of a federated system that causes me some concern is Google Wave. When I first started looking at Google Wave from a security standpoint, I admit that I did not fully understand the architecture of the product. In essence, Wave includes two distinct components – a server and a client. On the server end, Wave is an XMPP service that can communicate with any compatible setup. On the client side, Wave is the web interface hosted at wave.google.com for loading messages from servers.

Once I understood this division, I thought it even more important to discuss the security implications of gadgets within waves. I fully expect Google to address most, if not all, of the issues I raised regarding gadgets. (In fact, last time I checked, it appeared they had changed the domains of container iframes, stopping cross-gadget access). But if Wave really does catch on, Google’s client interface will not be the only one on the market. Since gadgets render as HTML/CSS/JavaScript, Wave clients will almost assuredly have some sort of web browser component. If the company that invented Wave did not factor in some of the security considerations I and others have noted in their original client, there’s a good chance other developers will not take into account similar issues unless people raise awareness.

However, security in Wave clients deals with only one direction of a federated system. I’m still wondering how certain aspects of federated waves will work in practice. For instance, from what I understand, each thread of messages in Wave will be stored on the server hosting the thread. What will happen if that server becomes suddenly unavailable? How will corporate record-keeping and e-discovery And while Google’s Wave servers will likely be quite secure, what about other servers?

Granted, some questions about Wave servers could be raised about similar systems, such as e-mail. But several of the decentralized aspects of Wave distinguish it from a typical e-mail setup, and could prove to be good experiments in light of proposals for decentralized social networking. I’ve long supported the idea of distributed social networking, but also felt it could lead to many performance and usability problems not found in a walled garden (I’ve been meaning to write a blog post entitled “In Defense of Walled Gardens” for at least a year). Wave may be one of the first large-scale attempts at building a distributed application somewhat akin to social networking.

After I posted concerns over security in Google Wave, several responses came (including one from Google) emphasizing that Wave was “still in an early preview stage” and many bugs would be fixed before a wider release. I think that clarifying why I would bother discussing bugs in a preview product may raise a few important points about web application security.

First, let me be clear about one point: I would not pretend to know more about application security than the engineers, programmers, and scientists at Google. In addition, I would not want to imply that Google does not care about security or user privacy. I realize that Google takes security issues seriously and has the resources to build highly secure products.

But those realizations are also a source of confusion for me when I observe decisions made about Google Wave. As an outsider, I don’t understand why Wave would include the problems I’ve outlined. What I’ve posted does not involve clever hacks or specific parameters – these problems involve weaknesses in the overall framework of Wave. And such weaknesses relate to well-known issues in application security. In fact, Google has previously addressed deploying third-party code by developing Caja after the launch of OpenSocial.

Returning to the “it’s a preview” argument, though, I would first respond by saying that applications, particularly ones that allow users to embed untrusted third-party code, should include security from the very beginning. Starting with an open model and trying to add restrictions later on is a recipe for disaster.

A larger issue in Wave’s case, though, is that Google has often cast Wave as a reinvention of SMTP e-mail. If you set expectations high, much will be expected of you. If a company with the reputation, resources, and revenue of Google markets a product as a replacement for traditional e-mail, I’m going to evaluate its security even more closely than normal. In my view, the hype that has already built around Wave and the reach it’s already found (Novell is reportedly planning a Wave-based business product in mid-2010) disallow the “preview” excuse.

In addition, if you’re going to reinvent e-mail, don’t forget lessons already learned from traditional e-mail. In a previous post, I outlined four major weaknesses I saw in Google Wave:

1. Allowing scripts and iframes in gadgets with no limits apart from sandboxing
2. Lack of control over what content or users can be added to a wave
3. No simple mechanism for verifying gadget sources or features
4. Automatically loading gadgets when a wave is viewed

Name one webmail interface that executes scripts in messages. Name one recent e-mail client that automatically loads content such as images in messages. Why were such considerations not part of Wave from the very start?

Of course, while Google has at least promised to include further permissions controls in Wave, such controls are one aspect of Wave intentionally left out in initial releases. While one can argue whether Google is correct in the merits of such collaboration, I’m a bit surprised that more of the security implications have not been raised before (at least not to my knowledge). When such changes will appear, though, remains to be seen. Personally, I find it a tad disconcerting that Google has similarly promised such updates as allowing users to turn off Wave’s real-time typing behavior, yet Wave has changed little since its announcement.

Still, I’m confident that Google will address at least some of the issues I’ve raised. If nothing else, I hope I’ve contributed to the public dialogue about Google Wave. I will add that Wave appears to include much security on the backend – most of the problems I’m seeing come in the client implementation. Let’s remember, though, that Wave will be federated. Another reason to bring up client security issues early is that other clients can learn from Google’s implementation. I’m rather concerned that if Wave interfaces proliferate, they may repeat many of the security problems seen in early e-mail interfaces.

I’m also concerned that Wave is not really addressing many of the issues that have plagued e-mail. The current “chaos” with Wave’s lack of permissions does not bode well for how it will handle spam, for instance. Whitelisting alone won’t do the trick. In fact, I would argue that Wave is a collaboration tool, not a communication tool, and thus not a replacement for e-mail.

In conclusion, I’d simply add one more point. While it’s exciting to find exploits such as specific XSS holes on a web site, it’s often more important to raise awareness regarding larger security issues that relate to the overall framework of an application. That’s why I’ve discussed FAXX hacks so much, as they relate to the overall implementation of the Facebook Platform instead of particular vulnerabilities.

Similarly, my concerns about Google Wave thus far involve behaviors built into the current system that open the door for exploiting the privacy and security of users. Preview or not, Wave needs to address these high-level weaknesses if it’s going to match the hype.