OWASP’s API Security 10 to 1

OWASP's API Security 10 to 1

I’m sure we’re all counting down the days until we can put our feet up and surround ourselves with loved ones but before that I’ve been busy reviewing each risk that appear on the OWASP API Security Top 10. This blog won’t feature any maids or lords or drummers but we will be counting down from ten to one and answer a couple of questions like; what are the risks to APIs and what has changed from the OWASP Top 10?

You will notice that some risks align with the OWASP Top 10, some don’t feature and others like authZ have been broken up once again (the OWASP Top 10 2013 featured A4: Insecure Direct Object Reference and A7: Missing Functional Level Access Control which were combined in the OWASP Top 10 2017 to A5: Broken Access control). While delving into the list we’ve also included mitigations and features that can supplement mitigations utilizing Axway’s API suite as well as Axway’s partner Ping Identity to addressing each of the risks.

API 10: Insufficient Logging & Monitoring

Coming in bottom of the API security list, almost like the pair of novelty socks you got, is insufficient logging and monitoring but it’s not to be forgotten because without it you’re flying blind. It perfectly aligns with OWASP Top 10 2017 who also felt this deserved the number ten spot. By overlooking this key component to your architecture that could consist of microservices, cloud services and legacy components you’ve just handed the attacker the greatest gift because they can leave no trail behind.

The problem

Attackers generally create unusual traffic when they are trying to break into a system. Reaching into their bag of tricks they’ll try the laziest and most often most effective method of brute forcing your authentication or running scripts against your inputs. Without a way of picking this up you’ll have no idea what’s happened until it’s too late, in fact you won’t even have enough information to run a post-mortem potentially leaving you open to attack after attack.

What can be done

The solution of monitoring is key across almost all of the top 10 where it will always aid in your investigation into an attack, but it may also prevent the attack from even taking place. Axway’s API Solutions along with Axway’s partner Ping Identity are key to tackling this issue. You can perform the follow to aid in addressing this risk:

  • Logging and tracing API requests and responses.
  • Logs can be written in a format that can be consumed by a log management solution such as Splunk, Elk Stack etc.
  • Enough detail can be generated and then gathered from the logs to identify a malicious actor.
  • Real time intelligence powered by AI and machine learning from Ping Identity with Ping Intelligence to detect and block threats.

API 9: Improper Assets Management

Working our way up the list to number 9 which I can’t see ever featuring on the OWASP Top 10 because in the application world it’s quite unique to APIs. This is kind of a knock-on effect from how teams are delivering software. When you have multiple deployments and you add a lack of documentation you end up with forgotten APIs in the form of both old and shadow APIs.

The problem

You’ve been building APIs for some time now and they meet all your security processes and pass all your testing. However, you’ve overlooked or have untracked and/or undocumented APIs which that have slipped through your net. Attackers in most cases take advantage of the weakest link in your system and these exposed old APIs are ripe for the picking. The first thing an attacker is going to do when they see your API version is /v3, is to try /v1 to see if the security mechanisms in place for /v3 also apply for /v1. Often times they don’t, and the attacker has got their foot into your enterprise.

What can be done

The first thing that you should do is perform an inventory of all you API hosts and document everything from production, staging, test and development and who has access. Utilizing Axway API solutions you can:

  • Track APIs within the API catalog which will contain the APIs that are registered in the API Manager. Here you can view the documentation and test the APIs.
  • API endpoints can be deprecated using an API manager which will render them inaccessible.
  • Utilizing the Traffic monitor you can see what APIs are being used and could lead to the discovery of undocumented APIs.

API 8: Injection

The most important issue throughout the years has lost its crown. This one needs very little introduction as pretty much everyone has a good understanding of injection and the main culprit in the injection category, SQLi. Why is it lingering down the bottom with the others? Its simple, injection is just not common in APIs. Possibly due to the use of object-relational mapping (ORM) which suffers less from injection and in general there is less and less application to SQL interactions with APIs.

The problem

Inputs to your API are targeted by the attacker e.g. parameters, HTTP headers (tokens, cookies etc.) or in fact any value within your API call. The attacker can try numerous types of injection SQLi, XML, LDAP, NoSQL, OS Commands, ORM etc. If successful your database can be leaked, your authentication mechanism circumnavigated, DoS, host take-over, etc.

What can be done

