Will Looking For The Low Hang Fruit Of API Deployment Ever Get Me In Trouble?19 Dec 2015
I am hyper aware of where the ethical line exists, when it comes to being a hacker. I'm not a hacker that penetrates systems, or finds exploits, I am a hacker that provides quick and dirty solutions to problems, using technology, which in my case happens to be via APIs.
Through my work as the API Evangelist, I am evangelizing that companies should consider an API approach to help them be more consistent in how they operate online. Helping companies be more transparent in their operations, in a way that encourages participation from trusted partners, and even the public, through sensibly designed, and secured APIs.
When people from enterprise, institutions, and government agencies approach me and ask how they should jump start APIs within their group(s), I have a pretty standard response, which I call low hanging fruit (LHF). LHF is simply this: if their is a spreadsheet, CSV, XML, or JSON file located on your website, or data is available in a table format across your site, it should be available as an API.
If something already exists on your website as HTML, it should also be available in CSV, XML, RSS, and JSON formats, for direct integration into other systems, applications, and devices. The is is the difference between your resoures being available to humans in a browser, and it being available to humans via the thousands of other Internet connected devices that are becoming ubiquitous in our worlds.
For me, this is a pretty fundamental way to help people understand API. To help bring my point home, I have a website spider that will crawl any URL I give it, and return the existence of any CSV, XML, RSS, JSON, or table with over five rows. I then publish this list of resources to a Github project, which I call the "low hanging fruit" for any domain (aka company, organizations, agenc(ies), or institution). If it is available on your website, it should exist as an API. If it is available on your website it has already been deemed valuable, and ok for publicly sharing. Right?
Well, this isn't always the case. You see, a lot of people publish data and content on the open Internet, and believe it is secure, if they are the only ones who know the URL. Many folks are unaware of how things work on the web, and accept security through obscurity as a sensible way of operating in our digital worlds, simply because they just do not know any better. The Internet has pushed its way into our personal and business lives so fast, many folks just do not fully grasp what it is, and how to properly protect themselves, their children, their jobs, co-workers, businesses, organizations, constituents, and customers.
As I read yet another story of a security breach, this one at children's toy manufacture V-Tech, I'm reminded of the line I walk in my API Evangelist world. The hacker in question, shared the fact that V-Tech's online security was pretty superficial, and shared that he was able to get at 5M parent's and children's accounts. He didn't do it for profit, and sell to the black market, he shared the details with Motherboard, to apply pressure on V-Tech to tighten down security.
I will make clear, I do support folks poking around for security holes like this, even though it is not something I do not personally do. I will scan the public surface area of any companies site, or mobile application(s), but I understand the public / private line that exists, and will never intrude beyond the line I am closely walking. The problem is, while I have a good grasp of the line I walk, I do not have the faith that others will share the same understanding of where this line exists, or even that it exists all.
When I publish a list of low hanging fruit for any domain on Github, one can easily perceive what I did was hacking (it is). The slippery slope in process of scanning a public website, following every link within the domain, and indexing the available data sources, is that you can uncover loose privacy and security practices, and the ignorance and incompetence that exists at any business, organization, institution, or agency. The not so fun part of all of this exists in the current climate, where we go after the person who uncovers the problems, not usually the folks who created the problem.
In my low hanging fruit process, I'm not using SQL injection, or other common security exploits, I am simply spidering what is already publicly available on a website. The problems comes when people in power, do not understand the difference, and in this current, very lopsided environment, there is a huge chance of getting swept up on the wrong side of the perception and understand of exactly what hacking is, or isn't. I acknowledge these dangers exist, but will be pushing back, hoping to change the perceptions that exist, whenever I possibly can.
I strongly believe in APIs, and when done right, they can benefit businesses, organizations, institutions, agencies, and the public and markets that they exist in. I think low hanging fruit is a great way to help individuals effect change from the bottom up, by demonstrating the API potential, using safe, already available resources. Groups that embrace a domain-wide API first strategy will have their houses in order, and will be more respectful of privacy and security of those that do not. The problem comes when we apply a low hanging fruit process in some of the more disorderly households, where ignorance, incompetence, or even straight up corruption exists--the power will bite back hard.
I write this post to help me set a stage, that will hopefully keep me out of trouble, as I continue to help groups understand where to begin with their API journey. As I do this, the security, surveillance, and privacy world seems to becoming much more volatile around me, which tells me my work is all the more important, but also runs the risk of being misunderstood. What a crazy digital world we are creating for ourselves, I worry about our future.