Months Later, Old Facebook Privacy Problems Remain

I’ve tried. I’ve tried to give Facebook the benefit of the doubt. I’ve tried to look at the positive aspects of their service. I’ve tried to bring attention to issues and wait for solutions. I’ve tried to provide solutions. But tonight, I’m ready to give up on Facebook. After all the privacy and security problems I’ve seen with the Facebook Platform, I have to conclude that you should consider every action you take and all the content you post on Facebook to be public. If that bothers you, stop using Facebook.

Some might contend that this is the Internet we’re talking about – it’s supposed to be public. Partially true, but many web sites provide services intended for private use. I can use the Internet to check my bank account balance, open a new credit card, and contact my doctor. None of those are public activities. While I’m not naive enough to think that any online activity can be considered 100% secure, I can accept services that provide a reasonable level of privacy and security.

At one time, Facebook fell into that category. I used it to communicate with friends about my life and their lives. I exchanged messages, photos, and ideas never intended for public consumption. All the while, I relied on Facebook’s legendary privacy controls to ensure my content reached its intended audience only. Originally, Facebook didn’t simply discourage you from public sharing – it wasn’t even possible. You could hardly even communicate with people who had not approved you accessing their profile.

Eventually, Facebook introduced the Facebook Platform and began shifting priorities. They faced controversies along the way, from deceptive ads to the failed Beacon program. Most recently, they rolled out new privacy settings which many have criticized. In the midst of all these stories, I’ve spent time sifting through both news reports and code to understand what exactly was happening with my data. This started as little more than a hobby, but eventually it became more serious as I made some disturbing discoveries.

One such discovery involved noticing that advertisements in applications were making requests to the Facebook API for user information. The ad network queries were broad in scope and used to target ads more effectively. I first wrote about problematic ads in June of 2008, but the first time I confirmed that ads were exploiting the Facebook API came in June of this year. I discovered that applications were leaking a “session secret” to ad networks, allowing the ads to hijack application credentials and access user data.

Once I understood the power of a session secret, I began exploiting previous cross-site scripting vulnerabilities I’d uncovered to access user information. One of these holes dated back to at least February 2008. This initial work eventually led to the Month of Facebook Bugs, which spanned September of this year. The project demonstrated XSS issues affecting over 9,700 Facebook applications, all of which could be exploited to access user information (FAXX hacks). The list included many top applications, including ones supposedly verified by Facebook.

I’ve seen Facebook claim that they monitor API requests to avoid rogue applications harvesting user data. But after watching ad networks make broad requests for weeks, I had trouble seeing how they were being proactive. Similarly, while Facebook worked to patch all of the holes I reported in September, they would often give developers my contact information for help with the issues, and were quite obviously not actively watching for XSS problems in applications.

But as I said, I’ve tried to give Facebook the benefit of the doubt. When it came to problematic advertisements, Facebook seemed to take some action, and more recently I’d thought the old problems were essentially gone. As for application security, some could argue that it’s not Facebook’s responsibility to monitor application issues. However, with the brand association of the Platform and application XSS holes exposing loads of user data, Facebook owes it to their users to prevent more FAXX hacks from appearing.

I give that lengthy recap to explain what I report next. On day 25 of the Month of Facebook Bugs, I posted a vulnerability in an application called Photos I Love. At the time, it had just over one million monthly active users. The hole remained live for about a week after I first reported it, but eventually it disappeared. Photos I Love now has more than 2.3 million monthly active users.

But it also still has some of the same ads I criticized back in June. The application loads advertisements from SocialCash, and while the ads do not display and profile pictures or names, the code for the ads does load most of the information in a user profile. This code is executed within the context of the page, so the data is not necessarily sent back to SocialCash, but a few bits are definitely sent back, and with a few code changes by SocialCash it could all be sent back. In fact, SocialCash does receive a session secret via referrer URIs, and I’ve repeatedly demonstrated that such a setup allows for the full range of session secret API requests.

Even worse, the application still loads an iframe for SocialReach, one of the first ad networks banned by Facebook. The SocialReach iframe doesn’t actually display any ads, but it does load code with a session secret that makes broad API requests to Facebook. Fortunately, these requests currently fail, likely due to a mishandling of the session secret, but once again, a few code changes by SocialReach would start the data flowing again. Finally, the session secret is also leaked to affiliate marketer Gratis Network via referrer URIs.

