
Serverless security implications from infra to OWASP - tkadlec
https://snyk.io/blog/serverless-security-implications-from-infra-to-owasp/
======
raesene9
I'm not sure, in practice, how much of a win for serverless reduced patching
is, compared to say a containerized environment.

You're still likely to be deploying all the exposed components yourself (i.e.
the web application and it's attendant libraries), so the attack surface and
possiblity for exploitable vulnerabilities is similar.

There's a win if you're comparing to a setup where you have a load of exposed
services that aren't directly related to the application (so management
services like SSH) but these days I see a lot fewer of those exposed directly
to the Internet from the web server hosts.

What is likely a win is lack of persistence. Attackers need to pull off
attacks with limited opportunity for storing something on disk and calling it
after the initial compromise, when compared to longer running services.

The thing that becomes totally critical in a serverless architecture is access
control and credential management for the underlying cloud platform. Where a
load of, for example AWS services are used an attacker who can get access to
the console via stolen credentials can do a lot of damage, if IAM profiles
haven't been managed properly.

~~~
drvdevd
Right. You have to authorize to some sort of management layer _somewhere_. In
this case at the cloud API level. It's nice that it's not directly "in band"
with the rest of your application code in the same physical address space,
like say SSH, but you have no idea of the actual hardware isolation involved,
unless you were an engineer building said cloud.

I guess what I'm trying to say is serverless just seems like a way of shifting
management layers around, giving the appearance or feeling of less management.
I'm not saying thats not valuable - I haven't tried it. This is just my view
from the outside.

------
Mizza
I gave a talk about this at CCC this year!

[https://media.ccc.de/v/33c3-7865-gone_in_60_milliseconds](https://media.ccc.de/v/33c3-7865-gone_in_60_milliseconds)

I'm sitting on a toolkit for this, just need to spend a Sunday polishing it to
release quality:

[https://github.com/Miserlou/Mackenzie](https://github.com/Miserlou/Mackenzie)

~~~
movedx
Great talk mate. Very interesting :)

------
jondubois
Also a big one that the author forgot to mention; because server-less back-
ends are shared by many companies, there is a stronger incentive for hackers
to try to hack the provider.

~~~
api
I'm really quite astounded that there haven't been more huge cloud hacks. I
guess hypervisor authors and cloud providers have taken security seriously
enough.

~~~
politician
The existence of hypervisor rootkits and the vast scale of cloud provider
operations argue for caution.

For example, a state-level actor can afford to train and place operatives into
an AWS-scale organization with enough access to infiltrate and undermine the
system.

~~~
api
We use bare metal hosts for the ZeroTier CAs. This is one reason, though
cost/CPU is another. These machines are CPU-bound, spending most of their time
signing network configs. CPU is way cheaper at OVH (bare metal) than anywhere
else.

------
steven777400
Another key aspect is new security approaches to consider during development
and integration. Currently an API can be secured as desired, and everything
else can be hidden behind the firewall. With the serverless approach more
thought has to be given to ensure there isn't "round-a-bout" ways to bypass
application security and data validation.

Edit: I don't mean to sound negative, I think serverless structure is finally
the realization of what "cloud" has promised and not quite delivered for so
many years.

~~~
inyorgroove
I don't know what you are trying to say. Any complex API will have to have
some custom validation code.

What we have been doing is using typescript interfaces[1] to validate our API
input data. This really makes the data validation painless for us.

 _EDIT_ : Thinking about this a little more, this really only ensures that the
provided data is the right "shape", there may still need to me more validation
performed.

[1] [https://github.com/ysangkok/typescript-interface-to-
jsonsche...](https://github.com/ysangkok/typescript-interface-to-jsonschema)

------
yeukhon
> 8\. Greater flexibility leads to greater attack surface

I think this is critical. The fact that there aren't many battle-tested
frameworks out there writing your own functions can introduce security bugs.
But from my experience, most of the use of Serverless code are very backend,
cronjob type of code, and aren't necessarily tied to any real applications.
Remote execution is still possible though. I am not sure how many people out
there run their website in API Gateway. I've read about one or two stories,
but that's it.

Another thing is not security-related, but more with reliability. Serverless
development poses challenge for performance monitoring.

------
eeZah7Ux
Also, for penetration testers it's usually not legal or in breach of contract
to try to compromise services running on cloud/serverless infrastructure
because they would impact 3rd parties, starting from the cloud provider
itself.

