How to apply the OWASP Top 10 to serverless for increased security

[51CTO.com Quick Translation] Introduction: This article discusses how to apply OWASP Top 10 to serverless applications to reduce risks and increase security.

Serverless Model

Serverless computing, sometimes also called Function as a Service (FaaS), allows you to write self-contained functions that can run independently. The basic model is as follows:

That is, your function receives some input, performs calculations based on various inputs, storage, and acquired states, and then generates corresponding outputs. Of course, ordinary code can also work in this way, so what is the novelty of them?

The biggest innovation of the FaaS architecture is that it shifts some security responsibilities from your backend to your corresponding FaaS platform provider. The division of responsibilities between you is shown in the following figure:

The blue part is the "jurisdiction" of your application, while the yellow part belongs to the FaaS platform. This obviously has a great effect of reducing the burden, that is, you only need to write a function, and others will be responsible for the rest of the tedious work, including: finding various servers to run it; keeping these servers updated; performing cleanup when the server is attacked; automatically adding servers when the load is too high; determining how many functions can run on a server; redistributing the load as needed; and building a communication network between each function and all the services it supports.

Of course, this shift also brings more tediousness than security, that is, you must now focus on and protect your own program code. That is, because different developers can link a function with other functions, and those input data that are not strictly "sanitized" are likely to come from some attackers, so your various functions need to have a certain degree of self-protection. In fact, the input data provided to serverless applications will be more extensive. In addition to those well-defined function chains, you may also need to deal with REST over HTTP, different types of message queues, and extensible protocols introduced with each release.

New risks

The serverless computing model brings new risks, and traditional tools cannot guarantee the effective handling of these risks and their extensions. The OWASP top 10 commonly used by the industry is an excellent reference framework for protecting various applications. Of course, the attacks it targets are mainly based on applications running on the server. At the same time, your responsibility is not limited to your own code, but also includes the entire operating platform.

There are always similarities among various risks. Attackers either try to inject malicious data into your application code itself (such as SQL/database injection attacks) or directly inject data into a function. These functions are often given too many permissions or do not implement strong enough authentication. Like other types of code, the vulnerability of functions depends on those vulnerable components and improper design.

Certain functions triggered by various APIs, events in queues, and even events in storage systems will add new risks to the serverless architecture. As a result, the execution process of serverless applications is not clear enough, and the attack surface is more complex and diverse. At the same time, existing security tools have not yet adapted to the multiple on-demand input characteristics of functions. Various static, dynamic, and interactive application security tests (Static/Dynamic/Interactive Application Security Testing, SAST/DAST/IAST) are often used in testing some recognized and classic HTTP interfaces.

In fact, when various events can trigger each other and call various serverless functions of each other, using analytical tools to perform security analysis on each processing flow becomes a so-called NP-hard problem (Translator's note: non-deterministic polynomial number theory problems, such as the famous salesman's traveling problem).

As a perspective on security, let’s look at how to apply the OWASP top 10 to serverless computing.

1. Injection

Typically, attackers send untrusted data to applications, and then run them in a serverless architecture and call their functions too frequently to attack them. Conceptually, while API gateways can explicitly handle requests for a function, serverless platforms allow storage events (such as creating or modifying certain files or database fields) or message queues to directly start the requested functions. As can be seen, since the triggering of any event may contain the attacker's input code, injection attacks are a primary security issue in serverless computing.

2. Invalid identity authentication

According to the aforementioned vulnerabilities, authentication failures are more exposed in serverless functions. The authentication and authorization mechanisms of traditional applications usually apply to the entire application. For example, all functions in an application use a unified token. Even in a microservice environment, we can control access to the application and all its functions through a unified authentication architecture. When microservices are further decomposed into nanoservices with more functional modules, they have their own set of access control mechanisms. Therefore, when a user accesses an API endpoint and writes to storage through multiple services, each link in the access chain will need to have its own authentication mechanism.

3. Sensitive data leakage

Serverless applications may also expose sensitive data that is poorly protected. Therefore, one of the challenges we may face when protecting the security of serverless applications is that since we need to ensure that sensitive data is available to multiple functions, we must share different API keys, encryption keys, or trust credentials for external services across multiple functions, and their security is obviously difficult to guarantee. Although some cloud service providers now provide a "key vault" system and share keys across the entire application, this concept is still new and may not be understood by the majority of development teams.

4. External Entity (XXE)

Many serverless applications are built using simpler data formats than XML (such as JSON), so the risks in the OWASP top 10 are less significant for new applications.

5. Broken access control and 6. Security misconfiguration

Compared with other items in the OWASP top 10, these two threats are more prominent in serverless computing than in traditional applications. A typical serverless application is generally composed of a "string" of functions. An input data of a function often interacts with the storage of several external data to generate corresponding outputs. This is the model diagram we mentioned earlier. If we build a complete application on the FaaS platform, its flowchart should be as follows:

As you can see, since each function interacts with all services, it is very difficult to correctly configure functions for each aspect according to the principles of secure deployment! A few years ago, Rapid7 (Translator's Note: The world's leading security risk information solution provider) published an article claiming that they found nearly 2,000 open S3 buckets, and each of them may contain the output of a function chain (see: https://blog.rapid7.com/2013/03/27/open-s3-buckets/). This means that an attacker can sneak into a function and obtain its output data. Obviously, you need to limit the use of each function and configure it to the minimum permissions to complete various complex tasks.

6. Cross-site scripting

Since the targets of common attackers are still the end users and their browsers, even if they are built on a serverless platform, web-based applications may still be vulnerable to XSS attacks (see https://blog.tcell.io/2017/08/why-is-cross-site-scripting-so-hard). Therefore, when deploying and implementing applications on a serverless platform, we must not modify them without authorization or publish them without testing to avoid the risk of XSS attacks.

7. Unsafe Deserialization

Similar to XXE (external entity) attacks, deserialization attacks are carried out by embedding code in the payload. Since serverless functions can be called in any order and we cannot "sanitize" user input, we should adopt a more extensive data "sanitization" approach in serverless applications, after all, no function can trust any of its inputs.

8. Using components with known vulnerabilities

In this regard, serverless applications are the same as traditional applications: only by understanding which software packages your application depends on can you better manage various potential risks.

9. Inadequate logging and monitoring

The reason why this item is at the bottom of the OWASP top 10 is that we usually build a logging system to track and control all the code. With the popularity of serverless platforms and cloud platforms, you can completely rely on the various logging function services of the cloud platform itself. Of course, the industry has not yet formed best practices for the "landing" of logging on cloud platforms (let alone serverless). Therefore, you can either rely on the logging tools provided by the cloud platform or do it yourself to build and customize logging for your application. Of course, no matter which method is used, the general log analysis tools have not yet reached the level of cloud-aware logging.

Original title: Serverless and the OWASP Top 10, author: Matthew Gast

[Translated by 51CTO. Please indicate the original translator and source as 51CTO.com when reprinting on partner sites]