Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

First, Do No Harm: Developers & Bad APIs

Primum non nocere (first, do no harm) – an iconic phrase in modern medicine, yet also applicable to many other fields. This is something I wish more people would think about, developers especially – and primarily when writing new APIs. In general, developers don’t have an impressive history with security – quite frankly, developers suck. Seeing as I consider myself a developer, that’s painful to admit.

Chris Andrè Dale posted an interesting article some time ago that got me thinking: Why it’s easy being a hacker: A SQL injection case study – Chris pointed out the problems with educational material that developers are using, and just how bad the examples are. SQL injection is everywhere and very few examples encourage developers to do it the right way – for that matter, very few are telling developers that there is a right way. I’m sure we’ve all seen similar issues in other areas, not just for SQL injection.

I had to ask, why? How did we end up in this situation? The industry has come so far in so many ways, it’s unbelievable that we still have these fundamental issues. It’s clear that the industry is failing, and these are just a few of the areas:

  • Educational material is riddled with errors
  • Authors rarely understand the security implications of their samples
  • Developers aren’t taking the time to research the right way to do things
  • Developers don’t understand the need to consider security implications

…and I could keep going.

Whose fault is it really? #

If you look at the PHP/MySQL examples that are floating around, you’ll notice something interesting: it’s really, really easy to write bad code. The first examples anyone sees is a simple, one line, easy to understand statement:

mysqli_query($link, "INSERT INTO Persons (FirstName) VALUES ('$_POST[firstname]')")

And this simple command is what people use – with no idea how dangerous it is. The API makes writing bad code easy, but how about good code?

$stmt = $mysqli->prepare("INSERT INTO Persons (FirstName) VALUES (?)");
$stmt->bind_param("s", $_POST[firstname]);
$stmt->execute();

The first example is simple and clear, the second is a bit less obvious. The API design itself is leading developers down the wrong path – it supports two syntaxes, one simple and easy to comprehend – but extremely dangerous, and one that’s more complex, less obvious, but safer. Without understanding the security implications, which syntax do you think developers will pick?

While developers should know more than they do (and I’m not trying to excuse their ignorance) – the years of effort and the daily reports of SQLi breaches should tell us that trying to educate all of the world’s developers isn’t working. As long as the easy way to use an API is the insecure way, we’ll continue to see a steady stream of breaches.

While I agree with Chris that the documentation is a real issue – the APIs are just as much to blame. Bad APIs make for bad developers.

Secure by default #

When a developer is working on a new API, they should ask if they are doing harm with the design. The maxim “first, do no harm” should be running through their head with each decision. Doing no harm – being secure by default, not leading developers astray – really should be the foremost goal of any API.

I don’t mean to pick on PHP’s MySQL API here, it’s just one of many that are designed this way. Look at any API on any platform, odds are better than not that security was an afterthought – if it was given any thought at all.

As anyone who writes code can attest, writing secure code is hard – but when the APIs that developers are given encourage insecure usage, it’s that much more likely that holes will be found. While organizations like OWASP are making some progress in education and awareness, it’s obviously not enough. Platforms need to be updated, APIs need to be fixed – this won’t be a quick process, but we won’t see real change until the APIs are improved.

Adam Caudill


Related Posts

  • Developers, Developers, Developers

    Note: This was written in 2012, but not published at the time. The point is still valid, perhaps moreso than ever and deserves to be made publicly. The content has been updated as appropriate, though the core of this article remains intact from the 2012 draft. I would like to note that this doesn’t apply to every environment, there are some where developers are very knowledgeable about security, and write code with minimal issues – my current employer happens to be one of those rare & exciting places.

  • Threat Modeling for Applications

    Whether you are running a bug bounty, or just want a useful way to classify the severity of security issues, it’s important to have a threat-model for your application. There are many different types of attackers, with different capabilities. If you haven’t defined the attackers you are concerned about, and how you deal with them – you can’t accurately define just how critical an issue is. There are many different views on threat models; I’m going to talk about a simple form that’s quick and easy to define.

  • phpMyID: Fixing Abandoned OSS Software

    phpMyID is a simple solution for those that want to run their own OpenID endpoint – the problem is that its author stopped maintaining the project in 2008. Despite this, there’s still quite a few people that use it, because it’s the easiest single-user OpenID option available. Unfortunately, the author didn’t follow best practices when building the software, and as a result multiple security flaws were introduced. In 2008, a XSS was identified and never fixed (CVE-2008-4730), in the years since then it seems the software has been below the radar.

  • Win by Building for Failure

    Systems fail; it doesn’t matter what the system is. Something will fail sooner or later. When you design a system, are you focused on the happy path, or are you building with the possibility of failure in mind? If you suffered a data breach tomorrow, what would the impact be? Does the system prevent loss by design, or does it just fall apart? Can you easily minimize loss and damage, or would an attacker have free rein once they get in?

  • On Automatic Updates and Supply Chain Attacks

    Once again, a supply chain attack is in the news; this time, it’s a ransomware attack against Kaseya which has impacted hundreds if not thousands of businesses. According to Kevin Beaumont, the attackers used a 0day vulnerability in the Kaseya VSA appliance to deploy a fake update to all systems it managed; that update is actually the REvil ransomware. As this is a VSA is used by Managed Service Providers (MSPs), this resulted in an attack not just on the MSPs but also their customers.