8: Denial of Service and Financial Resource Exhaustion
While serverless architectures bring promises of automated scalability and high availability, they also come with limitations and issues which require attention. If an application was not designed to handle concurrent executions properly, an attacker may eventually bring the application to hit the concurrency limits and deny service from other users of the system or the cloud account.
9: Serverless Business Logic Manipulation
Business logic manipulation may help attackers subvert application logic. Using this technique, attackers may bypass access controls, elevate user privileges or mount a DoS attack. Business logic manipulation is a common problem in many types of software and serverless architectures. However, serverless applications are unique, as they often follow the microservices design paradigm and contain many discrete functions. These functions are chained together in a specific order, which implements the overall application logic.
In a system where multiple functions exist — and each function may invoke another function — the order of invocation may be critical for achieving the desired logic. Moreover, the design might assume that certain functions are only invoked under specific scenarios and only by authorized invokers.
Business logic manipulation in serverless applications may also occur within a single function, where an attacker might exploit bad design or inject malicious code during the execution of a function, for example, by exploiting functions which load data from untrusted sources or compromised cloud resources.
Another relevant scenario, in which the multiple functions invocation process may become a target for attackers, are serverless-based state machines. Examples include those offered by AWS Step Functions, Azure Logic Apps, Azure Durable Functions or IBM Cloud Functions sequences.
10: Improper Exception Handling and Verbose Error Messages
Line-by-line debugging options for serverless-based applications are limited (and more complex) when compared to debugging capabilities for standard applications. This reality is especially true when serverless functions utilizes cloud-based services not available when debugging the code locally. As a result, developers will frequently adopt the use of verbose error messages, enable debugging environment variables and eventually forget to clean code when moving it to the production environment.
11: Legacy/Unused Functions and Cloud Resources
Similar to other types of modern software applications, over time some serverless functions and related cloud resources might become obsolete and should be decommissioned. Pruning obsolete application components should be done periodically both for reducing unnecessary costs, and for reducing avoidable attack surfaces. Obsolete serverless application components may include:
12: Cross-Execution Data Persistency
Serverless platforms offer application developers local disk storage, environment variables and RAM memory in order to perform compute tasks in a similar fashion to any modern software stacks.
In order to make serverless platforms efficient in handling new invocations and avoid cold-starts, cloud providers might reuse the execution environment (e.g. container) for subsequent function invocations.
In a scenario where the serverless execution environment is reused for subsequent invocations, which may belong to different end users or session contexts, it is possible that sensitive data will be left behind and might be exposed.
Developers should always treat the execution environment of serverless functions as ephemeral and stateless and should not assume anything about the availability, integrity and most importantly, the disposal of locally stored data between invocations.
Download the CSA “12 Most Critical Risks for Serverless Applications 2019” Guide.Brought to you by puresec.io