All of us have problems. Some of them big and some small. Then there’s Application Security. In my discussions with technology heads of high-velocity application companies, they come up with a single problem. Application Security. “We can never seem to get ahead of the problem”, they say, wearily as they try to remediate findings from their latest penetration testing or vulnerability assessment report. Release cycles are delayed or heavily compromised, customers are unhappy over security flaws or you are constantly on edge about some hacker (or script kiddie) completely owning your application and putting your company on the headlines of the front page of next day’s news, and subsequently have “expert bloggers” like me writing articles like “5 Things you can learn from So and So breach” Let's face it, your application security sucks! But don’t fret, there’s hope yet. In my opinion, there are 3 very critical things that organizations miss out on when trying to fix application security. This is not typically testing or secure coding or any other typical solutions that you would have come across. I am going to use stories to make my points. Here goes…
The $1 Hotel Room
We were recently testing a large and significant SaaS Solution that integrates with some of the biggest hotels and hotel chains in the world to give them easy online booking and customer relationship management solutions. They are a highly competent and technical team that has a good understanding of security. They were confident of their ability to have thwarted the OWASP Top 10 categories of flaws and were handing over their app to us for a penetration test. During the pentest we found that their web service was vulnerable to a integrity flaw, where we were able to bypass their checksum controls and manipulate booking amounts for hotel rooms. We were able to book a hotel room that was worth $650 for $1. Needless to say, they were shocked and admitted that they needed some time to fix this flaw. During my discussions with their VP of Engineering, I asked him why they had missed an obvious flaw like that. He said that they had looked at flaws like SQL Injection, Cross Site Scripting and what was considered “typical OWASP Top 10” flaws and had focused on the controls and counter-measures to address that.
This “Control-driven” Application Security culture is quite rampant. Companies use “lists” like the OWASP Top 10 and SANS Top 25 to dilute and create a bunch of security countermeasures that would address the vulnerabilities expounded in these lists. They completely miss out on business logic flaws and business-focused flaws because they don’t think “Threat First”. I have personally seen and implemented Threat Modeling Frameworks for organizations that has delivered amazing results as these companies were forced to think “Threat First”. This form of thinking gets you to analyze and detail some of your most critical threats in both business and technology terms and come up with high quality counter measures. In addition, these can be used as “security test cases” to perform detailed security testing for these Threat Models.
There are many ways to model and inculcate a “Threat First” thinking, including Threat Modeling, Table Top Simulations, etc.
Me and my Dependents
During a pentest for a major cloud application company recently, we identified a pretty serious authentication and session management flaw. For some reason they were failing to invalidate their Auth Token and their web service could be spoofed quite easily, if an attacker figured out the steps to do so. Turns out that the PaaS platform that they were using had a flawed token expiration call that didn’t really invalidated the Auth Token, rendering the application vulnerable to spoofing and similar attacks. Then, in the same pentest, we found a serious flaw in their Crypto library as well. In an age of modular applications rife with large number of dependencies with their own set of dependencies, this is becoming the biggest problem that tech teams have to deal with. Security flaws in underlying libraries, server components (in an ever increasing stack) and other executables are causing much pain to technology teams.
Unfortunately, there aren’t many great ways of addressing this other than certain customized solutions. We were shocked when we found that vulnerabilities in one client environment were cut by 65% when we implemented a security dependency management solution that we had developed for them. It became an integral part of their CI/CD process. Either way, the first way to tame the problem is to make an inventory and constantly update the inventory based on changes to the application. Luckily package managers and build tools provide functionality to extract and store this information for use. Once this is done, manual or automated investigative techniques must be used to identify and actively remediate security threats from dependencies.
“We have a tool"
I am in awe of marketing departments at some of these security companies. They make it sound like their product can find anything from SQL Injections to a needle in a 1 ton haystack. Their products are sold as a panacea to InfoSec and AppSec teams that are looking to solve their security problems with one or more of these tools. Unfortunately, these tools can’t find crypto bugs, business logic bugs, authorization bugs, authentication bugs, advanced SQLi bugs, Advanced XSS bugs, and mostly bugs with web services or slightly complex RIA frameworks. See where I am going with this? Tools are great, we all use them. I use them a lot, but I also understand that each app is different and tools can only help you with low-lying security flaws and point you in the right direction. Missing out on Manual testing or scripted manual testing is like missing out on the main course at the buffet. You’re going to remain hungry while someone else has your food. A very revealing statistic was when we integrated manual security testing into the CI/CD pipeline of one of our largest clients and they were able to identify and eliminate 100% of their critical and high vulnerabilities even before it went to Staging. Believe me when I say that there’s no better way to test an app as with a combination of manual and automated, that a purely automated tool can’t even come close to uncovering.
This article was originally published on the author's LinkedIn page.