The first issue came from a page on the mobile version of Facebook’s site. The interface was a prompt for posting stories to a user’s wall, and the parameter for the text of the prompt did not properly escape output. On March 28, a blogger identifying themselves as “Joy CrazyDaVinci” posted code that demonstrated how the vulnerability could be used to spread viral links:

<iframe id=”CrazyDaVinci” style=”display:none;”
src=”http://m.facebook.com/connect/prompt_feed.php?display=wap&user_message_prompt=’<script>window.onload=function(){document.forms[0].message.value=’Just visited http://y.ahoo.it/gajeBA Wow.. cool! nice page dude!!!‘;document.forms[0].submit();}</script>”></iframe>

This bit of HTML would be included in a viral page. The code sets the content of the wall post to a message that includes a link to a viral page, then submits the prompt automatically. Anyone clicking the link would get the same code executed on their account. The viral page could be used for malware distribution or phishing attacks, but in most cases where I saw this trick used, the page simply loaded advertisements or “offer spam”.

By the next day, several links were spreading virally and caught the attention of security researchers. Facebook moved quickly to patch the issue, and Crazy DaVinci issued an apology for the example code, explaining that versions of it had actually been circulating for several days prior and that the demonstration was intended to push Facebook for a fix.

On April 3, another XSS problem came to light, this time with a Facebook “channel” page used for session management. Both another security researcher and I had previously looked at this interface and found it properly escaped, so it’s likely a code update mistakenly changed the page’s behavior. Facebook again patched the problem soon after news of it spread.

I didn’t observe any viral exploitation of the second vulnerability in the wild, but after the first problem came to light, I noted that it was mostly used to submit a form already on the page for posting links. The payload made use of functionality within the vulnerable page, but XSS allows an attacker to do far more. I wondered when we might see a Facebook attack that made greater use of cross-site scripting’s potential.

What a Difference a Space Makes

I didn’t have to wait long. On April 7, I got word via Twitter of a Facebook app that had live XSS, but the app had disappeared before I got to see it in action. At first, I thought this was yet another case of XSS within the context of a Facebook app. But I soon found other version of the app which were still online, and I quickly realized this was actually an XSS problem with the Facebook Platform. Also, the XSS payload being used did much more than submit a form.

The attack used FBML-based Facebook apps, which render in the context of an apps.facebook.com page. Normally, Facebook filters code to prevent any scripts from directly modifying the page’s DOM, but the XSS problem gave attackers a bypass. When a user visited the app page, they would see what appeared to be a fairly benign page with a popular video.

Unlike many Facebook page scams, the promised video actually works – if you click play, the video will load and nothing unusual seems to happen. But as the code screenshot below reveals, that click does much more than load the video.

When the page first loads, the “video” is actually just an image placeholder with a link. Part of the href parameter for that link is shown above. Note the space after the opening quotation mark – that’s where the XSS comes in. Normally, Facebook would block a link to a javascript: URL. Adding the space worked around Facebook’s filters, but the browser would still execute the rest of parameter.

According to Facebook, it turned out that some older code was using PHP’s built-in parse_url function to determine allowable URLs. For example, while parse_url(“javascript:alert(1)”) yields a scheme of “javascript” and a path of “alert(1)”, adding whitespace gives a different result: parse_url(” javascript:alert(1)”) does not return a scheme and has a path of “javascript:alert(1)”. Other PHP developers should take note of the difference if parse_url is being used in security-related code.

A More Advanced Attack

Clicking the link executed an inline script that in turn added a script element to the page. This loaded more code from a remote address and included several parameters in the GET request. The parameters set variables within the remote code that specified what video to load, what URLs to use for viral posts, and so on. Multiple Facebook apps and domains were used for the viral links, but the main script always came from the same host. This helped the attack persist, since blocking one site would not stop it and the central code was loaded dynamically.

The remote code handled actually loading the video, but also included a number of functions which make use of having script access in a facebook.com context. The script would set the user as attending spam events, invite friends to those events, “like” a viral link, and even send IMs to friends using Facebook Chat.

When I came across the attack, one block of code had been commented out, but one blogger discovered a version of the attack a few days prior and saw it in action. This part loaded a fake login form which actually sent the entered username and password to a log interface on the attacker’s server. (Remember, this phishing form would appear in the context of a page with typical Facebook chrome.) Since the attack page would load even if a user was not logged in to Facebook, this could have also been a way to make sure a session was available before launching the other functions.

Fake videos and viral links are nothing new on Facebook, but most of these scams tend to be fairly simple. In fact, it’s not hard to find forums where people offer boilerplate code for launching such schemes – much like the first XSS worm above which simply submitted a form. But the April XSS attack involved multiple domains, multiple user accounts, and multiple methods for spreading and hijacking user accounts. And it still only scratched the surface of what’s possible with an XSS vulnerability. I expect we’ll see more XSS-based attacks and more powerful payloads in the future.

