June 10, 2016 at 3:53pm - Report Sent 
    ...
    June 10, 2016 at 10:11pm - Bug Confirmed by Facebook 
    ...
    June 11, 2016 at 9:05am - Bug fixed and response by Facebook 
    ...
    June 15, 2016 at 1:20am - Messages exchanged 
    June 20, 2016 at 9:03pm - Asked about bounty decision 
    June 23, 2016 at 1:13am - 5 digits bounty awarded

5 days later and the author had to follow up on the bounty decision before it was awarded?

perhaps this is standard but i appreciate the author putting the timeline in there, this is the kind of information that is important to bounty hunters but is hardly ever talked about.. we are usually more interested in the hack than the monotany

That seems rather speedy to me.

It routinely takes far longer than 2 weeks for clients who have pre-committed to paying me to pay up. That Facebook (as a huge corporation) is able to pay this quickly is actually impressive.

I mean, you're dealing with a planetary megacorp. I know it's facebook, but you should expect to have to fax something and be ready to pull out a DUNS number, SOW, and MSA. The fact that you don't is a miracle.

> DUNS number, SOW, and MSA

What are these abbreviations?

A DUNS number is a 9-digit business ID number from Dun & Bradstreet. Apple requires you to have one if you want to create an organization developer account for the App Store. See http://blog.metamorphium.com/2012/12/03/apple-duns/

Dun and Bradstreet number (a weird business registration number), Statement of Work, Master Services Agreement

SOW is probably Statement of Work. Dunsno about the others.

Msa is master services agreement

tl;dr: API flawz. When you created a comment with a video, you could link somebody's else video instead of yours. Then if you deleted your comment, it would delete their videos.

On an unrelated note, his page linked to this youtube channel that looks pretty awesome! Books animated: https://www.youtube.com/channel/UCXLesGEfmyhxqOjoAqhRwhA

okay, thank you for your explanation. I couldn't figure out what the author was trying to say.

I'd say internal permission system flawz ... scary.

Not only that, but probably a polymorphism-related error? It sounds like the logic might be that dependent objects/relationships in the graph (like reply comments) were what was intended to be deleted, but links to other videos were considered dependent relationships and needed to be deleted as well.

That's a commong thing in permission / capabilities. Either the system is not expressive enough, either you get "false positives" and bounties included.

or maybe insecure direct object reference?

This reminds me of my main concern with GraphQL, namely that I could never find a good example showing how you weave security within a request. The examples I saw made me feel uncomfortable. Like, the client requests progressed further than I felt they should.

My typical approach to securing REST APIs is to use guard clauses + white lists. This is very explicit and easy to comprehend.

Well, similar to REST, security is not in the spec, but in the implementation.

Different than REST, comes introspection. You would have to advertise fields and mutations to some people that you wouldn't to others, which is a bit of an odd paradigm with how you might do this at scale, but it's not fundamentally different than REST, just looks / feels different.

I haven't seen many people write on the subject for Graph -- in our implementation on Vogue.com, we don't have need of multiple auths. All the fields we describe are "public" and we don't support mutations at this point.

The option to look for, irrespective of language of implementation, is "context". An example of usage may be found in https://github.com/graphql/express-graphql. Basically the context (session or user data) is passed into any resolve function you define, so you may relate operations to permissions using some mechanism you define.

Edit: grammar

Nice work and great find. Really surprising this design flaw existed, I don't think I would have even bothered trying it. But Facebook ships a lot of code and features, so it just takes perseverance to find these types of issues.

It's interesting that this neatly overlaps two different features that in isolation appear benign, and probably never appeared together in a single code review.

Out of curiosity, why is that many of the vulnerabilities that

appear in the news, walls of fame, and websites like HackerOne

are discovered by Indians? Is this just a coincidence? Or is

there a better explanation for this?

I do not have reference handy, but recently read (on HN itself, I guess) that there is lot of interest among programmers living in "limited-opportunity" places in India to work on Bug Bounty programs. Obviously, one reason is time on hand. Other motivation could be the bounty itself. Even < $100 bounty is significant income. Thirdly, this honor badge is a ticket to a job interview, if not a job itself, in companies in bigger cities and possibly a better quality of life.