After these rather appalling discoveries, I poked around Photos I Love a little more, and within minutes found another cross-site scripting vulnerability that could be exploited to hijack application credentials and access user information. I’ve found several FAXX hacks in applications since September, and the Facebook Platform Policy Team even asked once if they could copy me on e-mails to developers so that I could confirm patches directly. I wrote this in reply:

I don’t mind you cc’ing me on e-mails to developers, but I couldn’t make any guarantees on how much time I’d be able to invest re-checking holes or helping developers out with details. I view these reports as a courtesy, and try to provide enough details for you to verify where the vulnerabilities occur. Again, I don’t mind helping and am not trying to hurt anyone, but I’m also doing all of this as volunteer work and have other projects that take priority. And while I don’t want to sound rude, if Facebook were really concerned about XSS holes in applications, why not look for them in-house? I think the Month of Facebook Bugs report demonstrated how common such issues are, and that was mostly from me spending a few hours poking around various popular apps.

Cross-site scripting issues are a problem in any application. But when they occur in a Facebook application, they compromise Facebook itself in a very real sense. Yet if the Month of Facebook Bugs is any indication, XSS is widespread on the Facebook Platform. And while I noted in September that applications may include vulnerabilities besides the ones I posted, this second hack of Photos I Love gives firsthand evidence.

All of these issues lead me to conclude that Facebook values public sharing and advertising dollars more than users who want to communicate more privately. The content you post and the actions you take on Facebook are at times more easily accessible to applications, advertisers, and injected code than to your own friends. Perhaps those who want to broadcast publicly or use free social games are fine with such an arrangement. But it’s certainly not the Facebook I signed up for.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Facebook Knows What You Did Last Summer

Pardon the creative title. In working on accessing Facebook photo albums lately, I noticed that one of the stories on Mark Zuckerberg’s privacy settings mentioned that he’d removed his events from his profile. After finding a way to view public photo albums, I wondered if I could find a way to pull up a user’s public events. That pursuit taught me a little more about Facebook’s privacy settings, and also raised another aspect of Facebook privacy I’d not previously considered.

At first, I followed the same approach as with photos – I tried to make special requests that imitate what happens when you click on a tab in a user’s profile. Doing so brought up no event information for Mark Zuckerberg, but did for a friend of a friend. It turned out this behavior could actually be controlled by a user’s privacy settings. However, the setting may not be where you’d expect – it’s on your application settings page. Facebook treats their events module as an application, and in the settings for the Events application is a field controlling who can see the application. Setting it to “Only Friends” blocks the trick I was using if you’re not the person’s friend; I’m guessing the same setting for the Photos application would block the bookmarklet I posted.

But while Events does appear in the application settings page, it’s not your average application. I knew that the Facebook API included commands for requesting event data. I loaded up Facebook’s API Test Console, set the method to events.get, and put in a user ID.

What came up surprised me – a complete record of practically every public event that user had been invited to. Note that this was not a friend of mine. I could easily filter by whether they had RSVP’d that they were attending the event.

The list only includes “open events,” (Update: “Closed” events are also visible, just not “secret” events) those that are publicly accessible. But the results reminded me of the controversy over Facebook’s original News Feed – while the feature didn’t expose any new data, it made it much easier to access. I’m guessing most Facebook users do not realize you can pull up a list of all the public events they’ve attended so easily.

Also, any application that a user authorizes also has access to secret events a user has been invited to, since the application operates on behalf of the user.

Seeing years of events come up when I put in my own Facebook ID was a wake-up call for me. I handle event requests routinely, but hadn’t really ever given thought to the fact that Facebook has stored all that information – and makes it accessible to others (for public events) and applications. It’s one more aspect of privacy that Facebook users may want to reconsider.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Easily View Hidden Facebook Photo Albums

In a previous post, I noted that Facebook had removed access to photo albums for any user not your friend. Soon after Facebook rolled out new privacy controls, some users noticed that they could view anyone’s photo albums marked visible to “everyone,” most notably a few from Facebook’s founder, Mark Zuckerberg. Soon after those reports, however, it appeared that the albums were no longer available, as “Photos” tabs disappeared from public profiles and visiting photos.php simply gave an error message.

But as I described, access had not been cut off – Facebook had simply made the albums harder to find. This practice, known as security through obscurity, can mislead users who think their hidden content is safe from prying eyes. To prove my point, I gave directions on how to load the public photo albums of any given Facebook user.

