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
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.
What are these abbreviations?
On an unrelated note, his page linked to this youtube channel that looks pretty awesome! Books animated: https://www.youtube.com/channel/UCXLesGEfmyhxqOjoAqhRwhA
My typical approach to securing REST APIs is to use guard clauses + white lists. This is very explicit and easy to comprehend.
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.
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?
Again, I am theorizing without providing references.
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.
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.
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 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.
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"