Again, I am theorizing without providing references.

you're right on all counts. add in the indian love of being intellectual or being associated with someone intellectual(you know the guy who discovered the video deleting bug? that guy works at my company!)

Payouts tend to be in the $250 - $5,000 range, IME skewing toward the bottom end for most bugs. If it takes 1-3 weeks to find one valid bug, economically that's not going to make sense for an employed US-based developer to spend their time pursuing. Those figures could allow for an income in the range of $10-$20k, which is ₹1M -- this chart gives an idea of how much money that is:

http://www.numbeo.com/cost-of-living/compare_cities.jsp?coun...

There are a lot of Indians (~1.3 billion), if even a smaller percent of them are programmers, thats a lot of programmers.

Small oversights get made in organizations of all sizes and often have large ramifications, as in this case. Good processes help minimize the exposure but the real world is too messy for them to act as guarantees.

A security-conscious client recently noticed that due to an artifact of MySQL's (terrible) built-in replication, they'd been running production databases with passwordless accounts allowed to connect from any host. If someone on the internet found the hostname and guessed the right username, they'd have full access. This client has stringent controls in place to prevent just such eventualities, but this one slipped through. You can't be perfect.

Computers are hard. The implications are frightening in this day and age, when so much of our business is conducted online, including highly-sensitive governmental business. The recent cyberattacks on servers hosting data regarding high-profile political figures will probably drive a program of mandatory licensure to work in IT as well as an even harsher version of the CFAA, both of which are very bad.

> If someone on the internet found the hostname and guessed the right username, they'd have full access. This client has stringent controls in place to prevent just such eventualities, but this one slipped through. You can't be perfect.

I don't know the details, but this sounds like someone is running MySQL on 0.0.0.0 interface, much like MongoDB's old default.

> This client has stringent controls in place to prevent just such eventualities, ...

Like a firewall that allows anyone, anywhere in the world to connect to the common database ports?

That is, they didn't have a firewall with a default deny policy?

It doesn't at all like they had "stringent controls" in place, to me.

They do have a firewall with a default deny policy, but due to an overlooked configuration issue and a miscommunication on the network team, it failed to include this server (and this server only).

"They should have auditors to make sure that doesn't happen!", you might say. Well, they do. That's how they caught it.

No matter how much someone wants to pretend their process is perfect, the fact is that in practice, simple, embarrassing mistakes can and do happen. Facebook is a company packed with many competent software, network, security, and infrastructure engineers, no one can doubt that. I'm sure they have at least semi-formalized code review processes and a security checklist pre-deployment. Yet they still overlooked this pretty permissions issue which anyone who has ever developed a multi-user web app has encountered.

It's easy to armchair quarterback it, but keep in mind, one day it may be your organization up on HN. Pretending like you're invincible is not productive for anything except your personal ego.

Nice work mate!

This is a classic example for when a developer of an API think that the only use cases are the ones imposed by the UI that the API powers. Thinking defensively would have prevented that bug from occurring in the first place, that’s why I love defensive style when developing. Never trust the client or think that the client is really, “the client"

Too bad it was fixed. Seems like the only recourse content creators had against freebooters until now.

Facebook doesn't comply with DMCA takedown requests?

Annoyingly they take long enough to process that the freebooter has already ridden the viral - and revenue - wave to shore. So a DMCA becomes a hassle for the content owner.

haha...at this scale, SQL or Database needs garbage collector instead of delete function.

I can't reach the site. Anyone have a link I can use?

Here you go! http://archive.is/THOiu

Thank you.

Youtube has a similar bug, it's called DCMA.

I assume you're meaning the Digital Millennium Copyright Act (DMCA), rather than DCMA.

Actually, it's just called "copyright complaint". Youtube's system goes well above and beyond the requirements of the DMCA.

Good Job! But i feel like finding such bugs is hardly noteworthy..

It's absolutely noteworthy. As a person who creates apps, I love reading about these vulnerabilities. Not only does it make me ask "Did I do something like this?" but in general tends to shift my mind to be more security focused.

I think it's interesting and noteworthy and I enjoy and upvote every time such vulnerabilities are reported here on HN.