Welcome to 2021 everyone! Or, as a Friday the 13th fan once said (and the way this year is going so far...) 2020 Part II: The Body Count Continues...
We apologize for the fault in the blogpost. Those responsible have been sacked.
Hey everyone and welcome to True's next 2021 2020 Part 2 blog post –
Let's talk about API security, shall we?
Generally, TRUE's methodology for web application tests follows a process of mapping out the application by browsing through it using Burp Proxy, clicking all the links, and putting data into input fields just to see what happens. Quite often, we'll find some stray cross-site scripting (XSS) vulnerability, or SQL injection, or some other kind of code injection. Oftentimes we don't find anything. It happens.
Something we've noticed quite a lot lately is how much thought goes into securing web applications, the front ends, the back ends, database calls, etc., …but not a lot of thought goes into securing API calls. After talking with a few developers and admins over the past couple of years, it's become clear that most devs/admins don't realize that these APIs can be accessed just as easily as the webapp itself. Many admins were under the impression that the API is accessible only through the internal network, as a backend endpoint. It often surprises them that we're able to not only access the API, but also to ransack it and download TONS of data about clients/users/PII/PHI/etc. In the 2017 OWASP Top 10 Web Application Security Risks, this particular vulnerability is #5 - Broken Access Control.
(Mynd you, møøse bites Kan be pretty nasti...)
We apologize again for the fault in the blogpost. Those responsible for sacking the people who have just been sacked, have been sacked.
Want some examples? I thought you'd never ask!
What we see the most often is the ability of an authenticated low-privilege user to:
- Access or change another user’s password
- Create new Admin accounts, from scratch
- Enumerate other accounts
- View another client’s data, such as PII/PHI/Møøse Identification Number
- Manipulate or add to another client’s data, including adding code for client-side code execution
- Delete another user's data, including PHI/PII/Templates/Orders
- Escalating existing privileges to higher privileged level Møøse account and/or Admin level
We've seen some of these attacks work with not only low-privileged users, but with completely unauthenticated attackers – the attacker doesn't even need to know someone's credentials to gather the data. These kinds of vulnerabilities are critical and need the utmost attention as soon as possible.
So, what can be done to mitigate these kinds of vulnerabilities?
Well, it really comes down to one of the most basic core tenets of Information Security – the AAA model – Authentication, Authorization, and Accounting.
Step 1 – Authentication
The first thing we recommend most devs/admins do is check and make sure that all API calls are authenticated. Even if you think that your API is inaccessible to the public, authenticate all API calls. This is the first step to making sure that unauthorized attackers, particularly the møøse without access to credentials, can't access the data that they want.
So, what do we need to do? AUTHENTICATE - ALL- API - CALLS.
Ok, is that checked? Let's move on to...
Step 2 – Authorization
Now make sure that access controls are in place to ensure that only authorized users have the ability to access their own data. I've seen APIs where the Admin pages are off limits, because some thought did go into unauthorized personnel’s being able to access the Admin section of a webapp, but the developers didn't realize that the client API calls were a free-for-all, and changing just one parameter of a call could give up the data of another client.
Simply implementing access controls on the API calls, then having that access control engaged for the dataset helped the organization get their security under control. The fix was relatively simple in theory, but it took a while to implement, because of the sheer amount of data that the organization had. There are several different types of Access Controls that can be used for granting or denying access to the data, but the one that you use will be largely dependent on your organization's needs– and going through them is beyond the scope of this blog post.
That brings us to the last part -
Step 3 – Accounting
Ok, so you've got the authentication set up and are finished with the authorization… but how do you KNOW that a user is only accessing the data that they're supposed to? This is where Accounting comes in.
Think of accounting like your network monitoring solution. It keeps track of who is accessing what at all times, so you have a record of what's going on in your API calls and your database. These are typically going to be some kind of logs that hold information about what account is accessing what data, and what account may be TRYING to access some data that it should not have access to. Admins can use these logs to determine if something was missed somewhere in the setup of the authorization, or if an attacker is trying to access someone else's data that they're not supposed to.
I've seen a lot of APIs where devs/admins might have the authentication setup, and sometimes even authorization, but there's no accounting setup, so they still don't know what's ACTUALLY happening in their API calls. We highly recommend this last step of the process, because, well, it's monitoring. Everyone needs monitoring! It's how we troubleshoot issues, find attackers and keep the møøse out of our networks.
If you would like to talk with someone about either a penetration test or security support, please feel free to request a consultation with one of our TRUE experts.
The directors of the firm hired to continue the blogpost after the other people had been sacked, wish it to be known that they have just been sacked.
The blogpost has been completed in an entirely different style at great expense and at the last minute.
Written By
40 SPECIALLY TRAINED
ECUADORIAN MOUNTAIN LLAMAS
6 VENEZUELAN RED LLAMAS
142 MEXICAN WHOOPING LLAMAS
14 NORTH CHILEAN GUANACOS
(CLOSELY RELATED TO THE LLAMA)
REG LLAMA OF BRIXTON
76000 BATTERY LLAMAS
FROM "LLAMA-FRESH" FARMS LTD. NEAR PARAGUAY
and
AARON MOSS
(with all apologies to Monty Python)