It’s always recommended to address these issues at their source in code. But as an extra layer of defense or a supplementary measure Axway’s API solution has

  • A WAF built in that can be configured in detection or prevention mode.
  • A filter within the Gateway which can perform regex expressions against incoming requests against API endpoints.
  • An inbuilt whitelist and blacklist to check requests passing through the system.

API 7: Security Misconfiguration

Just about aligned with the OWASP Top 10 we’ve got security misconfiguration but it’s a slightly different beast as the sole focus is misconfigured APIs. The adoption of SaaS technologies pushes the responsibility for a lot of configuration onto the SaaS providers.

The problem

Attackers will try to find out as much about your application as possible and one avenue is to force error messages that include stack traces and generally expose as much information through these means. Using this and other techniques they often lookup the exposed information against the CVE database. These are publicly available and sometimes even come with a proof-of-concept (PoC) exploit. There is no doubt that your unpatched flaws will be exploited. They’ll also look for:

  • Features that are poorly configured like unnecessary HTTP verbs.
  • A possibility of sending requests over an untrusted channel like HTTP or depreciated secure channel like TLS with CBC-mode cipher suites.
  • Lack of security headers configured in HTTP responses.

What can be done

There is a myriad of things you should be doing here, and it is recommended to check OWASP’s recommendations. To aid in mitigation or to add an extra layer of defence you can utilize Axway’s API Gateway and API Manager to:

  • Overwrite error messages generated by the back-end using either redacting or error handlers.
  • Check for and change HTTP Headers and CORS settings.

API 6: Mass Assignment

Although this is not unique to APIs it does not feature on the OWASP Top 10 where it stems from where modern frameworks which encourage you to use functions that automatically bind input from the client into code variables and internal objects.

The problem

A user is pulling information about themselves from your application where their client calls the API api/v3/users/me. The payload that is sent from the client to the server is {“username”:”axway”,”join_date”:”2019-02-12″}. The attacker has done some recon and the attacker learns that this same call to pull information about a user has an extra object related to it. The same API is called by the attacker api/v3/users/me but they now include an extra parameter in their payload {“username”:”axway”,”join_date”:”2019-02-12″, “is_admin”:”true”}. This is a valid request but this is an internal object that clients shouldn’t have access to. The attacker has circumnavigated the authorization mechanisms because the framework automatically binds input from the client. The attacker has successfully granted themselves admin access on your system by exploiting a mass assignment vulnerability. These types of issues are very dependent on the business logic of an application but using this technique an attacker could manipulate requests to perform many actions which could include adding money to their balance or injecting attacks against the underlying system.

What can be done

Always address this type of issue at the root cause and that’s in code. You should analyze any functions that bind a client’s input to code and adopt a whitelist approach against the incoming request. For more information look to the recommendations from OWASP. Using API Gateway, you can add to the protection by using:

  • API Gateway’s redaction on incoming requests can remove any client input that tries to interact with functions that bind to a client’s input.
  • Threat detection build into the products can alert and prevent malicious requests.

API 5: BFLA – Broken Function Level Authorization

Like that “will they, won’t they” couple who break up and then get back together there’s these two risks to authorization that seems to do the same within OWASP lists. The current OWASP Top 10 features both functional level and object level authorization as one under the heading “Broken Access Control”. The previous iteration of the OWASP Top 10 in 2013 had them broken and now the current OWASP API Security Top 10 once again has them broken up. We’ll get to the other issues of object level authorization later but with broken functional level authorization it’s basically down to users having access to APIs they simply shouldn’t be authorized to access. Restricted functions are often “hidden” by the UI where there is a reliance on the client to present only the functions available to the current logged in role. This could mean that the APIs are:

  • Open to anonymous users
  • Users with the least privilege
  • Non-privileged users.

This is much more common with APIs as it is often easy to predict an API endpoint once you know one or more API endpoints in use in the application and also the fact that there is a reliance on the UI to secure restricted functions.

The problem

An attacker will try map out your APIs in various ways with the goal of sending a successful request to one that they should not have access to. The complexity of modern applications, with their many roles and groups, means the application may not prevent the attacker sending a request to a seemingly restricted endpoint and having the endpoint process their request. There’s potential an attacker could carry out administrative functionality such as deleting users, listing all the users, shutting down services etc. An example of how predicable these APIs are can be seen below. The example shows both the publicly known URL and the restricted admin URL used for viewing users and deleting users;