Postscript on Real-Time Research

I came across the April attack late one afternoon as I was preparing to leave work… so I could present on XSS at a local OWASP meeting! Those following me on Twitter saw a somewhat frantic stream of tweets as I tried to find live examples of the attack and sorted through the code while closely watching the clock and wrapping up last-minute presentation details. Earlier this week, I did some searching to review information for this post, and I came across this article from eWEEK: “Facebook Bully Video Actually an XSS Exploit“.

I was a bit surprised by it, as I hadn’t known about it before and saw that it quoted me. I then realized it was quoting my tweets! I then read that I had “confirmed to eWEEK on Twitter” one aspect of the story. At first I was confused, but then remembered that during my flood of tweeting, another user had sent an @ reply asking about the very detail the story talked about. Checking that tweet again, I found out the question had come from the article’s author.

I relate all this not because any of it bothered me, simply because (1) I found it somewhat fascinating that a few quick Twitter updates could become the primary source for a news article and (2) I was humbled to realize that a few quick Twitter updates could become the primary source for a news article! While it’s great that a story can spread so fast, it was certainly gave me a reminder to be careful when discussing topics of interest on a public forum. But I’m glad I can do my part in helping raise awareness of online dangers, particular the implications of XSS.

At first, I started to think Facebook was simply looking to extend its reach by acting as an invisible layer of sorts. Anil Dash once talked about Facebook melting into the larger Web, but perhaps Facebook would end up becoming part of the underlying fabric of the Internet. In past public appearances, Facebook CEO Mark Zuckerberg seemed to be the kind of person who was content to remain in the background, and the company’s strategy seemed to reflect a similar style. I’ve mentioned before the idea of Facebook becoming and identity layer on the Internet, and innovations such as their Graph API have made it easier than ever for sites to integrate with Facebook.

But Facebook’s updated Groups feature changed my perspective, since it added functionality that would drive users back to facebook.com. Of course, the upgrade did enable e-mail as a way of interacting with groups. In some ways, Facebook’s overall strategy could be compared to Google’s. Years ago, many sites focused on “stickiness,” trying to keep users hooked. By contrast, Google drove users away by providing relevant links to other sites. But to see Google as non-sticky would be an oversimplification. In fact, the company built a successful ad network that extended its reach across the web. Also, Google has created a number of other products that many people stay logged into, such as Gmail.

And now, people are expecting Facebook to announce a web-based e-mail client that will compete with Gmail. I’m predicting that Facebook will roll out a new messaging system, but it won’t be a Gmail clone or simply another client for managing traditional POP/IMAP e-mail. That’s not to say there won’t be any e-mail gateway, but I think Facebook’s plans will go much further. I’m guessing that at least part of the new system will involve somehow extending private messaging features across Facebook-integrated websites.

In any event, I think Facebook’s announcement will include at least a few surprises for those who have been discussing the possibilities. Facebook has a history of introducing features that aren’t quite what people expected – and often end up leading to practical implementations of ideas that were previously niche experiments. Personally, I think it’s a bit short-sighted to think that Facebook would simply join the market for web-based e-mail without trying to reinvent it, especially given the service’s cautiousness about past features that allowed or potentially allowed spam-like behaviors.

Facebook has also been accused many times of somehow standing in opposition to “openness.” Personally, I think the term has become a buzzword that’s often used without much specificity. And even though I’ve often been a critic of Facebook, I do think many of the accusations aren’t entirely fair. From RSS feeds to developer APIs, Facebook has opened up data in ways that many other sites can’t claim. Today’s Facebook is certainly far more “open” that years ago – in fact, I would argue that the site has at times been too open lately, such as when some user data became reclassified as “publicly available” last fall. But regardless of Facebook’s degree of openness, the company has always been careful to maintain a high degree of control over information and features on the site. This can be positive, such as quickly removing malware links, or negative, such as controversial decisions to bar users or certain content.

Either way, that control has helped the site build a powerful database of profiles that generally reflects real people and real relationships. That’s part of what fascinated me about the site’s recent spat with Google over contact information. In the past, a list of e-mail addresses was about the only semi-reliable way to identify a group of people across the Internet. Now, many sites rely on Facebook’s social graph for that function. In terms of identity, the value of e-mail addresses has declined, and I don’t think exporting them from Facebook would provide as much value as Google might think. On the other hand, Google may realize this and be so concerned about the shift that they’re trying to curb Facebook’s influence. This would especially make sense if Google intends to introduce a more comprehensive social networking product that would need e-mail addresses as a starting point. Regardless, I’m sure Google feels threatened by the prospect of Facebook providing a better alternative to traditional e-mail – a change that would only bolster the value of a Facebook profile as the primary way to identify a typical Internet user.

