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
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.
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.
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.
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.
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.
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:
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 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"
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.
[+] [-] justifier|9 years ago|reply
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
[+] [-] morgante|9 years ago|reply
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.
[+] [-] droopyEyelids|9 years ago|reply
[+] [-] baby|9 years ago|reply
On an unrelated note, his page linked to this youtube channel that looks pretty awesome! Books animated: https://www.youtube.com/channel/UCXLesGEfmyhxqOjoAqhRwhA
[+] [-] notwhereyouare|9 years ago|reply
[+] [-] agumonkey|9 years ago|reply
[+] [-] gonyea|9 years ago|reply
My typical approach to securing REST APIs is to use guard clauses + white lists. This is very explicit and easy to comprehend.
[+] [-] brokentone|9 years ago|reply
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.
[+] [-] akeating|9 years ago|reply
Edit: grammar
[+] [-] ohitsdom|9 years ago|reply
[+] [-] Splines|9 years ago|reply
[+] [-] guessmyname|9 years ago|reply
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?
[+] [-] umbs|9 years ago|reply
Again, I am theorizing without providing references.
[+] [-] jessedhillon|9 years ago|reply
http://www.numbeo.com/cost-of-living/compare_cities.jsp?coun...
[+] [-] jrowley|9 years ago|reply
[+] [-] cookiecaper|9 years ago|reply
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.
[+] [-] yeukhon|9 years ago|reply
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.
[+] [-] jlgaddis|9 years ago|reply
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.
[+] [-] istsehrgut|9 years ago|reply
[deleted]
[+] [-] josephko|9 years ago|reply
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"
[+] [-] BHSPitMonkey|9 years ago|reply
[+] [-] icebraining|9 years ago|reply
[+] [-] iamgopal|9 years ago|reply
[+] [-] palakchokshi|9 years ago|reply
[+] [-] eugeneionesco|9 years ago|reply
[+] [-] ParadoxOryx|9 years ago|reply
[+] [-] imadeajoke|9 years ago|reply
[+] [-] colemickens|9 years ago|reply
[+] [-] roachycok|9 years ago|reply
[+] [-] orthecreedence|9 years ago|reply
[+] [-] colinbartlett|9 years ago|reply
[+] [-] pg_is_a_butt|9 years ago|reply
[deleted]