Application security vulnerabilities are often known exploits

Microservices security

It's hard to believe that basic access control continues to be an issue, but in this new age of containers and microservices, it's not uncommon at all for developers to package and deploy server-side software components without any access control settings at all. Annotation-based security, a fine feature that should make applying access control easier, not harder, is often to blame.

With annotations, Java classes and their contained methods need only be decorated with a small piece of text, which subsequently applies security. When this is done correctly, access control problems disappear. But the simplicity of annotation-based access control can have devastating consequences. Developers can get into trouble if they delete an annotation while troubleshooting and then forget to code it back in before deployment.

Jeff Williams

"Just leave out an annotation, and all of a sudden, you've got a microservice that's not protected," said Jeff Williams, CTO and co-founder of Contrast Security.

It's a rookie mistake to make, but it's a problem that arises in the most professional of environments. Another well-known exploit that should never appear on an assessment of application security vulnerabilities is the cross-site request forgery (CSRF) issue.

"Basically, the solution to CSRF is to add a token to your forms and links in order to prevent them from being forged," Williams said. "And most people either don't do it or they don't do it right."

CSRF attacks will succeed despite the fact that precautions to prevent and thwart such attacks are well-known and well-documented.

New scripts, same security vulnerabilities

It's almost embarrassing to mention it, but injection techniques -- be it SQL injection, Lightweight Directory Access Protocol injection or command-line injection -- are all regularly flagged when Angular front ends and microservices back ends get scanned for application security vulnerabilities. All it takes to prevent most of these injection problems is to perform simple validations on any text your applications might consume -- whether that text is garnered from the client through an online submission form or information embedded within a JSON string. The need to validate incoming text for escape sequences and executable scripts is not a new revelation to the world of software development, yet it's a task that even experienced developers routinely skip.

So, why are all of these easily addressable application security vulnerabilities still regularly appearing in production deployments? Williams said we can blame much of it on the shift toward new JavaScript frameworks based on the model-view-controller methodology, like Angular and Ember. Not that these frameworks have any inherent security flaws, but instead, the simple shift from one programming paradigm to another has made developers forget about the basics.

It's as though people just forgot all of the security-related best practices they had previously learned.

"When we moved from pure web apps with HTML interfaces to web services with Angular front ends, we ended up exposing all of these services," Williams said. "It's as though people just forgot all of the security-related best practices they had previously learned."

It’s not a problem unique to the realm of security either. Organizations somehow start to omit compliance rules that were rarely overlooked in the traditional data center when they move to the cloud.

"How do you expire passwords? Do you have your firewall turned on? Do you have mandatory access controls on the system machine?" Julian Dunn, director of product marketing at Chef, said. "These best practices are easy to ignore when you’re deploying into that environment."

Don't trust vendors with your security

But Dunn doesn’t attribute compliance or security omissions to negligence by software engineers but, instead, attributes it to the way various vendors provision their cloud computing environments to their clients.

"When a cloud vendor provides you its API gateway and they tell you that it has a web allocation firewall in front, you immediately think, 'Oh, somebody else is accountable for that, right?'" Dunn said.

The result? Well-meaning software developers assume the firewall meets all of the compliance requirements or that it will meet all of the organization’s security needs. But this type of blind faith in the cloud provider can create serious shortcomings in terms of security and compliance.

Williams also asserted that some of the existing tools intended to detect security holes are failing to deliver and took particular aim at existing static analysis tools. "Static analysis tools take too long to run; they require experts in order to operate them and interpret the results, and they produce a huge number of false positives. They also miss a lot," Williams said. "If it takes a week to get your application scanned and another week to interpret the results, that's just way too long."

Cloud computing and the new, modular, container-based systems used for developing and deploying microservices and serverless applications have significantly changed the way applications are developed. But that doesn’t mean security and compliance best practices should be abandoned. In fact, going back to first principles and making sure all of the basics are covered will go a long way to ensure deployed applications meet all of the required compliance standards, while, at the same time, are free of any oblivious application security vulnerabilities.