Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Cloud Facebook Security News Your Rights Online

Facebook Connect Exposes Hulu User Data 60

An anonymous reader writes "Over the weekend, Hulu rolled out Facebook Connect integration. Almost immediately after launch, Hulu had to pull the feature as the company discovered a technical issue affecting a limited number of users. More specifically, some users weren't seeing their own Hulu account information upon login, but someone else's."
This discussion has been archived. No new comments can be posted.

Facebook Connect Exposes Hulu User Data

Comments Filter:
  • Hulu's problem (Score:5, Interesting)

    by cgeys ( 2240696 ) on Monday July 04, 2011 @12:04AM (#36650026)
    Nice how to the title tries to imply that it is Facebook's fault when in fact it's only bad coding from Hulu's side. They even admit it:

    The company has admitted that the flaw was the result of a coding and configuration error on Hulu’s side. The company has denied that the issue is the result of hacking, other third party actions, or a vulnerability in Facebook Connect.

    • Re:Hulu's problem (Score:5, Insightful)

      by SlappyBastard ( 961143 ) on Monday July 04, 2011 @12:23AM (#36650084) Homepage
      Good PR: the cure to shitty coding.
      • Re:Hulu's problem (Score:5, Insightful)

        by RoFLKOPTr ( 1294290 ) on Monday July 04, 2011 @01:09AM (#36650232)

        Good PR: the cure to shitty coding.

        You seem to be implying that Hulu is dancing around the fact that they fucked up when they clearly admitted that they fucked up.

        • by Anonymous Coward

          Good PR: the cure to shitty coding.

          You seem to be implying that Hulu is dancing around the fact that they fucked up when they clearly admitted that they fucked up.

          You seem to be implying that people here on slashdot RTFA. Also note that it was an "anonymous reader" that submitted this article with the sensationalist headline.

          I think its pretty fucking obvious what I'm implying, lets hope that this fact ends the thread here.

        • Is it exposing CC data? If not I really don't see what the big whoop is as it isn't like Hulu is offering porn, right? Who cares if someone else knew you watched NCIS or some dumb reality show? Sure having fucked up code is never a good thing, but it isn't like a Sony "whoops we lost your CC numbers LOL!" level of fuckup is it?

          Skimming TFA it looks more like they simply saw someone else's viewing history but TFA is kinda light on details besides "No CC numbers exposed!" so maybe someone who had it happen

          • Is it exposing CC data? If not I really don't see what the big whoop is as it isn't like Hulu is offering porn, right? Who cares if someone else knew you watched NCIS or some dumb reality show?

            A data breach is a data breach. A data breach means there was a vulnerability through which data could be breached. Who knows what other data could possibly have been obtained via those methods? One thing we know for sure is that their security auditing processes before going live with new code are not up to snuff. It doesn't matter if credit card information WAS leaked... but if there was a data breach of any sort, credit card information could potentially leak out eventually. Either way, trust in the secu

    • by Co0Ps ( 1539395 ) on Monday July 04, 2011 @03:48AM (#36650648)

      Probably some script-monkey who wrote:

      // Get account to connect with facebook.
      SELECT * FROM `accounts` WHERE first_name = $facebook_first_name LIMIT 1

    • Your dead wrong. Facebook's user data was exposed, it does not matter who wrote the damn code, it is facebooks fault. Running a major site comes with real responsibilities.
      • It was Hulu's data that was exposed to the wrong Hulu users, not Facebook data.

        This was made clear in the first paragraph of TFA.

        So how is that Facebook's fault? Hate much?

    • I'm not a software engineer but should any bad coding on Hulu's side be able to expose user data from a non-authenticated user? It seems that allowing "bad coding" to display personal information from some presumably secure location on FB's database is a serious security flaw with their API. What stops shady-individual-a from incorporating Facebook Connect into their site and engaging in "bad coding"?
      • I think you misread.

        This bad coding on Hulu's side exposed user data for other Hulu users, it did nothing bad to Facebook users. You could compare it to Dropbox's mess-up when they allowed you to authenticate with any password.

        There is no motive to make this mistake on purpose, because it would give access on your site, it would not affect anyone's Facebook account.

  • by cranil ( 1983560 ) on Monday July 04, 2011 @12:09AM (#36650040)
    "Hulu exposes user data on Facebook Connect"
  • Ahh that old bug (Score:2, Insightful)

    by Anonymous Coward

    The good old static variables (or class variables in a singleton) causing a network application to leak data between sessions.
    Doesn't generally show up in most testing as that's generally done by one tester at a time.
    Relatively innocent to do and relatively major crap-storm that follows because one programmer accidentally used the wrong variable scope for probably 1 or a few variables.

    • Re:Ahh that old bug (Score:5, Interesting)

      by JWSmythe ( 446288 ) <jwsmythe@jws[ ] ['myt' in gap]> on Monday July 04, 2011 @12:59AM (#36650196) Homepage Journal

          I had a friend who had a problem just like that. What had happened in that case was this... Each user was given a session cookie, using functionality included with the language (an older version of ColdFusion). The cookies were a pseudo random number. It was all fine and dandy with just a few users on, there was very little chance of collision.

          When it was introduced to the real world, you didn't just have one or two people on, you had thousands of simultaneous users. Beyond that, the sessions had a relatively long TTL (a few hours, if I remember right).

          Well, User A logs in, does their stuff, and then leaves. No problem. They could have even hit the logout button, but CF didn't properly ditch the session. When User X (someone down the line) came in, they were issued the *same* session cookie. It didn't validate anything. It didn't care what your IP, username, or anything were. So when they reached part of the site dependent on the session cookies, their credentials tied in with User A's session, not theirs.

          Needless to say, the users were not entertained.

          Beyond that, I demonstrated that with a little bit of cookie manipulation, you could access any account that was recently active. I did it with just changing a few things to arbitrary values, and accessed someone else's account. I then had *them* go to the site and log in. They then read me off their cookie information, and I modified my cookie to match. Voila, I'm them.

          They weren't very happy. There was a period of about 10 minutes, where there was some colorful language used. They finally went to work writing their own cookie routine, so they wouldn't have the risk of these collisions any more.

          With the load that Facebook can throw at a site, I'm sure there's a huge risk of collisions. Not ever user would have the luxury, but enough would to make it an issue. Someone should have seen it coming and dealt with it, but obviously it wasn't handled properly.


      • Who in their right mind would use a random string as the sole means of session validation without even checking to make sure that string isn't already in use after its generated?

        Of course, aside from the fact that it shouldn't be your sole means of session validation regardless of collision checks, but still.

        • Ya... Trust me, I agree totally, and my comments were along the lines of "What kind of idiot wouldn't check to see if the session ID was already in use", and "how can you trust *that* as your validation.

          For me, validation is positive validation. It may be browser based (like .htaccess style), a cookie with a hash of some known data (user:pass:timestamp), or a big encrypted cookie with user, pass, IP, user agent, etc. I'm a firm believer, if I need to block someone from an aut

  • by raving griff ( 1157645 ) on Monday July 04, 2011 @12:14AM (#36650050)

    This is why it worries me that Facebook is increasingly becoming a sort of ID badge for the internet--many blogs, for example, now support Facebook Connect as the primary (or only!) way to comment; social networking games (even ones living outside of Facebook) urge or even force users to connect their accounts, etc.

    What control do I retain over my own information? For some sites, sure, it's useful to be able to authenticate my login info with one click (assuming my Facebook is logged in) and it's nice to have a populated friends list for applications such as online games so I know who I can play with, but for some sites (Hulu included), I don't want to give my name, profile picture, and friends list up.

    I use a different, strong password for all of my accounts online, so a website I visit being compromised by hackers doesn't concern me much, but if a flaw in implementation of the Facebook Connect API can leak any information that Facebook gives them out to other people (and potentially out to hackers), I could be facing some serious issues.

    A name and friend list forms a unique thumbprint for my identity that can contribute to identity theft. Hell, I have even seen Facebook hacks that clone your profile and friend your entire friends list--sort of the reverse of having your profile hacked and having to create a new one.

    Bottom line: Facebook has information that I barely trust Facebook to handle, much less other websites, and the use of the Facebook Connect API by a site can have dangerous consequences for its users.

    • by GrumblyStuff ( 870046 ) on Monday July 04, 2011 @12:16AM (#36650064)

      Don't worry. Google+ will take care of everything.

      (I jest but it would be unwise to ignore the lessons of current predicaments.)

      • by Anonymous Coward

        Not that I think Google+ is going to succeed, but isn't Google an OpenID provider? Relying directly on Google accounts for 3rd-party authentication would just be plain wrong.

        • Re: (Score:3, Insightful)

          by Anonymous Coward

          Not that I think Google+ is going to succeed, but isn't Google an OpenID provider?

          So is facebook.

          I would prefer that both were also OpenID consumers (or whatever the heck that is called these days) instead.

          • Facebook does act as an OpenID consumer, you can login with OpenID. It is not a provider, that I know of. They provide Facebook Connect instead.

    • by cgeys ( 2240696 )
      99% time Facebook Connect is offered as an alternative if you don't want to fill the registration form. Sort of like OpenID on Slashdot.
      • by Mashiki ( 184564 )

        The GP is correct, that sites are increasingly moving towards facebook as a means and only means to post comments and sign up for things. 2 national newspapers use it as the only means to leave comments for example, it just gets sadder from there when you see other major sites across north america doing the same thing.

        Personally my form of protest is simply to stop visiting said site and use a major aggregation/rss feed for news.

    • by Anonymous Coward

      Some people call this a good thing, like Jeff Attwood [].

      (I don't agree with him, though).

    • I will never put everything in one basket. I don't even have a Facebook account since they kicked me off for fake/false datas.

    • While I don't use FB for the reasons you lay out, I think the situation is not yet as bad as you portray it. I've canceled my Fuckbook account years ago and have no troubles logging into any web forums, etc.

      I'd be generally more worried about the general tendency to regulate the Internet and turn it into an interactive TV network. The big companies certainly want that, as long as they get their share of the cake, and many governments nowadays seem to be sympathetic to the idea. This "vision" of the future o

    • It was Hulu's data that was exposed to the wrong Hulu users, not Facebook data.

      This was made clear in the first paragraph of TFA.

  • Saw something like that a while back at another company. Their auth code was essentially all static. Worked great for one user. I wonder if it was the same sort of problem. That'd be pretty funny. Whenever I see users getting other users' credentials, that's immediately what I think now.
  • This sort of thing rarely happens when people are coding for free. Check for security advisories in web frameworks like Drupal, WordPress or Joomla; they're usually about things breaking under comically unlikely circumstances. These companies have the money to pay people for testing and QA; shouldn't they reach at least the quality level of FOSS?

    • Excuse me? Wordpress is a security joke, not an example to be held aloft.

    • by archen ( 447353 )

      Open source projects rarely have a deadline, have to come up with some minimal level of results, among many other sources of pressure that end up reducing the quality of code (assuming programmers on the same skill level).

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller