Time to continue our journey on 'Fundamentals of API Security' and take a look at how hackers can manipulate your API microservices, often leading to financial gain.

After successful recon and gaining intel on your API microservices, hacker will start moving towards the API Manipulation phase. The goal here is to extract data, alter data or in certain cases even delete data from your microservices.

What does OWASP recommend for API Manipulation?

OWASP ranks three very important risks in their API Security Top 10 that are heavily focused on the Manipulation phase.

1. API5:2019 - Broken Function Level Authorization
2. API6:2019 - Mass Assignment
3. API8:2019 - Injection

Broken Function Level Authorization

With microservices architecture, more and more API endpoints are created and as typical ‘API design best practices’ are applied. Many of the common API design structures that you see are using the same API endpoint but changing the HTTP Method to change the action.

While the GET method to retrieve data is very common, API design best practices states that the same API endpoint should be allowed with either POST methods (to create new objects), the PUT method (to alter existing objects) or the DELETE method (to delete objects).

Of course, these functions might not be desired for those who are not properly authorized to do so. Not locking down these functions behind proper authentication and authorization is the security risk presented here.

It is also important not to leak important information such as overly descriptive error messages or alternative API endpoints to perform these admin functions to anyone not properly authenticated. You will want to give out as little intel as possible for critical API functions.

Injection

OWASP has warned developers for years on the different types of Injection attacks - ways to feed malicious data to your infrastructure or databases to either disrupt, manipulate or destroy your data.

For many years, we saw traditional web application Injection attacks. Form fields would get used to load in specific Injection attacks like SQL Injection to manipulate SQL databases but the Injection attacks are slowly moving over to API Injection attacks as well.

APIs can be susceptible to Injection attacks as well, given that for many of the API endpoints, you have the ability to for instance, submit query string parameters, specific payload in the form of JSON or even, malicious payloads that could very well lead to issues when sent.

When developing your API, make sure you apply proper data validation. Make sure to handle special characters properly in the right place and disallow them in places where they are simply not needed - for instance in an alphanumeric object ID, you really shouldn’t be able to submit special characters.

If your API interfaces with a SQL or even NoSQL database underneath it, ensure that threat actors cannot send known SQL Injection attacks as part of the API endpoint, parameters or payload by properly sanitizing this data.

Web Application Firewalls can be very helpful when protecting against Injection attacks. Inspecting the request in headers, parameters, and payload to make sure they do not include elements for a harmful injection attack is something that can help. Akamai for instance has enhanced their Web Application Firewall by offering XML and JSON Inspection on payloads to protect against Injection attacks, not only on Web Applications but also API endpoints.

Mass Assignment

Your API objects come with many different fields of information or simply, properties. If you offer users the ability to update their data through an API endpoint with the PUT method, it is very important that you lock down the actual properties that can be altered.

While the web or mobile application only offers the actual form fields and transfer that data into JSON objects, you have to make sure to validate these fields. Someone could alter this request and add in fields that should not be altered. For instance, I should be able to change my telephone number at my bank, but the actual amount on my account should not be changeable.

Mass Assignment though categorizes this risk. It is important here to think about the way your properties get updated across your API endpoints. Especially sensitive or critical properties should be handled carefully with allow or deny-lists from being accessed by specific API endpoints.

Again, the combination of different API exploits here to manipulate data is critical here. Having the ability to gain access to specific functions through Broken Function Level Authorization and then Mass Assignment to update properties with these functions is a major risk to your API.

Combinations

API Attacks these days are of course way more complex than these 'straight-forward' examples and risks laid out so far. It is the combination of intel and manipulation attacks that will find gaps in your microservices architecture. Combining different attacks together can lead hackers targeting your APIs to their desired outcome - your data.

There is more that you can do though when securing your APIs and we will cover that in the final blog and video of these series, tackling API Management.

In Closing

With that, I will end this blog here. For more information, please take a look at the third video in the 'Fundamentals of API Security' series.

I also encourage you to try out crAPI for yourself and study the OWASP API Security Top 10.

Thanks again for all your support on this series! Consider leaving feedback and if you have any questions or want to see other API related topics covered in the future, let me know. You can find me on social media under Mike Elissen

Join me next time as we continue our journey to keep your API microservices secure!