HTTP VerbURIBody
Traditional ApplicationGET/app/users_view.jsp?user_id=40404
POST/app/admin_pane/users_mgmt.jspaction=delete&user_id=40404
API ApplicationGET/api/users/40404
DELETE/api/users/40404

What can be done

Firstly, keep in mind there is no way of “hiding” an endpoint, just because it is not publicly documented doesn’t make it hidden. As recommended in the OWASP API Security Top 10. Axway’s API Manager can:

  • Differentiate between many roles and groups such as policy developer, gateway admin, API developer, end user etc.
  • Endpoint access can be determined by a combination of organization and application.

Also, Axway’s API Solution allows you to leverage OAuth as part of your authorization mechanism;

  • API Manager allows the association of ‘scopes’ to an API or API method.
  • When the scope is used to generate an Oauth token or with an API key, that token can only be used with methods that have been associated with the scope.

API 4: Lack of Resources and Rate Limiting

This issue only appears on the API Security Top 10 but again does not mean traditional applications don’t suffer from this issue where it’s pretty much self-explanatory. Simply put there is a lack of resources devoted to the API and/or there is no rate limiting set to APIs.

The problem

An attacker launches an attack through your APIs in an attempt to force your service to fall over by over consuming network, CPU, memory and/or storage resources. Bear in mind this could be done inadvertently by a valid user if any of the following limits are missing or set inappropriately:

  • Execution timeouts
  • Max allocatable memory
  • Number of file descriptors
  • Number of processes
  • Request payload size (e.g. uploads)
  • Number of requests per client/resource
  • Number of records per page to return in a single request response

What can be done

On top of limiting how much server resources your application can consume Axway’s API Manager can perform:

  • Quota operation-based user identity,
  • Rate Limiting (Floating Time Window, Smooth Rate Limiting) protection
  • Message size checks and anti-virus/ICAP checks on the back-end

API 3: Excessive Data Exposure

Another new entry not seen over on the OWASP Top 10 this risk is due to processing being done on the client side. This occurs when there is one endpoint that is consumed by multiple clients where there is a reliance on the front-end engineers to filter out the data being returned by the API. It’s poor design that could be caught at the design phase and during a threat model where the issue is an API exposing private data. This is comparable to the bad practice of SELECT * where there is a certain amount of laziness and oversight associated with it.

The problem

Attackers will never use your application the way you designed it. When you rely on the client side to restrict information being displayed to a user an attacker is going to take advantage of that. For example, your mobile app returns your location and the location of the users who have chosen to go public. But an attacker doesn’t use the mobile UI which is filtering those people who don’t wish to have their locations shared publicly. The attacker calls the API endpoint directly where all data is returned in a raw unfiltered fashion allowing them to see users who have chosen to remain “private”.

What can be done

The first thing to do is to review how you’re returning data, never rely on the client to restrict access to data where it should be done in code. As a transition to reduce the risk while you’re addressing the issue in code you can utilize Axway’s API solutions:

  • Redaction filter can be used by importing an API spec into API Manager.

API 2: Broken Authentication

We’re aligned once more with the OWASP Top 10 but unlike traditional applications, API authentication can be more complex than your traditional web app authentication. Like traditional applications it’s usually exposed to everyone and often publicly. Included in this is both forgot password and reset password functionality which can be overlooked. These endpoints responsible for authentication should be treated differently from other endpoints with extra care taken. Authentication mechanisms should differ according to the type of application e.g. a web application vs IoT client.

The problem

Attackers will try gain access to your application by tinkering with its authentication mechanisms by either circumnavigating the authentication mechanism itself or by going after the users of your system. By going after the users of a system, an attacker affects the integrity of the system by becoming those users. The most basic attack used to exploit broken authentication is brute forcing credentials and MFA codes. For example, when trying to reset a password a user will receive a 5-digit code to their mobile device. If there is no lockout or throttling mechanism for this function the attacker could successfully brute force the MFA code. Another example would be the login username and password where there is no restriction on the combinations of usernames and passwords, the attacker can easily run scripts that will not be stopped or detected by your application.

What can be done

