Leaky APIs threaten to wash company reputations out to sea

In life, generally, communication is a great thing. There’s no quicker way to come to an understanding, learn something new, or build a relationship. In the software space, APIs serve a communicative purpose that allows applications to talk to each other, boosting features and usability. That connectivity often creates a richer experience that end-users love, and increasingly, have come to expect from the software in their day-to-day lives. 

However, like in real life, it’s a big problem when they talk too much. Experian has recently found this out the hard way, when one of their APIs - used by a third-party partner - potentially leaked the credit scores of… well, just about every American citizen.

The problem was patched quickly, but questions remain on whether this vulnerability was truly stopped in its tracks. If one vendor was affected, chances are good that others were too, and there is the possibility that it is a systemic bug, affecting anyone making use of that insecure API.

API security is an issue that isn’t far from the minds of most security experts, and it’s something we need to equip ourselves with the knowledge to fight. 

Any swashbuckling geek can bypass poor API authentication

A feature of many data leaks, breaches, and security incidents, is that they rarely take a mastermind to achieve. Complex, insidious, damaging attacks like we saw with SolarWinds require teams of cybercriminal geniuses to carry out, and they are the exception rather than the rule. 

When an API is built with weak authentication, it’s rather easy for them to be exploited. Bill Demirkapi, the security researcher who discovered Experian’s API bug, determined that it could be accessed without any authentication. Inputting 00/00/0000 in the date of birth field granted him access to a person’s credit score, using only publicly available information like a name and associated mailing address. While this hasn’t been reported, the potential for these records to be scraped and contextualized as a credit-related data dump (and therefore valuable) is certainly there.

Clean and functional authentication processes should be in place no matter how small the use case; a chatterbox API that is not properly secured, and potentially opening up access to multiple systems, is a liability.

Broken Authentication is number two on the OWASP Top 10 API vulnerabilities list. Read more here on how you can avoid this bug, and test your skills on our platform once you’re done feeding your brain.

Poor API security controls are a widespread problem that requires cultural change

It’s not fair to point the finger solely at organizations like Experian, but the lack of nuance and security control diligence displayed in this particular API exposure doesn’t bode well for the many companies out there that are navigating APIs as part of their IT systems and endpoints. 

In general, we have a lot more work to do in not just finding and fixing API vulnerabilities, but understanding them as part of the attack surface we’re supposed to protect. Visibility over APIs - and how they have been built - is a huge concern, and it’s something that should be demanded as part of security best practices. Even an organization with the most stringent security measures can find itself undone by an API that is published and working outside of the company security controls. It is more important than ever to ask where an API has come from, who ultimately maintains it (is it a third-party vendor? How stringent are they with security?), and what information it is accessing. 

Injection vulnerabilities remain a barnacle for every CISO.

API security may seem like a fairly new module to include in a security program, but it can be exploited by some (very) old tricks we’re used to seeing in plain old web software.

A recently disclosed attack on Accellion revealed that chained SQL injection and OS command execution attacks allowed the threat actors to manipulate APIs, extracting a significant haul of sensitive data, including Social Security numbers. They determined that the attackers had to have had extensive knowledge of Accellion’s FTA software to carry out the heist, which would have been possible through substantial reverse engineering.

With the breach happening over December 2020 and January 2021, there was plenty of time for the thieves to cause damage. Further discoveries in February 2021 uncovered a stored XSS vulnerability, with forensic analysis finding that just one API endpoint having improperly sanitized user input made it possible to inject an argument when calling the admin.pl script. 

With over 3000 customers, including many prestigious educational institutions, this breach could be far-reaching. The unfortunate situation is that these exploits were made possible by leveraging common vulnerabilities, many of which could have been addressed at the code level, pre-production, by a security-aware developer. As we keep seeing time and time again, it only takes a small window left open to create big problems. And a culture of human-led cyber defense needs to be part of the strategy in solving a very human problem.

Want to test your API security skills now in Java Spring API, Kotlin Spring API, C# (.NET) Web API and more? Try some API challenges on our Learning Platform (check out all languages:frameworks via the drop-down):
‍

‍