User impersonation code always terrifies the bajeebus out of me.

You only get to see your own profile. It's a very useful tool to make sure you're not leaking data you people you'd rather not give it to.

> You only get to see your own profile.

Well, when it doesn't have a security hole.

Well, thanks to Facebooks "View As" functionality, I recently discovered that their privacy setting "Only Me" does not work for only me, if another person is tagged in the picture. Meaning that if I have a picture with my ex somewhere in profile, set to "Only Me", it actually means "Only me... and her".

Right, the interface isn't very clear but instead of "Only Me" it shows "Only Me (+)" and if you hover it says: "Only Me, Anyone tagged."

... until the mechanism turns out to have an exploit, as just happened here.

Could have been any other mechanism on the site.

...but it wasn't. Which is the point, no?

I don't think that matters. "I hate travelling by air because the plane can crash" is a true statement for many people... but statistically, that's not the method of transportation that kills people.

The fact of the matter is... ACLs are hard to get right. It's even harder when you have various roles that can be checked against the ACL (logged in user, batch job, logged in user impersonating someone, etc.) . But in the end, complexity is what's scary, not some feature that depends on complexity.

> The fact of the matter is... ACLs are hard to get right

This sounds similar to different distros of linux. Some are security focused where nothing is allowed until it is explicitly allowed. Other distros try to be more "user-friendly" and pretty much everything is open.

Starting from a wide open starting point and then trying to batten down the hatches afterwards does seem to the harder way to do it, but that's exactly where FB is. They wanted everything open, and then had to decide to start limiting that data. FB was designed as a place to share info. If you posted it, you wanted to share it. I totally get that mentality. However, as devs, I can imagine that we have all built something that the end users use in a way not envisioned, and we've probably all had "you're holding it wrong" lines of thinking. Once you get to that point, you can alienate users by telling them to stop doing it that way or embrace what's happening, and then make it work for them. Seems like the perfect situation to where bugs can get introduced.

Which is why the point doesn't make sense. The article says tokens were leaked. There are plenty other places where such bug could happen, so it shouldn't serve as a strong validation of "User impersonation code always terrifies the bajeebus out of me".

(Not to mention it's not really user impersonation, it's just filtering your profile page based on computed access level of one of your friends.)

Something similar happened 8 years ago. https://techcrunch.com/2010/05/05/video-major-facebook-secur...

if ( loggedin_user() ) { }.... oh shit wait, since it is viewAs it's not that it's current_user() oops.

Stealing the access token is the worst possible attack, because it wouldn't get logged or lead to any sort of notification. If they were only able to steal the passwords, this would have gotten caught immediately.

Isn't this the second time this feature has been exploited? I thought I remembered a similar issue from a while ago.

Yes, there have been other cases of exactly the same issue. I recall a case where it was possible to pretend to be people via the chat system while using “View as”.

I think they’ve been breached like this previously. What a mess.

Am catching up. Would these tokens be the signed JWT’s, if so am wondering how they were able to figure out the signature part?

I imagine you just "replay" the issued/signed JWT to Facebook, so you can act like that user.