However, that’s not quite the case. Back in March, I published a guide to exporting data from Facebook using various tricks and FQL queries. Facebook has since made changes and added tools which have made the post a bit outdated, but much of the information still applies. In particular, I described using Yahoo’s contact import tool to download an e-mail address book for all your Facebook friends. This technique relies on a Facebook-approved feature and should not violate the site’s terms of service. A few specific steps have changed a bit, so I’ll recap the process here.

First, you need to have a Yahoo! Mail account. If you don’t already have one, you can create one for free. In fact, I’d advise creating a new account to avoid your Facebook friends’ e-mail addresses getting mixed up with any others already in your address book.

1. To add your friends’ e-mail addresses to your Yahoo! Address Book, follow the steps given on this page at the Yahoo! Mail blog. Essentially, you open Contacts, click on “Tools,” then “Import,” choose “Facebook,” and follow the steps. You will have to authorize a Facebook application built by Yahoo! for this purpose.
2. To save a local copy of these addresses, you can use the export tools in Yahoo! Address Book. Return to your Contacts, once again click “Tools,” and this time select “Export.” You’ll be presented with a list of programs, each with an “Export Now” button.
3. If you’re not sure which you should choose, I would recommend clicking the button next to Microsoft Outlook. You may have to enter a code a CAPTCHA code, but you’ll then be prompted to save a file in CSV format. This is a fairly standard way of saving contact information.
4. Once you’ve downloaded the file, you can use it to import your contacts into other places, including Outlook. You can also open the file in Microsoft Excel to view the contact list or make changes.

The report generated controversy across the Web, and some reactions were strongly negative. On TechCrunch, Michael Arrington dismissed the article as alarmist and overblown. Forbes’ Kashmir Hill surveyed other responses, including a conversation on Twitter between Jeff Jarvis and Henry Blodget, and expressed skepticism over the Journal’s tone.

I’ve been a bit surprised by the degree to which some have written off the Journal’s coverage. Some may disagree with the label of “privacy breach,” but I thought the report laid out the issues well and did not paint the problem as a conspiracy on the part of Facebook or application developers. Either way, I’m glad to see that the article has sparked renewed conversation about shortcomings of web applications and databases of information about web users. Also, many may not realize that information leakage on the Facebook Platform has historically been even worse.

Information leakage via a referrer is not a new problem and can certainly affect other websites. But that doesn’t lessen the significance of the behavior observed in the WSJ investigation. Privacy policies are nearly always careful to note that a service does not transfer personally identifiable information to third parties without consent. Online advertising networks often stress the anonymity of their tracking and data collection. The behavior of Facebook applications, even if unintentional, violated the spirit of such statements and the letter of Facebook’s own policies.

Some people downplayed the repercussions of such a scenario on the basis that it did not lead to any “private” profile information being transferred to advertisers – a point Facebook was quick to stress. Yet when did that become the bar for our concept of acceptable online privacy? Should other services stop worrying about anonymizing data or identifying users, since now we should only be concerned about “private” content instead of personally identifiable information? Furthermore, keep in mind that Facebook gets to define what’s considered private information in this situation – and that definition has changed over the last few years. At one time in the not-too-distant past, even a user’s name and picture could be classified as private.

Many reactions have noted that a Facebook user’s name and picture are already considered public information, easily accessed via Facebook’s APIs. Or as a Facebook spokesmen put it, “I don’t see from a logic standpoint how information available to anyone in the world with an Internet connection can even be ‘breached.’” But this argument fails to address the real problem with leaked IDs in the referrer. The issue was not simply what data applications were leaking, but when and how that data was leaked. The problem was not that advertisers could theoretically figure out your name given an ID number – it’s that they were given a specific ID number at the moment a user accessed a particular page. Essentially, advertisers and tracking networks were able to act as if they were part of Facebook’s instant personalization program. Ads could have theoretically greeted users by name – the provider could connect a specific visit with a specific person.

Interestingly enough, many past advertisements in Facebook applications did greet users by name. Some ads also including names and pictures of friends. Facebook took steps several times to quell controversies that arose from such tactics, but I’m not sure many people understood the technical details that enabled such ads. Rather than simply leak a user’s ID, applications were actually passing a value called the session secret to scripts for third-party ad networks.

With a session secret, such networks could (and often did) make requests to the Facebook API for private profile information of both the user and their friends, or even private content, such as photos. Typically, this information was processed client-side and used to dynamically generate advertisements. But no technical limitations prevented ad networks from modifying their code to retrieve the information. In fact, a number of advertisements did send back certain details, such as age or gender.

Change to the Facebook Platform, such as the introduction of OAuth earlier this year, have led to the deprecation of session secrets and removed this particular problem. I’m not sure how much this sort of information leakage or similar security problems motivated the changes, but problems with session secrets certainly persisted quite a while prior to them. If the WSJ had conducted their study a year ago, the results could have been even more worrying.