Those directions were a bit technical, however, and I wanted to make the point more obvious. After working through more Facebook code, I came up with a bookmarklet (a bit of JavaScript you can store as a bookmark in your browser) for viewing public photo albums. Bookmark this link, or copy the code below. (Tested in recent versions of Opera, Firefox, and Chrome.)

javascript:(function(){function y(){if(x.readyState==4){q=x.responseText.substring(9);p=eval(‘(‘+q+’)’);document.getElementById(‘tab_canvas’).innerHTML=p.payload.tab_content;}}x=window.XMLHttpRequest?new window.XMLHttpRequest:(window.ActiveXObject?new ActiveXObject(“MSXML2.XMLHTTP”):null);x.onreadystatechange=y;x.open(‘POST’,’http://www.facebook.com/ajax/profile/tab.php’,true);x.send(‘id=’+ProfileURIController._profileId+’&v=photos&__a=1′);})()

Once you’ve saved the link, simply visit someone’s public Facebook profile, then load the bookmarklet. It will replace the body of the user’s profile with a list of links to public albums, if any are available. The results are not formatted well, and only include the first page of albums, but the code works enough to at least demonstrate that public albums are not as well-hidden as you might expect.

I’ve browsed through some random profiles, as well as some more prominent Facebook users, and I think many would be surprised by how many photos I was able to access through this trick. Note that this code does not circumvent privacy settings in any way – it simply makes visible albums you can rightfully access but that Facebook has hidden from view otherwise.

At some point, users who have followed default album settings in the past and left many photos accessible to “everyone” are in for a shock when they realize the implications of those choices. I personally think it best for them to realize that now instead of later, which is why I decided to release this technique.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Positive Developments from Facebook

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.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Facebook Application Privacy Confusion Continues

Many technology journalists and privacy advocates have criticized aspects of Facebook’s new privacy controls and default settings. But I’ve noticed one aspect to the changes that I find disappointing, and thus far I’ve not seen it noted elsewhere.

You may recall that earlier this year, Facebook came under scrutiny by the Privacy Commissioner of Canada. Several concerns the Commissioner’s office raised related to Facebook applications. Readers of this blog were already quite familiar with privacy issues relating to applications, but the Canadian investigation brought them to the forefront, and Facebook responded by promising sweeping changes to their platform.

When the new privacy controls launched on my own Facebook profile, I took a look at the section for “Applications and Websites.” At first, my feelings were mixed. Facebook had finally made it clear that the checkboxes of various fields you could elect to share applied only to applications your friends used. (The previous setup was far more confusing and led to even major technology sites errantly reporting that the controls applied to applications you used as well.) But Facebook had also removed the option to exempt yourself from the Platform completely.

But then I clicked the button to “Learn More” about what I shared when using applications and web sites. I’ve long talked about the need to educate users, so perhaps this would finally clarify how much access applications have. Instead, I was stunned to read this statement:

When you visit a Facebook-enhanced application or website, it may access any information you have made visible to Everyone (Edit Profile Privacy) as well as your publicly available information. This includes your Name, Profile Picture, Gender, Current City, Networks, Friend List, and Pages. The application will request your permission to access any additional information it needs.

Excuse me?

At first, I thought this was simply false. The way I read it, authorizing an application gave it access to your PAI and anything visible to “Everyone,” but if the application also wanted, say, your favorite movies, it would ask you first. While Facebook has vowed to eventually roll out such a setup, it has not yet appeared and was not promised to be fully in place until fall of next year.

But then I realized what the paragraph was actually communicating. An application has access to your PAI and anything visible to “Everyone” as soon as you stop by – no authorization necessary. (This may lead to a few surprises and scares in the near future.) That last bit about requesting your permission for any additional information refers to authorizing the application. In other words, if the application needs any more data, it will request authorization – which gives it access to all of your personal data.

Some may counter that the confusion here lies with me alone, and I ought not presume that users will make the same mistake. However, given that users have already been trained to authorize applications before using them at all (not to mention whether users even distinguish applications from the Facebook brand), I’m quite certain this new paragraph will continue to produce the sort of myths I’ve seen published about the old application privacy settings. In any event, Facebook has resorted to language that could at best be described as somewhat vague.

Please correct me if you think I’m wrong, but I find the last sentence of Facebook’s new explanation very misleading. It gives the impression that applications will politely ask users for more personal details if they become particularly necessary, when in fact most people who use a given application have already authorized it and thus already given it full access to personal profile information.

After all of the controversies, studies, confusions, misstatements, and problems that have come about this past year regarding privacy and Facebook applications, and especially in light of the previous pressure from Canada, I would have thought that Facebook would take this opportunity to add a more thorough and clear exposition of what applications can access and do with user information. Perhaps I’m being too hard on their new attempt. But if the past is any indication, I expect user misunderstandings over Facebook applications to persist.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

With Facebook Privacy, Everyone Means Everyone

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

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

New Facebook Privacy Settings: For Better or For Worse?

Everyone has probably already heard that Facebook rolled out new privacy settings today.  If you haven’t seen them or gotten the following pop-up box on login…you will soon:

message1

There are a great deal of articles already out about how this is such a great improvement and how these new settings give you more control over your privacy.  However, I would argue that these settings may possibly open up more issues then they are trying to prevent.  The best article on the new settings and the privacy implications is the one that the Electronic Frontier Foundation (EFF) released today titled: Facebook’s New Privacy Changes: The Good, The Bad, and The Ugly.  I recommend everyone (no pun intended) read this article as it provides much more detail then I will provide in this post.

What I want to do is provide you with a summary of the good and the bad of the new privacy settings.  I also want to give a security professional’s point of view on these settings.  As a penetration tester I can tell you that my job just got way easier!  You may have read my series on Enterprise Open Source Intelligence Gathering in which I tell you how you can find information on social networks about your company and employees.  Well, searching for information on Facebook just got easier thanks to status updates being available using new technology like Google Real-time Search!  Ok, on to the better and the worse!

The Better?

  • The new way privacy settings are “managed” is a good thing.  It’s easier to find and navigate through the settings.
  • I like that they ask you for your password to change privacy settings.  It’s just another layer.  Now, this doesn’t help much if you have a keylogger installed but it seems they put this in to prevent bots that may have taken over your account access to your settings.  Again, not fool proof but another layer.
  • The ability to fully customize privacy settings on all the content you post.  So for example, you can specify if you want everyone on the Internet to view your status updates (more on that in a minute) or Friends, Friends of Friends and Custom.
  • Users are now somewhat “forced” to check out their privacy settings.  It’s more accessible that’s for sure.

The Worse?

  • Your Name, Profile Picture, Gender, Current City, Networks, Friend List, and Pages are all available to be viewed by EVERYONE on Facebook! You cannot change these settings at all.  Note, there is a way to remove your entire Friends List from your profile but it’s all or nothing!  Here is a screen shot of this. You have to set it in your profile page using the “edit” button and check the box.These changes are quite disturbing considering that you used to be able to restrict this type of information.  I really believe that Facebook has done this on purpose so *more* information is being shared about you while stating “enhanced” more granular privacy settings.  If you have been to one of my talks in the past I always mention that social networks need to find ways to make money.  The way they make money is off of the information you share!  If you don’t get a choice about the basic information anymore…that’s more money in their pocket at the expense of your privacy.
  • What about the security ramifications of this? It opens up a whole new world for cyberstalking, predators and other attackers.  If you were someone that didn’t feel comfortable sharing this information in the first place, your choice is gone.  Sure, you can lock down your profile so no one can search for you but if you do that…why are you on Facebook to begin with?  You *have* to let your real friends search for you at some point!
  • By default Facebook “suggests” that you set your status updates to “Everyone”.  Here is the thing with status updates….Everyone means everyone on the Internet!  This is where new technology like Google RTS comes into play.  Imagine how easy it will be to find the latest information on “Tiger Woods” or now everything YOU are saying on Facebook, Twitter and other social networks.  Enter in some social engineering and things just got easier for attackers looking to use you or your information (which is easy to figure out now that I can see your friends, and things that interest you via the pages your a fan of).
  • Lastly, Facebook removed the ability to prevent Facebook applications your friends installed from pulling your “public” information.  That option is now gone and applications that your friends install can now view your “public” info.  Remember kids, “public” info is now: Your Name, Profile Picture, Gender, Current City, Networks, Friend List, and Pages.

One final note…be sure to double check all your privacy settings after you run the wizard.  I found a few settings that reverted back to settings I never had.  So what are your thoughts?  Will this make you lock your profile down more?  Do you care?  Is privacy dead anyway? Will Zombies destroy us all? :-)

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


Security in Syndicated and Federated Systems

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.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

1 6 7 8 9 10 22