How hackers gain intel on your API microservices

How hackers gain intel on your API microservices

Continuing our journey with 'Fundamentals of API Security', a four part video series.

Thanks to the tremendous interest and support so far on my new video series 'Fundamentals of API Security'. I hope that these videos provide you with new insight and help you protect your microservices architecture better.

Today, we continue our journey focusing on how hackers can gain intel on your API microservices and start to find gaps...

Anyone trying to attempt to gain unauthorized access to your API microservices will typically know little of how your microservices are designed and operate. Hackers will attempt to gain as much intel as possible on your APIs before they can launch manipulation attacks.

Your APIs tend to be available on the public Internet and while they might be designed to be hidden inside of web or mobile applications, with some simple tools, it is easy to inspect these API requests and responses being send back and forth.

And while your application might filter out and only show the data necessary, there might be more information send that is risky to share with hackers.

What does OWASP recommend for API Intel?

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

  1. API1:2019 - Broken Object Level Authorization
  2. API2:2019 - Broken User Authentication
  3. API3:2019 - Excessive Data Exposure

Trust No One

When designing your API microservices, there is one tenet that comes to mind and that is 'Trust No One'. Don't trust the user, don't trust the client and of course, always validate.

Whether your API endpoint is available for public consumption or only designed for use 'inside' your company and perhaps a few select 'trusted partners'. You have to make sure that your API is properly protected on several levels.

Looking at Broken Object Level Authorization, or BOLA, you have to ensure that the objects in your API are only allowed to be accessed by the correct user. A common way to apply a BOLA-related attack is to scan for other object IDs inside of an API.

Take for instance this simple API request to retrieve information from a user:

GET https://myapi/user/123

This request could be replayed by an attacker by changing the userId.

GET https://myapi/user/456

If your API contains privacy or sensitive data, you are opening yourself up to some serious implications for your business, especially with current regulations on data and privacy regulations.

Similarly with Broken User Authentication, you have to make sure to properly authenticate the user or system using your API to ensure they have the right access to the API endpoint, the API method and even the underlying data.

API Authentication is quite frankly the most complicated and most expansive topic that I can easily cover in a complete stand-alone blog series. The different API Authentication methods commonly used such as API Keys, JSON Web Tokens (JWT) or OAuth2 are all complex standards, rightfully so.

While I will revisit this topic at a later stage, for now, I can recommend you to think about who needs to access what when, while you are creating your design.

Simply checking authentication once and setting a JSON Web Token with an expiry date of 1 year into the future is not a good idea. Neither is sending usernames and passwords in plain text of course, but passwordless is the future anyway.

In the second video, I showcase a demo of crAPI and how the forgot password feature operates on an easy to bypass 4 digit one-time password. Simply trying all 10,000 combinations can easily lock out a user and all you need to know is their email address. Dangerous!

Finally, of course, is Excessive Data Exposure. I mentioned 'don't trust the device' and speaking of email addresses, this is another easy demonstration in crAPI. Several API endpoints are returning too much information. The data does not get displayed inside the web application, the HTML simply doesn't show it but the data is definitely there.

With a simple Google Chrome DevTools, you can scan the requests and responses going back and forth and inside one of the requests, you can find the email address of the user leaving a comment.

Combining both this 'Excessive Data Exposure' intel attack with the aforementioned 'Broken User Authentication' One-Time Password attack, you can find legitimate user and lock them out of their accounts and use it. For a simple car mechanic website, the damage is relatively low but locking someone out of their streaming service or worse their online bank account and you can see how the 'value of being a hacker' quickly adds up.

In Closing

With that, I will end this blog here. For more information, please take a look at the second 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!