Still, I’m glad that the Journal’s research has led many to look more closely at the issues they raised. First, the story has drawn attention to more general problems with web applications. Remember, the Web was originally designed for accessing static pages of primarily textual information, not the sort of complex programs found in browsers today. (HTML 2.0 didn’t even have a script tag.) Data leaking via referrers or a page’s scripts all having the same scope are problems that go beyond Facebook apps and will likely lead to more difficulties in the future if not addressed.

Second, people are now investigating silos of information collected about website visitors, such as RapLeaf’s extensive database. Several responses to the Journal piece noted that many such collections of data provide far more detail on web users and are worthy of greater attention. I agree that they deserve scrutiny, and now reporters at the Journal seem to be helping in that regard as well.

We’ve entered an age where we can do things never previously possible. Such opportunities can be exciting and clearly positive, but others could bring unintended consequences. I think the availability and depth of information about people now being gathered and analyzed falls into the latter category. Perhaps we will soon live in a world where hardly any bit of data is truly private, or perhaps we will reach a more open world through increased sharing of content. But I think it well worth our time to stop and think about the ramifications of technological developments before we simply forge ahead with them.

Over the last few years, I’ve tried to bring attention to some of the issues relating to the information Facebook collects and uses. They’re certainly not the only privacy issues relevant to today’s Internet users, and they may not be the most important. But I think they do matter, and as Facebook grows, their importance may increase. Similarly, I think it wrong to dismiss the Journal’s investigation as “complete rubbish,” and I look forward to the rest of the dialogue they’ve now generated.

Soon after that initial roll-out, security researchers noted vulnerabilities on Yelp’s website that allowed an attacker to craft pages which would hijack Yelp’s credentials and gain the same level of access to user data. TechCrunch writer Jason Kincaid reported on the cross-site scripting (XSS) holes, and made this prediction: “I suspect we’ll see similar exploits on Facebook partner sites in the future.”

Kincaid’s suspicions have now been confirmed, as the latest site with instant personalization also had an exploitable XSS vulnerability, which has now been patched. I’ll quickly add that Flixster, the company behind Rotten Tomatoes, has always been very responsive when I’ve contacted them about security issues. They have assured me that they have done XSS testing and prevention, which is more than could be said for many web developers. In posting about this issue, I primarily want to illustrate a larger point about web security.

When I heard about the expansion of instant personalization, I took a look at Rotten Tomatoes to see if any XSS problems might arise. I found one report of an old hole, but it appeared to be patched. After browsing around for a bit, though, I discovered a way I could insert some text into certain pages. At first it appeared that the site properly escaped any characters which could lead to an exploit. But ironically enough, certain unfiltered characters affected a third-party script used by the site in such a way that one could then execute arbitrary scripts. Since I had not seen this hole documented anywhere, I reported it to Rotten Tomatoes, and they promptly worked to fix it.

I’ve long argued that as more sites integrate with Facebook in more ways, we’ll see this type of problem become more common. Vulnerable applications built on the Facebook Platform provided new avenues for accessing and hijacking user accounts; now external websites that connect to Facebook open more possible security issues. As Kincaid noted in May, “Given how common XSS vulnerabilities are, if Facebook expands the program we can likely expect similar exploits. It’s also worth pointing out that some large sites with many Facebook Connect users – like Farmville.com or CNN – could also be susceptible to similar security problems. In short, the system just isn’t very secure.”

Overcoming such weaknesses is not a trivial matter, though, especially given the current architecture of how scripts are handled in a web page. Currently, any included script has essentially the same level of access and control as any other script on the page, including malicious code injected via an XSS vulnerability. If a site uses instant personalization, injected scripts can access the data used by Facebook’s code to enable social features. That’s not Facebook’s fault, and it would be difficult to avoid in any single sign-on infrastructure.

Of course, all of this applies to scripts intentionally included in the page as well, such as ad networks. With the Rotten Tomatoes roll-out, Facebook made clear that “User data is never transferred to ad networks.” Also, “Partner sites follow clear product/security/privacy guidelines,” and I assume Facebook is monitoring their usage. I’m not disputing any of these claims – Facebook is quite correct that advertisers are not getting user data.

But that’s due to policy limitations, not technical restrictions. Rotten Tomatoes includes a number of scripts from external sources for displaying ads or providing various functions. Any of these scripts could theoretically access a Facebook user’s information, though it would almost certainly be removed in short order. I did find it interesting that an external link-sharing widget on the site builds an array of links on the page, including the link to a user’s Facebook profile. This happens client-side, though, and the data is never actually transferred to another server.

I bring up these aspects simply to note the technical challenges involved in this sort of federated system. I think it’s very possible that we will eventually see ad network code on a Facebook-integrated site that tries to load available user data. After all, I’ve observed that behavior in many Facebook applications over the last few years – even after Facebook issued explicit policies against such hijacking.

