Modern Application Security - Good and Bad News

Introduction‍

This is the first article in a 2-part blog series outlining how application security has changed (or needs to change). Before I get into the article, let me give you a little background on myself. I am currently the Head of Security Research at Traceable but my personal journey with application security started long ago. My journey has had three stations so far: the first one was in middle school as a script kiddie, where I found myself studying vBulletin exploits and building phishing pages; the second station was serving in the Israeli Defense Forces, where I performed penetration tests for the most critical systems; and the last one was in a form of a one-way ticket to Silicon Valley, on my way to work with top startups and tier one companies.

During these 13 years, I’ve been watching the application development field change from one end to the other with new technologies coming and going. Accordingly, in order to stay relevant in the industry, I had to adapt my perspective on application security and my methodologies in understanding the new threats.

While creating the  “OWASP API Security Project” as project co-leader, I tried to define exactly what “Modern Application Security” means, and the role API security plays in it. This blog series will humbly walk you through those research questions, thoughts, and conclusions.

In this first article, I focus on reviewing the most significant changes in application development over the last several years. Understanding how applications have evolved is instrumental in knowing how application security must also evolve.‍

Traditional vs. Modern Applications‍

There have been many changes in application development, but let’s focus on summarizing the more relevant ones that impact security:‍

The Backend

This is an example of a backend in traditional applications:

Applications used to live in on-premises and self-hosting environments. They were self-contained and independent. The IT engineers would conduct this orchestra, and the pace used to be, well, pretty slow.

Now, here's what a backend might look like in a modern application:

Today, applications live in the cloud, they are loosely coupled and spread out. Things tend to be much more flexible and scalable thanks to the DevOps Wizard and the Three Scalability Musketeers — SaaS, Agile & Kubernetes.

Some major changes worth mentioning:

• Cloud Hosting: Modern applications are hosted in the cloud. Cloud providers offer different levels of abstractions (IaaS, PaaS, SaaS) that take care of classic IT concerns, and allow companies to focus on creating products instead of struggling to manage machines.
• Microservices & K8S: business logic is spread out across different microservices, instead of living on one cumbersome monolith. It brings an extra layer of complexity, handled by K8S and other deployment orchestration frameworks.
• High pace: The production environment changes all the time. Concepts like Agile, CI/CD, supports the pace.
• DevOps: The DevOps culture bridges the gap between developers and operations by training each team in the other’s skills and supports the dynamic nature of modern application.
• Cloud Services / 3rd Party Services (SaaS):
  These services save a lot of time for engineers by providing them a set of ready to use tools.
• More Active Versions live at the same time.‍

The Client

This is how regular data flowed in traditional applications:

The client used to be pretty simple, and it had a few main responsibilities: receiving and handling prepared visual HTML pages sent from the web server and showing them to the user; Updating the web server about the user’s state.

Now, this is the regular flow of data in modern applications:

Today, things look very different: the rendering component moved from the server to the client; The client app fetches very specific pieces of data and renders visual components locally on the client device; The client app receives raw data in the format of JSON instead of HTML pages.

On top of that, a few other things have changed dramatically.

• Client Muscle: clients are more powerful, with richer frameworks. Client applications take responsibilities from the backend (like the rendering component).
• More Parameters: the clients maintain the user’s state, and they are much more specific about what they need from the server - which results in more parameters being sent.
• More Requests: instead of one HTTP call to fetch “homepage.aspx”, a modern client would send several API calls to fetch data to populate the homepage view.
• Multiplicity of Clients: today we can find IoT, Android, iOS, and developers that use the APIs in addition to web browsers.‍

The Rise of REST and GraphQL APIs‍

API standards such as REST and GraphQL were born out of necessity. They fulfill different needs of modern applications and play a fundamental role in those applications.

Based on the concepts we discussed, let’s try to understand how REST and GraphQL support new concepts in modern applications.

• JSON is the new Esperanto - To make applications more scalable, there is one unified format to represent data. The “receipt” object read by your Uber app, might be the same object processed by the backend, and the same object stored by the database, without too much parsing or conversions.
• Generic Entry Points - In the past, we could have multiple entry points to access the same piece of data. Today, the new standards encourage developers to write more uniform and generic entry points to save time.

• Predictable Entry Points - in the past, there was no one convention on how to expose different functions to clients. Today, the new standards define how to perform different actions on resources (for example, using different HTTP methods with the same URL)
• More Entry Points:

• Fewer Abstraction Layers - This is one of the most important points about APIs.
  Unlike monolithic apps that hide a lot of secrets and data, APIs are like an open book. ‍

Summary‍

Many exciting changes have happened in the last few years within the field of application development. It’s an exciting time to be a developer and create sophisticated distributed applications, but even more so, to be a security engineer and protect/break them :)

Next, read Part II where we discuss how the mentioned new changes impact application security, and why the new characteristics of modern applications make them such attractive targets for attackers.