Modern Application Security - Good and Bad News part 2

This is the second article in a 2-part blog series. In the previous article, we talked about the major changes in application development in the last several years. In this article, we will discuss how these changes impact application security as we used to know it, and redefined the boundaries.

Extended Boundaries: Application Security is a Widespread Concern

With traditional applications, it was common to see companies invest most of their security efforts on the “edge” - the first layer exposed to the internet. Today, it’s not really possible to do this, because of two main reasons:

Microservice Level Protection: Microservice and API architectures expose more pieces of business logic to the client. It’s easy to use them for positive purposes as a developer or to take advantage of them as an attacker. Code components that used to be concealed in monolithic architectures, are today standing uncovered and easy to understand, just waiting to be explored by attackers. 

The Isolation Challenge: It is more challenging to isolate sensitive components, such as admin panels, internal tools, and even complete environments from external access. Engineers working remotely and non-production environments integrating with with CI/CD tools both lead to a situation where companies usually leave these sensitive environments exposed to everyone. 

‍Client Security is a Separated Field

Clients become more sophisticated with heavier functionality. Client security is no longer a small area of Application Security that contains a few issues like CSRF and XSS. It’s a whole new field, and each one of your clients requires different security approaches. Protecting a web application is a different story than protecting an iOS app or an IoT device. 

API Security is the Most Sensitive Area

Historically and statistically, breaches on the backend are more critical and expose the organization to a larger risk than client-side breaches. The Famous Facebook Breach, Uber Account Take Over, and Equifax breach all happened because of backend Application Security issues (more specifically, API security).

The backend handles information about all the users + internal data, while each client handles information about one to a few users. Since the backend is driven by APIs, API Security simply means modern backend application security.

API Security - The Good News

Over the last years, many traditional Application Security issues that you’re probably familiar with became less and less prevalent.

It didn’t happen in one day, but instead was a gradual and developing change driven by a set of security-oriented technologies and better developer training. Let’s take a look at a few examples:

‍

• SQL  Injections: usually solved by the use of ORM environments.
• Command injections & path manipulations: less common because developers tend to use external libraries and SaaS services (like S3), instead of working directly with the file system and OS commands.
• XML External Entities (XXE): A vulnerability in the parsing process of XMLs? Don’t worry about it, modern applications use JSON.
• Cross-Site Request Forgery (CSRF): This tricky vulnerability loses its place of honor because many modern clients use the “Authorization” header instead of cookies. No cookies? No CSRF.

On top of that, traffic today is more structured and predictable thanks to the REST standard. Modern security companies leverage this fact and build more sophisticated and self-adaptive products. 

API Security — The Bad News

There are a set of concepts in modern applications that make APIs a very attractive target for attackers.

1. ‍‍‍The attack surface is larger: As discussed in the previous article, APIs expose more endpoints and receive more parameters from clients. When it comes to Application Security, every parameter sent from the client, is a potential area to exploit. APIs handle more parameters than traditional apps.
   ‍
2. APIs are oversharing: An entry point can be consumed by multiple clients and features; Clients can easily filter out data based on many factors; These two facts lead API developers to return raw data and rely on frontend engineers to filter out the unnecessary parts. Sometimes it’s harmless, but sometimes they return sensitive data that should not be exposed. ‍
   ‍
3. APIs are predictable: Internal components of your app that once used to be concealed from most attackers are now exposed. Attackers today craft special payloads that manipulate the underlying business logic of your app. A few interesting examples:
   
   > It’s easier to exploit mass assignment in APIs: instead of guessing property names while exploiting mass assignment - you can find a GET endpoint that returns all of them.
   
   > It’s easier to find administrative endpoints in APIs: instead of guessing and run heavy dictionary attacks to find administrative endpoints, you can just leverage the predictable naming convection (for example, change the HTTP method from GET to DELETE).
   
   > It’s easier to find old and active versions in APIs: there are more active versions live at the same time, and the naming convention allows you to find them easily (`/api/v1` instead of `/api/v2`)‍
   ‍
4. Authorization is the biggest challenge: Authorization is the process of verifying that a user is doing something that she is supposed to do. Modern applications have different users, roles, policies, and expose more resources and functions. Implementing a decent authorization mechanism that prevents unauthorized access of any kind is a big challenge. BOLA and BFLA are pure authorization issues, but you can find a sense of authorization in almost each one of the OWASP Top 10 for APIs. Developers & DevOps engineers don’t always ask themselves a very important question — “who’s the consumer of the data/function? should she have access to it?”.

What’s Next

After we understand the unique aspects of API security, it’s time to jump into the OWASP Top 10 for APIs.

A lot of good people have invested resources and time in this project. We published the first RC last year, and made changes based on feedback we’ve been gathering from the community.  Now it’s ready to be used.