eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
While serverless technology is becoming increasingly widely used, there has been a lack of understanding when it comes to serverless security implications. That’s a challenge that Protego Labs is looking to help solve with the release of a freely available open-source tool that helps organizations learn about serverless security.
Serverless, also referred to as functions-as-a-service, is technology that enables organizations to run functions in an event-driven approach, rather than requiring a long running persistent server. Among the most popular serverless platforms is Amazon Web Services (AWS) Lambda, which provides some default security capabilities in the cloud at the infrastructure layer. Although AWS provides some security capabilities, there are still application layer risks that organizations need to be aware of when it comes to serverless. The Protego Labs Damn Vulnerable Serverless Application (DVSA) is a purposefully insecure serverless application and toolset that provides organizations with insight into how to properly secure serverless deployments.
“Our customers were looking for a way to help better understand the real risks from serverless,” Tal Melamed, head of security research at Protego Labs, told eWEEK. “So we decided to come up with DVSA, which is an attempt to be a realistic serverless deployment, and it interacts with various cloud resources, including databases, that are typical for a serverless application.”
Founded in 2017, Protego Labs itself is in the business of providing serverless security. DVSA is open-source technology that Protego Labs is contributing to the Open Web Application Security Project (OWASP) with project code hosted on GitHub, and there is also an online hosted version set to debut this week at serverless.fail. DVSA makes use of the OWASP Serverless Top 10 list project, which provides a listing of the most common serverless flaws and misconfigurations that organizations need to consider.
“Serverless services run code without provisioning or managing servers and the code is executed only when needed,” the OSAWP Serverless Top 10 project page states. “However, even if these applications are running without a managed server, they still execute code. If this code is written in an insecure manner, it can still be vulnerable to application-level attacks. “
Melamed explained that DVSA has a directed path to help users learn how and where to find the vulnerabilities that are part of the project. Among the primary serverless risks is that of injection attacks.
“Injection attacks are well-known in the web application space, but when it comes to serverless, injection attacks are not coming from the same places that developers might expect,” Melamed said.
In an injection attack, some form of unauthorized or unexpected content or data is injected into an application flow. Among the most common injection attack vectors is SQL injection, when hackers input different code strings to exploit databases. In a regular web application, an injection attack comes from a user input as an entry point. Malemed said that with serverless, an injection attack can come from an event that the serverless function calls to execute. Malemed said that examples of potential serverless injection attacks include sending unauthorized emails with information or potentially uploading a file.
Function permissions is another area of potential vulnerability with serverless. Melamed said that prior to serverless, permissions were typically managed at the infrastructure level, with a determination made what access permissions a given application might need. With serverless at AWS Lambda, each function can be granted its own permissions for what it can do within an account. As such, Malemed said that it is incumbent upon developers to make sure they assign the right permissions.
“What we see in practice is that companies create permission templates for developers and tell them that every function that is developed should be covered by the template,” Melamed said. “The templates typically cover hundreds of permissions and actions inside of an account.”
Melamed added that the majority of serverless functions do not need the full permissions that permission templates provide. By providing more permissions than a serverless function needs, there is a potentially larger attack surface that an attacker could exploit. Looking at permissions from another perspective, Melamed said there is also an opportunity for organizations to implement better granular permissions and reduce the attack surface by limiting individual functions to only have the very specific permissions that are needed.
“Serverless can be a risk, but it can also be an opportunity to improve security,” he said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.