Crap app tapped to trap mishaps: Demo insecure software built to school devs on secure coding

The Damn Vulnerable Serverless Application ships expletive-ready

To help those deploying serverless applications do so without stumbling into vulnerabilities, security biz Protego Labs has released crappy code in the hope there's something to be learned from studying the bugs.

The company has developed a slipshod app called the Damn Vulnerable Serverless Application (DVSA) and donated it to the Open Web Application Security Project (OWASP), a non-profit focused on helping developers write more secure code.

In a phone interview with The Register, Tal Melamed, head of security research at Protego Labs, explained that the name represents a continuation of a tradition in the security community. DVSA follows in the footsteps of the Damn Vulnerable Web Application (DVWA), the Damn Vulnerable iOS App (DVIA), Damn Insecure and Vulnerable App for Android (DIVA), and the discontinued Damn Vulnerable Linux (DVL).

DVSA also follows a similarly shoddy serverless project called Serverless Goat, donated to OWASP by security biz PureSec last month.

"Security methodologies that were efficient in traditional applications no longer apply to serverless, and the best way to demonstrate this is through a serverless application that can highlight the new challenges and the risks associated with adopting these architectures," Ory Segal, CTO of PureSec, said in an email to The Register.

Developers now have both Serverless Goat and DVSA has hazard maps.

Melamed said it wasn't hard to create bug-riddled code for DVSA. "We wanted to make it realistic," he said. "What we did was wrote a regular application then tweaked it to make it vulnerable."

The flaws, he said, focus on the particular nature of serverless applications, so there's no cross-site scripting vulnerability, something often seen in web apps.

DVSA comes chock full of flaws, both documented and undocumented, related to event injection, authentication, data exposure, cloud configuration, access controls, denial of service, over-privileged functions, logic vulnerabilities, dependencies and unhandled exceptions, among others.

Melamed said when companies adopt serverless apps, they often mistakenly assume that their cloud service provider will take care of security. "They forget they need to make sure their code is secure," he said.

The biggest challenge, said Melamed, is to know the risks and how they differ in a serverless app. "People may assume it's the same as any application but it's not," he said.

For example, he points to monolithic apps where there's a single entry point, usually a network protocol. "In serverless, the entry point could be various events you don't control," he said, adding that the situation becomes complicated because you can't rely on an IPS or firewall to filter bad input.

Ultimately, Melamed said the biggest benefit of bad code for the serverless community will be the opportunity to learn to avoid those mistakes. ®