If you were searching for epic Lord of the Rings materials and came across this blog post, make sure you read the first installment before continuing on your journey.
Repeating the Geek Alert
Like I said in the first installment of this two-part series, be warned that this post contains analogies comparing Web API security to the epic fantasy trilogy The Lord of the Rings by J.R.R. Tolkien. I am still unapologetic about going full geek in this short series.
Now let’s finish this adventure and retire to our comfortable home in the side of the hill!
Continuing the Journey
To quickly reiterate, one of my favorite parts in the books comes very close to the beginning of the series where the Fellowship of the Ring starts on their journey and are having a heck of a time making any progress. The first two issues are what I covered in the first post, and those are:
- They run through a list of paths to take to get to Mount Doom (the only place they can destroy the Ring), and they decide to take a mountain pass. But an extremely strong snowstorm – which the group suspects is magically created by their enemies – hits them on the pass and they turn back to take an alternative path.
- After the failure of the mountain pass, they decide to go through the dwarven Mines of Moria as a shortcut. But it takes a bit to find the doors, because the door was designed to only be found when the Moon shines upon it.
And now we rejoin our heroic group. Things are getting better, but they’re still struggling:
- They eventually find the door to the Mines of Moria, but Gandalf the Grey (the powerful wizard leading the group) can’t figure out how to open it. Part of the writing on the door says “Speak, friend, and enter.” Gandalf tries a bunch of passwords, but the door won’t budge.
- Gandalf eventually figures out how to get into the door: he simply says the Elvish word for “friend” (it’s “mellon”, in case you’re curious), and the door opens.
How Does This Thing Work?
In the book, the instructions for getting through the door are literally written plainly for everyone to see. They simply say, “Speak, friend, and enter.” All Gandalf has to do is follow those instructions, and Moria will be open to them! But just because the instructions are there doesn’t mean Gandalf knows how to follow them. The simplicity of the message baffles him.
Thinking in terms of an API, the instructions – or documentation – for most APIs are readily available (like I said in the first post: “Web APIs are… meant to be found and used…”) and fairly easy to decipher. Read these excerpts from a blog post at swagger.io:
Catering to the developer is tricky. They’re analytical, precise, and are trying to solve important problems with your API. They want to understand how to use your API effectively, which is where API documentation comes into the picture.
Your API is a means to an end for the technical user, and they want to integrate as quickly as possible to move forward in their software development, meaning they should immediately understand the value and usage of your API.
In short, API documentation is meant to be easy to decipher. The problem is that API security is still a fairly new concept. Because of that, most legacy security tools such as traditional web application firewalls can’t take advantage of that documentation to build protections for APIs. And there are still many, many legacy WAFs deployed all over the Internet providing inadequate protections.
Modern next-gen WAFs and other API-specific security tools take that documentation and interpret it to create custom and flexible protections that don’t rely on static, outdated signature tech. Gartner calls these modern tools Web Application and API Protection (WAAP) tools, and they are needed to build modern security into modern API deployments.
Speak the API Key and Enter
Of course, Gandalf finally figures out the trick to the simple phrase. All he has to do is say the word “friend” in Elvish, and the doors open. Now, I think that most of you reading this are cybersecurity professionals of one kind or another. And even if you’re not, you probably know that writing a password down in plain sight is not a good security practice. But that’s exactly what was happening in this scene. The password, albeit somewhat obscured by a simple riddle, was written for all to see.
Now, think about API keys. In their most basic form, with no other security measures placed around them, API keys are nothing but semi-complicated usernames and passwords in code (Daniel Miessler says the same thing in his – admittedly old – post about 2FA security and APIs). If there are no controls around the API keys, exposure is very likely. And since APIs are generally expected to be exposed for use over extended periods of time, those unsecured API keys may stay exposed for large periods of time. Just like usernames and passwords, they will end up on a list somewhere for attackers to use and abuse.
Protection of API keys can be implemented programmatically by developers through various means. And secure coding techniques can go a long way to protecting API keys. Another way is through the deployment of an API gateway to enforce encryption (among other best practices) at a single point – though this doesn’t protect APIs that aren’t passing through the API gateway (rogue APIs created through shadow IT is a real problem).
There and Back Again
I started out by analogizing the snowstorm that The Fellowship endured on the road to Mount Doom to the potential wall of defenses put up by a security team trying to protect a web application. While the “snowstorm” may be effective, a determined attacker will pivot to find an easier target. And APIs are very often much easier to breach than a modern web app with good controls.
Next, I compared the not-so-difficult task of finding the door to the Mines of Moria to the attacker trying to find an API. I have heard the argument that APIs don’t need all the security of a web UI because APIs aren’t meant to be accessed directly. But APIs are meant to be easily found and used by developers, so what’s to keep them from being abused by an adversary?
Then came the simple phrase that stumped Gandalf: Speak, friend, and enter. The instructions for opening the door to the mines were clear and visible. Yet Gandalf couldn’t interpret them. If you’re using an older, legacy WAF to protect your web applications, you most likely can’t depend on it to protect your APIs. They can’t pull in the API documentation like modern WAAP technology, just like Gandalf couldn’t interpret a simple riddle.
And finally, Gandalf had an epiphany and figured out that the password was written for all to see. We all know that is not a good security practice, and exposure of API keys is not good practice either. While they may appear to be complicated because they are “all code-ey and stuff” (thanks for that, Daniel Miessler), they are really just passwords that can be abused if known to adversaries.
And now our journey is complete. For those who have stayed with me on my geek adventure, I thank you. Now, let’s sit down, put our feet up, grab our best pipe, and hope no one from Mordor tries to attack our APIs.
***
This blog was written by Michael Farnum, Chief Technology Officer at Set Solutions.