These dangers are part of the reason why JavaScript guru Douglas Crockford has declared security to be the number one problem with the World Wide Web today. Crockford has even advocated that we halt HTML5 development and focus on improving security in the browser first. While that won’t likely happen, I think Crockford’s concerns are justified and that many web developers have yet to realize how dangerous cross-site scripting can be. Perhaps these issues with instant personalization sites will help increase awareness and understanding of the threat.

Postscript: This morning, an XSS vulnerability on Twitter led to script-based worms (somewhat reminiscent of “samy is my hero”) and general havoc across the site. This particular incident was not related to any mashups, but once again emphasizes the real-world security ramifications of cross-site scripting in a world of mainstream web applications.

Update (Sep. 27): Today news broke that Scribd had also become part of Facebook’s Instant Personalization program. I took a look at the site and discovered within minutes that it has a quite trivial XSS vulnerability. This particular issue should have been obvious given even a basic understanding of application security. It also indicates that Facebook is not doing much to evaluate the security of new instant personalization partners. Update 2: Scribd patched the most obvious XSS issue right about the time I updated this post: entering HTML into the search box brought up a page that loaded it unfiltered. Another search issue remained, however: starting with a closing script tag would still affect code later in the results page. After about half an hour, that problem was also patched. I’m glad Scribd moved so quickly to fix these problems, but I still find it disconcerting they were there to start with. I’ve not done any further checking for other XSS issues.

Facebook also allows your friends to check you in at locations, and these check-ins are indistinguishable from ones you made for yourself. In typical opt-out fashion, you can disable these check-ins via your privacy settings, and you’ll be asked about allowing them the first time a friend checks you in somewhere.

Even if you stop friends from checking you in to places, however, they can still tag you with their check-ins, similar to how friends can tag you in photos or status updates. Such tags will appear on your wall, as tagged status updates do now. You’ll be able to remove tags after the fact, but it doesn’t seem that you’ll be able to prevent friends from tagging you altogether.

Applications have two new permissions related to places. One gives access to your check-ins, the other gives access to your friends’ check-ins as well. Both will appear in the list of requested permissions when you authorize an application, and they are required for API access to check-ins. If your friends grant an application access to friends’ check-ins, you can prevent yours from appearing via “Applications and Websites” privacy controls.

API access is currently read-only – authorized applications can access your check-ins, but can’t submit check-ins to Facebook. That sort of functionality is currently in closed testing, though.

ReadWriteWeb has a nice guide to applicable privacy settings. When these controls first appeared on my profile, Facebook set the visibility for all my check-ins to “Friends Only” by default and disabled API access to my check-ins via friends by default. But they also enabled by default another setting which makes individual check-ins visible to anyone nearby at the time, whether friends or not. The option for letting friends check me in was not specifically set, but apparently I would have been prompted the first time a friend checked me in.

According to Facebook, you will only be able to check-in at locations near where you are, as determined by the geolocation feature of your browser (or your phone’s GPS for the iPhone app). I’m a bit suspicious on how difficult faking a check-in will be, but I don’t yet have the ability to test that out.

Facebook’s initial geolocation rollout brings a fairly modest feature set, but when integrated with Facebook Pages and made available to a network of 500 million people, the service offers great potential. As with other recent changes, adding check-ins reduces friction for users to share their location and provides Facebook with another valuable set of data about people’s daily activities. It remains to be seen whether users will react with discomfort over the potential for an entirely new meaning of “Facebook stalking” or with excitement over potential new product offerings. Either way, the amount and variety of information under Facebook’s control continues to expand rapidly.

The event title proclaimed “iPhone Testers Needed!” and might be enticing to users who want an iPhone. While the event page included more information on the supposed testing program, the invite was followed by a message from the event creator. Once you’re on the guest list for a Facebook event, the event administrators can send out Facebook messages you’ll receive, regardless of privacy settings. This particular message (which also arrived in my e-mail inbox due to notifications settings) included a link to the iPhone opportunity, which unsurprisingly was a typical “offer” page that required me to submit personal information and try out some service before I could get my fancy new phone.

I began investigating how this all happened. When you create a Facebook event and try to invite people, you’ll only see a list of your friends to choose from. But it turns out that on the backend, nothing prevents you from submitting requests directly to Facebook with other people’s Facebook IDs. In my testing, I’ve been able to send event invitations to other users even if we’re not friends and they have tight privacy settings. I’m guessing that using this technique to invite more than a few people could raise a spam alert, but I’m not sure. Also, an event invitation does not give the event creator increased access to any profile information of guests, but as already noted, it does let event administrators send messages to people they might otherwise not be able to contact.

