OWASP Serverless Top 10 #1: Injection
In serverless applications, the attack surface increases. Since serverless functions can also be triggered from different events sources like cloud storage events, Stream data processing, databases changes, notifications, and more, we can no longer consider input coming directly from the API calls as the sole attack surface.
Moreover, we no longer have control of the line between the origin and the resource. If a function is triggered via email or a database, there is nowhere to put a firewall or any other control that will validate the event.
Security Weakness and Impact
The traditional SQL/NoSQL Injection will be the same. Code injection will allow an attacker to use the provider’s API to scan and interact with other services in the account.
The impact of a successful injection attack will depend on the permissions 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. Roles that allow creating users and permissions can eventually lead into a cloud account takeover.
How to Prevent
- Never trust, pass or make any assumptions regarding input and its validity from any resource
- Use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs)
- Use positive or “whitelist” input validation when possible
- Identify trusted sources and resources and whitelist them, if possible
- For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter
- Consider all event types and entry points into the system
- Run functions with the least privileges required to perform the task to reduce attack surface
- Use a commercial runtime defense solution to protect functions on execution time