Read this as a cautionary tale, not as a how-to. First, a disclosure. We’re an API system-of-record, so obviously always interested in how APIs are being handled on the backend. Two, we’re developers, so hacking is in our nature.
During a recent conference, one of our devs noticed that an attendee on the leaderboard collected a staggering number of points. More than 2X any other attendee. That sent our Spidey senses tingling. Looking at that person’s profile, we noted a link to a GitHub repo containing two scripts they had used to boost their score. Nothing nefarious here, just some good old fashioned dev ingenuity.
Well, that looked like fun. So, during some down time between presentations, we forked the scripts (one to scrape attendee IDs and the other to visit their profile pages), merged them together to make them a little more efficient, and ran that to automatically visit each attendee’s page and boost our own score. We were right. That was kind of fun.
Here is where it gets interesting. We had a live demo of our product scheduled. In this demo, we wanted to show how our product Resurface captures API calls that can be viewed in real time. What better way to do that than to have people watching the demo get a notification and see the API call related to that notification recorded in Resurface at that same time? We looked around a little and saw that the messaging endpoint was as available as the one for viewing profile IDs. So, we wrote another script to send a message to every attendee. We ran this script in the demo. As intended, attendees got notification of a message and saw the call related to that message recorded. Many were amazed. (Caution: This is where we ruffled a few feathers because of course everyone else at the conference got a message as well. Some were more upset than amazed.)
But it did serve to illustrate the ease of access, and that user authentication cannot solve for all uses. We used the API the same way that Peloton got hacked — verifying that a user is authenticated, but not having access rights at the user level to control what operations they are allowed to run. In the conference example, participants need a level of access to communicate, so how do you prevent this from becoming an abuse or an attack? Or, at the very least, people posting inappropriate comments and images.
The platform owners either weren't aware that people were abusing their public API, or they knew and didn't see a problem because it wasn't affecting everyone directly. Until we sent the DMs to everyone. That got people’s attention.
Hyram’s Law plays out here in risky ways:
With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
We might alter that last line to: “will be depended on, or misused, by somebody.”
Either way, unknowing or ignoring API actions leads to problems that can be prevented by monitoring the API endpoints. For example, you could identify the user and warn them or ban them before they do something worse.
Top comments (0)