I’m sure Facebook will take action soon to clamp down on this particular loophole, so I think it unlikely we’ll see it exploited too widely. (The iPhone testing event currently has around 1800 guests – significant, but tiny compared to other Facebook scams.) But it does demonstrate the sort of challenges Facebook is having to handle as their network and power expand. Several years ago, when the site was used for little besides keeping in touch with college classmates and other offline friends, Facebook was seen as mostly spam-free, in contrast to services like Myspace. Now that applications, social gaming friends, and corporate brands have all become integral parts of the Facebook experience, black hat marketers keep finding new ways to spread links among users. And worse, those tricks can often be used to spread malware as well.

I do think that Facebook wants to avoid annoying users with spam, and works to prevent your inbox on the site from becoming as flooded as a typical e-mail account. But a network of 500 million people presents a very enticing target, and we’ll keep seeing new scam ideas pop up as Facebook expands and adds features. In the mean time, continue to be wary of any links  promising a glamorous reward for free.

First, the new interface for making many changes appears to be much more streamlined. This should be a welcome change to those confused by the previous litany of options. The primary privacy page displays a table with columns for “Everyone,” “Friends of Friends,” and “Friends Only,” with rows for several categories of content. This table not only establishes settings for certain bits of profile information; it also lets users set defaults for new content shared.

Second, Facebook has removed the requirement that “connections,” such as your list of friends and the pages you “like,” always be publicly available information. A secondary page will provide access controls for certain groups of these connections, as well as who can friend you, send you messages, or see your profile in search results.

Third, users will have new options related to third-party applications that integrate with Facebook. The company had previously announced a granular permissions model for applications, and developers are in the process of transitioning to the new setup. Those permissions will now be reflected in the privacy settings, though how that will look is not yet clear. (Also, Facebook’s privacy guide assures users that applications can only request “information that’s needed for them to work,” but that’s up to developers.) Facebook is also re-instating an option to completely opt-out from the Facebook Platform. This setting had been available prior to changes last fall. However, it now appears that this opt-out will also be the only way to avoid public content being indexed by search engines.

Zuckerberg promised an “easy” way to opt-out of the controversial instant personalization program, which lets certain third-party websites automatically identify Facebook visitors, but the feature remains opt-out. Many of the other privacy settings are also still opt-out in that the site defaults appear to remain the same, presented as “Recommended” when a new user checks them.

I’ve been concerned about the tone of some Facebook responses to recent privacy concerns, and today’s presentation by Zuckerberg was no exception. He noted that the company had not seen any noticeable impact on site usage lately, and according to one report commented, “Perhaps the personal privacy preferences of liberal advocacy groups and DC politicians don’t match with those of the general public.” That may be true, though I think politicians or privacy advocates have a deeper understanding of recent changes than the general public. Still, this sort of remark comes across as at best somewhat irritated and at worst rather arrogant. It also probably won’t win over any liberal advocacy groups or DC politicians. (For the record, I don’t fall into either category.)

Other aspects of the announcements lead me to wonder how much Facebook truly understands the rising worries over the site’s handling of privacy issues.  Zuckerberg emphasized the site’s focus on sharing, that users want to share, and his belief that people want to share more openly. The default privacy options clearly reflect this belief, positioning Facebook as a site generally intended for public sharing.

But I think Zuckerberg is confusing the desire to share easily or freely and the desire to share publicly. Several researchers have explored how people approach privacy, and people constantly use services such as Facebook to post content they would not want distributed to the entire Internet. We’ve become accustomed to the idea of being private in public, since our offline conversations in public settings are not recorded and indexed for anyone to search. What would be the harm to users if content was private by default, but could be opened to the public if the author wanted that? After all, this is how Facebook operated for the first few years of its existence – and it likely played a significant role in the site’s growth.

Of course, while an opt-in approach may help many users, Facebook wants users to share more openly. More public content provides more value for other services that might integrate with Facebook, extending the site’s reach and influence. That’s part of why I find it difficult to simply accept Zuckerberg’s notion that most people are moving towards public sharing on their own: regardless of what individuals think, Facebook itself certainly has an opinion on how much you should share.

And that’s the real question – how much you share, not whether you share. I’ve never been opposed to making it easier for users to share content. But I do have a problem when a site that was built on sharing with a limited audience reorganizes to make that same type of sharing more difficult than fully public sharing – an activity that carries far more potential dangers, both social and otherwise.

Facebook has built an unprecedented audience of users who give it significant trust. I’m glad to see the company making welcome changes which assist users who actively care about privacy controls. But I remain concerned that the company’s overall perspective still reflects questionable ideas, such as the notion most people are not concerned about privacy, and either fails to recognize the company’s role as a trend-setter or ingenuously downplays it. That’s not a personal attack on Zuckerberg, whom I’ve never met, or anyone else at Facebook. It’s simply my evaluation of the service’s direction based on recent features and public relations. And I think Facebook owes its users much better.

Why the Change?

And why did Facebook make those changes? There’s no technological reason for many of them. Nothing about liking pages or using social plug-ins forced the company to remove old access controls or make “instant personalization” an opt-out feature. Facebook’s executives made a policy and business decision to push users into more public sharing. In many ways, we’re having this debate because Facebook chose to make it an issue.

