The Open Web Application Security Project (OWASP) is releasing a Top 10 interpretation for web application security risks in serverless. Serverless has been gaining a lot of attention as of late because of its ability to eliminate operations and improve speed, costs, and scalability for businesses. However, serverless is a new paradigm and with it comes new risks.

“Companies that are going into serverless without realizing there is a change required in the way they work and think they can just do the same things they did before. But it’s not the same, and that’s not going to work,” Tal Melamed, project lead for the OWASP Serverless Top 10, told SD Times. “The real changes with serverless are at the application security level.”

The interpretation of the Top 10 for serverless is designed to look at the differences in attack vectors, security weakness, and impact as well as remedies to prevent them.

[ What types of applications should you use serverless for? 10 use cases for serverless | How can you successfully transition to serverless? Rethinking the way you build software with serverless | Does the serverless hype match the reality? Serverless: A bad rerun ]

The OWASP Top 10 itself doesn’t change with serverless, rather it just looks at application security from the serverless perspective, according to Melamed.

“Serverless doesn’t fundamentally change what [hackers]/ want, what they want to steal from you, or how they want to steal it,” said Hillel Solow, CTO of serverless security company Protego Labs, who is spearheading the interpretation. “The OWASP Serverless Top 10 is really saying the Top 10 are the same types of things you have to worry about, but how they manifesto and how you protect yourself is very different.”

For instance:

 

  1. Injection: The attack surface for injections increases with serverless since functions can be triggered from different event sources, according to OWASP. “The impact of a successful injection attack will lean on the permission the vulnerable function has. If the function has been assigned a role that grants it liberal access to a cloud storage, then injected code could delete data, upload corrupted data, etc.,” OWASP wrote in the interpretation. To prevent these types of attacks in serverless, OWASP suggests things like never trusting, passing or making any assumptions about input and the validity from any resource, and using a safe API.
  2. Broken authentication: According to the OWASP, broken authentications are a result of poor identity and access control design. With serverless, things can become increasingly complex because it comes with multiple potential entry points, services, events and triggers. “Having access to functions without authentication can lead to sensitive data leakage, but could potentially also lead to breaking the system’s business logic and flow of execution,” the OWASP wrote. Suggestions on preventing this include: Requiring different types of authentication for different types of identity and access controls; and requiring authentication for external-facing resources.
  3. Sensitive data exposure: “There is no change of impact in case of sensitive data exposure. Sensitive data such as sensitive personal information (PII), health records, credentials and credit cards should be protected, no matter the architecture,” the OWASP wrote.
  4. XML external entities (XXE): X
  5. Broken access control: Businesses do not own the infrastructure in serverless, so things like removing admin/root access to endpoint is not a concern. The concern in serverless is granting functions access to unnecessary resources or excessive permissions, the OWASP explained. Remedies include: examining each function and following the least privilege principle on each, and reviewing each function before delivery.
  6. Security misconfiguration: “Serverless reduces the need to to patch the environment, since we do not control the infrastructure. However, in many cases the biggest weakness is human error. Secrets could be accidently uploaded to the GitHub repo, put on a public bucket or even used hardcoded in the function,” the OWASP wrote. This could result in sensitive information leakage, money loss or even unauthorized access. Solutions include scanning cloud accounts to find public resources and reviewing cloud resources to verify access control.
  7. Cross-site scripting (XSS): XSS attacks originate from different sources in serverless such as email, cloud storage, logs and IoT. Traditional ways of  preventing XSS remain the same in serverless. “This is one of the only risks for which original recommendations stand. Encoding all untrusted data before sending it to the client, as well as using known frameworks and headers are still valid in serverless,” OWASP wrote.
  8. Insecure deserialization: “As usual, the business impact depends on the application and the data it handles. Insecure deserialization usually results in running arbitrary code that could eventually lead to data leakage and, in severe cases, even resource and account control,” OWASP wrote. Ways to prevent this in serverless include validated serialized objects, reviewing third-party libraries and monitoring deserialization usage.
  9. Using components with known vulnerabilities: Serverless functions often include many dependencies and third-party libraries, according to OWASP. Hackers will try to attack systems through vulnerable libraries. “Like any facet of cybersecurity, securing serverless applications requires a variety of tactics throughout the entire application development lifecycle and supply chain. However, since vulnerable dependencies are the same risk as in traditional applications, most of the best practices are still relevant,” OWASP explained.
  10. Insufficient logging and monitoring: Lastly, the lack of monitoring is a common way attackers get into systems because they can achieve their goals if undetected. “The impact of not having a proper auditing mechanism in place cannot be determined by itself. But, the impact of identifying security incidents too late can be significant. An attacker may already be part of the application and infect the code. It is worth mentioning that the ephemeral nature of serverless functions makes exploits less sticky, which means that even if the application was infected, it might go away by itself, if the attacker is not using techniques to make the exploit last,” the OWASP wrote. Suggestions for prevention include; making use of monitoring tools from the service providing and deploying an auditing and monitoring mechanism for data.

 

 

“Since serverless applications are vastly different, security risks have changed,” said Melamed. “With serverless, hackers must try different vectors and approaches for attacks [and]  developers cannot employ traditional perimeter protections and need to change their way of thinking, as almost none of the mitigations suggested for traditional applications would fit in the serverless world, which is why we’re working on the OWASP serverless Top 10 project.”

The Serverless Top 10 release is just a first draft of the interpretation. The OWASP will be establishing a public open call to collect data and comments before the final version of the Serverless Top 10 report is published. OWASP anticipates the final version to be released in April 2019.