The first thing to do is to understand your current authentication mechanisms and the flows to the authentication API bearing in mind OAuth and API keys are not authentication. With anything like this don’t roll your own and always rely on proven technologies. Please see various guides from OWASP, mainly the authentication guide. With Axway’s API solution you can:

  • Integrate with current authentication technologies e.g. LDAP, CA SiteMinder, IBM Tivoli Access Manager, RSA Access Manager, Oracle Access Manager, etc.
  • Use Rate Limiting (Floating Time Window, Smooth Rate Limiting) protection
  • Utilize threat detection build into the products can alert and prevent malicious requests.
  • Utilize a web application firewall (WAF)

API 1: Broken Object Level Authorization (BOLA)

At the top of the list is the one you should focus most of your attention on and is actually part of that couple who breaks up and get back together. This risk has that “complicated” relationship with API 5: Broken Functional Level Authorization as they can be separated or together depending on what list you’re referencing. But it is separate with the intention being to put more focus on broken object level authorization. BOLA is essentially based around IDs and the erroneous ways they are tied to authorization. Secure systems should have authorization checks that rely on user policies and hierarchies where it checks if the user logged in has access to a requested object. Unfortunately, in API based applications the server doesn’t always track the client’s state fully so there is this reliance on object IDs.

The problem

Attackers once they see that your application is using IDs will try to enumerate them. For example, you can retrieve you user data by calling api/v2/user/40404. The attacker decides to cycle through ids such as api/v2/user/001 and api/v2/user/002 and so on. To the attackers delight the application will return data about those users. Digging deeper the attacker could gain access to admin functionality, etc.

What can be done

There is a tendency to use GUID instead of guessable ids and although it offers obscurity and should be used, it is not a complete solution. Good authorization is business dependent and every application should be analyzed before implementing authorization. The right solution should be selected based on the technologies and architecture where every controller adopts the authorization put in place. There is a tendency to also put server-side access controls in place at the functional level, which only addresses the risk outlined in API 5: Broken Functional Level Authorization and stop there. This means there are no checks at the data or object layer which should protect against tampering with IDs in requests. So, enforcing the server side authorization checks against the data layer access control should be done by verifying that the current user is allowed access to the requested data.

Within API Gateway you can take a two-step approach to tackling both authorization issues of API 1 BOLA and API 5 BFLA (which was outlined in the previous section). There are many ways of integrating authorization mechanisms in API Gateway such as:

  • RSA Access Manager authorization
  • Attribute authorization
  • Axway PassPort authorization
  • CA SOA Security Manager authorization
  • Certificate attribute authorization
  • Entrust GetAccess authorization
  • Insert SAML authorization assertion
  • LDAP attribute authorization
  • SAML authorization
  • SAML PDP authorization
  • Tivoli authorization
  • XACML PEP authorization

For example, to specifically tackle the BOLA issue and administrator could:

  • Use an XACML PEP filter that enables them to configure the API Gateway to act as a Policy Enforcement Point (PEP). The API Gateway intercepts a user request to a resource, and enforces the decision from the Policy Decision Point (PDP)
  • Utilise JWT tokens which contains the user identity, attributes and roles which can be generated by API Gateway. The backend API will be responsible for performing the authorization check or delegate to a policy engine.

And that’s a wrap

The OWASP API Security Top 10 is an acknowledgement that the game changes when you go from developing a traditional application to an API based application.  It’s a new top 10 but there’s nothing new here in terms of threats. The list is a reshuffle and a re-prioritization from a much bigger pool of risks. It’s not a complete list by far but no top 10 is. It does however, rightly shift the focus when working with an API based application. If you were to work from the OWASP Top 10 then in my opinion areas that should be most critical would be overlooked and areas with a lower risk to almost zero risk would continue to be prioritized. Utilizing Axway’s API and Ping Identity solutions are one of the many things that you can do to reduce or mitigate the risk that feature in API Security Top 10. I’d always recommend that you follow best practice and OWASP is key in this. Simply look to the OWASP API Security Top 10 which is freely available where you’ll find that Axway’s API and Ping Identity can either mitigate or supplement a mitigation. It’s early days and the list is subject to change much like the security landscape tends to do. But if you like to keep up with the pace of security trends, which can be exhausting, then take note of this list.  It’s certainly something myself and Axway will be keeping a close eye on.

API Security – Checking it Twice

LEAVE A REPLY

Please enter your comment!
Please enter your name here