That’s not a criticism, simply an observation. In fact, many would probably say that Facebook was right to challenge ideas on privacy. Popular tech blogger Robert Scoble has repeatedly argued that Facebook’s changes bring many benefits to users. One writer at Fortune questioned any backlash and gave this response to Pandora’s new social setup: “My first reaction? Creepy! My second reaction: Cool!” Is it wrong to force users into a new situation that’s uncomfortable at first if it ultimately brings significant value?

In this case, however, the ultimate value to users remains unclear. Many users will certainly find advantages to a freer flow of information. But does Facebook really have the right to decide whether content people had previously restricted should now be available publicly? How can any of us judge whether the benefits outweigh the downsides for each user? Many users chose to put information in their profiles that they did not want shared beyond certain limits. If exposing that information seems trivial, are you certain you understand why the profile owner thought limits so important to begin with?

I would argue that by pushing the envelope on our understanding of privacy, Facebook’s leadership made changes that benefit the company, partly by also benefiting developers and partners. That’s not necessarily a bad thing – Facebook is a business and has to make money. But while those changes do benefit some users, perhaps even a majority of users, they also harm the trust of many other users who had shared private content on Facebook.

Where’s the Backlash?

In the short term, the benefits outweighed the downsides for Facebook. Several high-profile users have deleted their accounts, and others are following suit. But keep in mind that even if 10 million people stopped using the site, that would only be a 2% reduction in user base.

As the company faces widespread criticism and possible regulatory changes, you might expect Facebook to back down on some of their changes. I doubt it. Facebook’s executives know the company enjoys a very strong position in the market right now. They can afford losing 2% of users without breaking a sweat. And if people do leave, where will they go?

Given that level of security, why bother talking about Facebook privacy? Why does it matter if techie types bail on the service? Should we simply get used to having less control and move on?

To put it another way, should we let Facebook dictate our understanding of online privacy?

I realize Facebook will probably never go back to the way it once was and that there’s essentially no hope of meaningful competition in the short term. Yet Facebook didn’t reach this place overnight. Industry shifts take time. And many influential people in technology are often on the bleeding edge of such shifts.

Is Privacy Dead?

For the time being, though, Facebook users will likely react in one of three ways. First, they may not understand the implications of updates and keep using the site as before. Second, they might embrace the new capabilities and voluntarily unleash more content. Third, they will decide that they derive too much value from Facebook to let it go, and thus will, perhaps begrudgingly, keep their account – but they’ll be far more careful about what they post in the future.

I suspect that as awareness grows of how much data Facebook now distributes, many people will take more precautions in using the site. That’s not necessarily a bad thing – I’ve long argued for increased education of online dangers. People need to be careful online, regardless of how “private” a service seems. But care is not the same as paranoia or having to manage your identity the way a celebrity might. If Facebook wanted to increase intimacy and authenticity among online friends, they may find they’ve actually done the opposite.

Some people, such as Scoble or perhaps Mark Zuckerberg, have chosen to live their lives with “radical transparency.” Most of us probably still want to keep certain information private, and yet we routinely share that information with parties we trust – even online. I use my credit card number when shopping at Amazon, but I’d prefer they keep it to themselves. When I filled out web-based job applications last year, I often had to disclose my social security number – a small bit of data I would not want passed around. In a more offline example, I’ve often shared personal struggles with close friends in other states by talking with them on my mobile phone.

I realize that a determined hacker could possibly steal my payment info or even my SSN when I send that data to websites. I also know that my phone can be tapped or that my friends could repeat our conversations to others. But based on a wealth of factors, I make a decision to take those risks, since I judge the likelihood of these scenarios (especially given certain precautions I take) to be minimal.

The idea that any data you transmit to another computer should be considered public has significant merit. In practice, though, much of our offline lives face the same technical threat of publicity, and channels have long existed to share electronic data with only a limited audience. Most of us would not want the entire world to see all of our e-mails, and a range of businesses let only certain people access certain servers.

Which brings me back to one of my original points: nothing forced Facebook in a direction away from privacy. They chose it. I doubt whether they would have around 500 million users today if they had chosen that direction years ago. But even if Facebook now thinks I should share all of my content with everyone, I still find value in keeping some information limited. For me, that’s the essence of online privacy. And while one website with a very large audience may have reduced privacy by keeping me from using their features in a limited way, I will continue to exercise control over my data in other ways.

What Now?

The current debate about Facebook and privacy may seem confusing, futile, or even pointless. But it’s important to evaluate the background and ramifications of Facebook changes, especially given the company’s influence on industry trends. It’s important to realize that visible competition and meaningful alternatives to Facebook will require months or even years of development. And it’s important to understand how much privacy still plays a role in the way people manage and share information, whether online or offline.

