This blog was written by an independent guest blogger.
The number of machine identities for which organizations are responsible has “exploded” in recent years, according to Security Boulevard. These machine identities include devices and workloads. But they also include application programming interfaces (APIs). Organizations use APIs to connect the data and functionality of their applications to those managed by third-party developers, business partners, and other entities, per IBM. These connections enable different applications to communicate with each other and to use the services of one another to help deliver and streamline functionality for users.
APIs and machine identities under attack
Digital attackers are increasingly taking an interest in APIs and machine identities. In 2020, for instance, Venafi found that attacks involving machine identities increased 400% between 2018 and 2019. Kount also released a report in 2020 in which 81% of enterprises revealed that they now deal with attacks driven by malicious bots. A quarter of respondents said they had experienced an attack that ended up costing them at least half a million dollars.
These findings raise the question: Why are these attacks happening?
The answer is that many developers are prioritizing speed of innovation over security. Yes, many of today’s mobile, web, and Software-as-a-Service (SaaS) applications would be impossible without APIs. But it’s also true that APIs can expose sensitive data including personally identifiable information when not properly secured, resulting in security incidents that can undermine organizations’ business interests. The Open Web Application Security Project (OWASP) was therefore correct in saying, “Without secure APIs, rapid innovation would be impossible.”
The challenge here is the multifaceted nature of API security. OWASP, which pioneered the OWASP Top 10 list of application attacks, recognized the need for a new list focused on API attacks and in 2019, it created the OWASP API Top 10. Only one threat for the first list made it onto the second list, showing just how different API attacks are. The following two threats are great examples of how bad actors target APIs vs. applications:
- Broken Object Level Authorization: As explained by Heimdal Security, Object Level Authorization is an access control mechanism that confirms a user can’t access objects that they shouldn’t have access to. Broken Object Level Authorization (BOLB) occurs when an application does not leverage this mechanism properly. In doing so, a BOLB vulnerability can enable an attacker to access sensitive information handled by the app.
- Broken User Authentication: This type of vulnerability occurs in instances where authentication mechanisms do not function as intended because they weren’t implemented properly, noted OWASP. A malicious actor can subsequently weaponize Broken User Authentication to compromise a user’s authentication token and/or impersonate a user for a period.
An overview of authentication and authorization
API security might be multifaceted, but some things do repeat themselves. In fact, many of OWASP’s list of top 10 API vulnerabilities revolve around insufficient authentication and authorization controls. To understand the implications, it’s important to first define what these security controls entail.
In another article, Security Boulevard defined authentication as “the process of identifying users and validating who they claim to me.” Most authentication schemes use a set of credentials made up of a username and password to authenticate someone’s identity. However, some schemes layer on additional factors of authentication such as a fingerprint, a One-Time Temporary Password (OTTP) generated by an authentication app, or a physical security key to secure access to an account in the event of a password compromise.
Authorization comes after authentication. This stage involves granting full or partial access rights for databases, accounts, or other resources to an authenticated user. In this sense, a user can be authenticated, but they still might not have the authorization to access certain systems within the organization. Simultaneously, attackers can capitalize on a broken authentication system to abuse a victim’s level of authorization for accessing sensitive systems and data.
Authentication and authorization are necessary for defending against many security threats today. That’s especially the case for insider threats. The longer that people are with an organization, the more they tend to collect permissions over time that may exceed what’s required for their job. Some of those permissions might be relevant to current work duties, for example, while others might trace back to projects long-since completed. Others might provide rights the user never needed.
These types of permissions emphasize the importance of the principle of least privilege and ongoing permissions reviews. But it also underscores what can happen when robust authentication and authorization aren’t in place. For example, an external attacker can compromise an account protected with only a single layer of authentication (a single credential set) and abuse a lack of authorization checks to expose information handled by the API. Without proper validation, a malicious insider could do the same thing. There’s the belief that authenticated users won’t go look for things that they shouldn’t. But Account Takeover (ATO) attacks do happen, and certain authorizations enable these types of attacks to occur.
How to provide strong API authentication and authorization
Acknowledging the threats above, Salt Security provides the following recommendation: “Externalize your access controls and identity stores wherever possible, which includes mediation mechanisms like API gateways….” InfoWorld clarified that API gateways function as single points of entry into a system, allowing security teams to concentrate their system hardening efforts there instead of distributing their efforts across multiple APIs. Gateways help by facilitating authentication and authorization at the business level by concentrating security logic in a single location. Organizations can also use Identity and Access Management (IAM) solutions as well as key management technologies to further lock down their APIs.
It’s important to highlight, however, that authentication and authorization are not sufficient for API security. Organizations also need tooling that will identify when bad actors are able to manipulate API calls and adjust authentication or authorization parameters that, individually, look proper but have actually been changed to enable inappropriate access to accounts. So get your authentication and authorization done right, but don’t rest of those laurels.
Article Link: Why authorization and authentication are important to API security – and why they’re not enough | AT&T Cybersecurity