Serverless security implications from infra to OWASP
1–10 of 16 posts
Re: Serverless security implications from infra to OWASP
#2> 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.
Re: Serverless security implications from infra to OWASP
#3Also 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.
Re: Serverless security implications from infra to OWASP
#4I gave a talk about this at CCC this year!
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:
Re: Serverless security implications from infra to OWASP
#5I'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.
Re: Serverless security implications from infra to OWASP
#6Another 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.
Re: Serverless security implications from infra to OWASP
#7I'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 servic…
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.
Re: Serverless security implications from infra to OWASP
#8I gave a talk about this at CCC this year! 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
Great talk mate. Very interesting :)
Re: Serverless security implications from infra to OWASP
#9Another 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 final…
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...
Re: Serverless security implications from infra to OWASP
#10Also 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.
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.