Perhaps Facebook will end up right, and most people will move away from old ideas about privacy. But I’d rather see companies educate users on new features and empower them to choose more public sharing rather than expose previously private content and encumber such a change with illusory settings. Facebook may try to say most people don’t mind their new take on privacy, but I think they’ll find this debate is far from over.

Facebook’s faced criticism for several security issues over the last few weeks. In April I reported on a vulnerability that allowed applications to be hijacked for stealing data or spreading malware. More recently, a glitch allowed users to spy on Facebook Chat sessions and problems with Yelp showed the risks of cross-site scripting in “instant personalization” sites.

Unfortunately, I have a few other holes to report. I first notified Facebook of these new issues last month, but I wanted to give time for patches before I published details on the problems. Facebook has since made several changes that address some of the issues I raised. However, some of the problems appear to remain. Given the updates and length of time since my reports, I decided to go ahead and post about these issues, but I’m withholding technical details on issues that are still active.

Weak Session Secrets

On April 19, I notified Facebook of a behavior I was observing in applications and Facebook Connect websites. Prior to the new OAuth 2.0 model, the required parameters for a Facebook API request included a session key (identifying the user’s session with the application) and a session secret (a code to verify the authenticity of the request’s source). If an application used an <fb:iframe> or <fb:swf> tag to load content from another domain (such as an advertisement), the request to the other site would include the session key, but not the session secret.

The problem I saw, however, was that the session secrets being issued were part of the session key. For example, suppose Facebook issued this session key: 2.sNXhV4G1ILRKkvdBHoIbTg__.3600.1271682500-00000000. The session secret would then simply be the first set of characters between periods: sNXhV4G1ILRKkvdBHoIbTg__. This meant that any site which acquired a valid session key could extract the session secret and make API requests. While harvesting the session key is not necessarily trivial, the code is passed around more freely than a session secret (such as the advertising example noted above) and vulnerabilities listed below could be combined with this behavior.

I’m not sure exactly when Facebook started issuing weak session secrets, but when I made the report I had observed several of them and tested that I could extract session secrets from session keys. After about a week, I once again saw session secrets issued that bore no relation to the session key, and I could no longer extract a string from the session key and use it to issue API requests.

Arbitrary FBML/FBJS on Facebook.com

On April 14, I noted an even more worrisome issue, and on April 29 I sent a similar problem using a different URI. In both cases, I’d uncovered a way to render arbitrary FBML/FBJS in the context of a facebook.com page without any typical UI chrome. Such a vulnerability presents a range of possible attacks.

First, this could enable the same sort of data harvesting I had demonstrated with the Facebook Platform vulnerability published last month. I could load a Facebook page that included inline frames pulling content from other websites. While <fb:iframe> did not appear to include the session secret in requests, it did include enough information to identify the current user, as well as the session key. Also, the <fb:swf> tag for loading Flash content did include the session secret as a parameter when loading content, even from other domains.

One could also combine the new OAuth 2.0 flow with this issue to harvest a user’s Facebook ID and access public information about them. Essentially, you could imitate the behavior of an “instant personalization” partner on any website, with or without notice. This happened because the OAuth redirect parameters allows facebook.com URIs.

Second, since the page would render on facebook.com, I could load other Facebook pages in iframes and they would not have clickjacking protection enabled. This would allow previously described clickjacking attacks to be launched once again.

Third, it was unclear to me if the vulnerability enabled some further application hijacking by a failure to check a parameter for cross-domain communications. This aspect could have been nothing, but I’ve not done enough testing to make sure.

Finally, the problem presents a dream situation for phishing. Once could easily load a convincing Facebook login form that sends the information to another server – and the URI for the page would appear to be on facebook.com.

Over the last few weeks, Facebook has altered these pages so that they no longer render all FBML or FBJS code. Specifically, iframes and Flash content will no longer work. This prevents many of the attacks described above, especially those that allow automatic data harvesting.

However, one can still render a range of code using these pages, including form elements. That means the phishing scenario described above is still an active possibility. To make matters worse, the parameters necessary to render code can be included in a POST request, meaning the URI in the user’s address bar for an attack page could be a short facebook.com address.

Below is a screenshot of this website loaded in the context of a facebook.com page using the original vulnerability reported on April 14. The second method uses a www.facebook.com page, resulting in an even shorter URI on the address bar.

Social Hacking (theharmonyguy.com) loaded on a facebook.com page

This particular issue actually came from a Facebook feature that was implemented without much security. I knew that fixing it might take some time, since a number of developers depended on the feature involved. I’m glad that some of the threats have been removed, but more still needs to be done before this feature can be considered secure.

Update: Since this post I’ve found a third implementation of the feature, and this method provides an even shorter URI.

Update 2: It appears the feature involved in this FBML/FBJS issue was deployed in July 2008, so it’s quite possible the problems I noted in April have been active for almost two years.