“The global serverless computing market is expected to witness a further growth in the forecast period of 2022-2027, growing at a CAGR of 22.2%, according to the industry analyst firm Expert Market Research group. Such growth is driven by the need for cost effective computing services, low maintenance and strong demand for web and mobile applications to address the rising consumer demands.
However, rise in serverless adoption has also seen rise in security related incidents. Despite the security features offered by cloud providers, typical characteristics of serverless such as short runtime durations, volume of executions, and the dynamic and fluid nature of the server functions can make it difficult to detect, investigate and respond to a potential compromise.
For example, the Denonia Malware, first ever known malware to attack AWS Serverless service – Lambda functions – created ripples in the serverless world. This malware written in Go Lang used a DNS over HTTPS (DoH). DoH encrypts DNS queries and sends the requests out as regular HTTPS traffic to DoH resolvers.
The primary reason for this gap is lapse in customer commitment to uphold the shared-responsibility agreement. While AWS is full responsible for global infrastructure that runs all of AWS Cloud, under the shared-responsibility model the user maintains control over his or her content that is hosted on the Amazon infrastructure, including Serverless functions such as AWS Lambda. When customers fail to keep up their end of the promise, it leads to security lapses such as the Denonia malware.
The Denonia malware incident exposed a vulnerability that led AWS to introduce “additional- security mechanism” to protect the Lambda functions – the Lambda function URLs – a new feature allowing cloud builders to set up simple, dedicated application endpoints for Lambda functions.
A function URL is a dedicated HTTP(S) endpoint for your Lambda function. You can create and configure a function URL through the Lambda console or the Lambda API.
When you create a function URL, Lambda automatically generates a unique URL endpoint for you. Function URL endpoints have the following format:
Although Lambda functions could already be externally exposed via API gateways and load balancers, Lambda URLs let AWS users fast-track this process with minimal overhead, for straightforward use-cases such as webhook handlers.
Additionally, Lambda URLs can be used during the development and testing of Serverless applications, allowing developers to focus on core functionality and postpone dealing with validation and authorization requirements to later stages of development.
Function URLs are best for use cases where you must implement a single-function microservice with a public endpoint that doesn’t require the advanced functionality of API Gateway, such as request validation, throttling, custom authorizers, custom domain names, usage plans, or caching.
For example, when you are implementing webhook handlers, form validators, mobile payment processing, advertisement placement, machine learning inference etc.
Lambda function URLs may be simple, but like any other externally exposed resource in your cloud environment, it is important that they be properly secured as well. While functions residing behind an API gateway or load balancer rely on the secure configuration of these frontend services, function URLs must be independently secured, and misconfigured instances could pose an attractive target for malicious actors hoping to cause damage or gain access to sensitive data.
Below is a classic example of A function URL could be at risk of an attack under the following circumstances:
The above elaborated risk could give rise to multiple impacts to the targeted cloud environment:
This might interest you: AWS Glue for Serverless Data Integration Services for Analytics and Machine Learning
1. IAM authentication and authorization
In general, it is advised to always require both authentication and authorization for invocation of a Lambda function, and to host it in a private subnet within a VPC. If your function needs public internet access, for example, to query an external non-AWS API, then you should expose it through a NAT gateway in a public subnet within the same VPC.
If cross-origin resource sharing (CORS) configuration is enabled, by default the function URL will accept HTTP requests from any origin (domain), which is not recommended. Therefore, you should configure additional CORS constraints, such as only allowing HTTP requests from specific origins, or requests containing specific headers and HTTP methods (GET, POST, etc.)
3. Reserved concurrency
By reserving concurrency for every function with a URL and limiting it to a maximum value, you can ensure that even if a function URL is somehow invoked repeatedly by a malicious actor attempting to cause disruption, any business impact will be limited to the specific compromised function, while unrelated operations in the same region will remain unaffected.
Indium is a digital engineering leader and full spectrum integrator that helps customers embrace and navigate the cloud-native world with certainty. Regardless of where you are in your digital journey, Indium helps you to migrate/modernize your applications and data on the cloud, make sense of the data and leverage automation to scale and innovate in a secured and compliant fashion.
With deep expertise across Applications, Data & Analytics, AI, DevOps, Security and QA Indium makes technology work and accelerate business value, while adding scale and velocity to customer’s digital journey on AWS.
By Uma Raj
By Uma Raj
By Abishek Balakumar
Sangeetha Govardhan is AVP- Cloud Services at Indium Software.