Describe serverless.
A cloud execution model is serverless computing. It enables users and developers to create and use applications and services without having to worry about servers. Applications are created more quickly, launched only when necessary, and infrastructure management is no longer necessary. Servers do still exist in serverless, but they are removed from the process of developing applications. While developers merely package the deployment of their code in containers, the cloud provider manages and maintains the infrastructure.
Why is it crucial?
The advantages of serverless technology for application developers are quite promising. The deployment of applications becomes simple, quicker, and less expensive due to automatic scalability, provisioning, and other characteristics performed by the cloud provider that remove infrastructure concerns from the developers’ focus. In this manner, serverless architecture seeks to alter the cloud computing industry’s business model.
Function Event-Data Injection
One of the most frequent risks to date is application injection flaws, which have been extensively discussed in numerous secure coding best practise guides (as well as in the “Open Web Application Security Project (OWASP) Top 10” project). Injection flaws generally occur when untrusted input is passed to an interpreter without first being executed or evaluated.
However, function event-data injections are not confined to direct user input in the context of serverless architectures (such as input from a web API call). The majority of serverless architectures offer a wide range of event sources that can start a serverless function. Examples comprise:
• Cloud storage events (e.g., Amazon Web Services Simple Storage Service (AWS S3), Azure Blob Storage,
Google Cloud Storage)
• NoSQL database events (e.g., AWS DynamoDB, Azure Cosmos DB)
• SQL database events
• Stream processing events (e.g., AWS Kinesis)
• Code changes and new repository code commits
• HTTP API calls
• IoT device telemetry signals
• Message queue events
• Short message service (SMS) notifications, push notifications, emails, etc.
The most common types of injection flaws in serverless architectures are presented below (in no particular order):
• Operating system (OS) command injection
• Function runtime code injection (e.g., Node.js/JavaScript, Python, Java, C#, Golang)
• SQL injection
• NoSQL injection
• Publish/Subscribe (Pub/Sub) Message Data Tampering (e.g., Message Queuing Telemetry Transport
(MQTT) data Injection)
• Object deserialization attacks
• Extensible Markup Language (XML) External Entity (XXE)
• Server-Side Request Forgery (SSRF)
Broken Authentication
Applications created for serverless architectures may contain dozens (or even hundreds) of unique serverless functions, each serving a particular function because serverless architectures encourage a microservices-oriented system design.
The overall system logic is created by combining and orchestrating these functions. Some serverless functions might expose open web APIs, whereas other serverless functions might act as “internal glue” to connect processes or other serverless functions. Other sources of events that some functions may consume include SMS notifications, telemetry signals from Internet of Things devices, events from cloud storage, and events from NoSQL databases.
It is a difficult task that can easily go wrong if not done carefully to apply robust authentication schemes, which provide access control and protection to all pertinent functions, event types, and triggers.
Insecure Serverless Deployment Configuration
In order to adapt for particular needs, tasks, or environment, cloud services in general—and serverless architectures in particular—offer a wide range of customization options and configuration settings. It is important to pay attention to certain configuration parameters because they have important effects on the security postures of applications as a whole. The settings offered by serverless architecture vendors might not be suitable for a developer’s needs.
Applications that use cloud-based storage are frequently vulnerable to improperly configured authentication and authorization.
Over-Privileged Function Permissions and Roles
The “least privilege” principle states that a serverless function should only have the privileges necessary to carry out the logic it is designed to.
Inadequate Function Monitoring and Logging
Every cyber “intrusion kill chain” typically starts with a reconnaissance phase, during which attackers scour the application for flaws and potential security holes that they could later exploit. Looking back at significant successful cyber attacks, one crucial factor that was always in the attackers’ favour was the absence of real-time incident response, which was brought on by a failure to recognise early warning signs of an attack. If the victim organisations had effective and sufficient real-time security event monitoring and logging, many successful attacks might have been avoided.
Insecure Third-Party Dependencies
A serverless function should typically be a brief segment of code that completes a single distinct task. Functions frequently use open-source libraries, third-party software packages, and even third-party remote web services that are consumed through API calls to carry out tasks.
However, when importing code from a weak third-party dependency, even the most secure serverless function can become weak.
Insecure Application Secrets Storage
There is a need to store and maintain “application secrets” as applications expand in size and complexity.
Examples consist of: API keys, database login information, and encryption keys.
• Special configuration options
Simply storing these secrets in a plain text configuration file that is a part of the software project is one of the most common errors related to the storage of application secrets. In such circumstances, these secrets are accessible to any user who has “read” permissions on the project. If the project is housed in a public repository, the situation becomes much worse.
Denial of Service and Financial Resource Exhaustion
Denial-of-service (DoS) attacks have dramatically increased in volume and frequency over the past ten years.
Such attacks have emerged as one of the main threats facing almost all businesses with an online presence.
Serverless Business Logic Manipulation
Attackers may use business logic manipulation to undermine application logic. Attackers could circumvent access controls, grant users more rights, or launch a denial-of-service attack using this method.
The manipulation of business logic is a frequent issue in a variety of software and serverless architectures.
However, because they frequently adhere to the microservices design paradigm and include a large number of discrete functions, serverless applications are distinctive. The application logic is carried out by chaining these functions together in a particular order.
Improper Exception Handling and Verbose Error Messages
When compared to line-by-line debugging options for standard applications, serverless-based applications have fewer (and more complicated) options as of this writing. This is particularly true when a serverless function makes use of cloud-based services that are not accessible when debugging code locally.
Developers frequently adopt the use of verbose error messages as a result. They also enable debugging environment variables and eventually forget to clean up code before moving it to the production environment.
Legacy / Unused functions & cloud resources
Similar to other modern software application types, some serverless features and associated cloud resources may age over time and need to be retired. Obsolete application components should be pruned on a regular basis to cut down on unnecessary costs and attack surfaces. Deprecated serverless function versions are one example of an obsolete serverless application component.
• Deprecated serverless functions versions
• Serverless functions that are not relevant anymore
• Unused cloud resources (e.g. storage buckets, databases, message queues, etc.)
• Unnecessary serverless event source triggers
• Unused users, roles or identities
• Unused software dependencies
Cross-Execution Data Persistency
Serverless platforms provide local disc storage, environment variables, and RAM memory to application developers so that they can perform computational tasks similarly to any contemporary software stack.
Cloud providers may reuse the execution environment (for example, a container) for subsequent function invocations in order to make serverless platforms effective at handling new invocations and preventing cold-starts.
Sensitive data might be left behind and exposed in a scenario where the serverless execution environment is reused for subsequent invocations, which could belong to various end users or session contexts.
https://cloudsecurityalliance.org/artifacts/the-12-most-critical-risks-for-serverless-applications/