How testing perspectives helps find application security flaws

People often lose sight of what's happening with their application security testing and what their test results actually represent. While proper vulnerability and penetration testing should represent reality, such testing rarely takes place. I have seen so many situations over the years where organizations claim that their web application environment has been properly vetted when that was hardly the case. To say that assumptions, oversights and gaffes in the testing process are creating a strong false sense of security -- in the context of application security -- is an understatement.

In this tip, we'll discuss aspects of the application security testing process that should not be overlooked in order to create a more sound process and eliminate application security flaws.

One common issue is that the primary focus is on the most visible core business applications while other, presumably benign, applications such as network and security management systems, multifactor authentication systems, marketing websites and other microsites are either put on the back burner or not tested at all. This is not intentional but rather a side-effect of the process. By performing an in-depth systems inventory and business impact analysis, you'll likely be surprised by how many untested applications process and store sensitive business assets.

Similarly, you need to ensure that all applications are being internally vetted by you and your team or by an outside party. Quite often in the security assessment scoping process, people claim that an application or system doesn't need to be tested because it's being hosted elsewhere, for example at a hosting provider's facility or in AWS. By saying this, they are fooling themselves and, in many cases, people believe that if they're paying for bandwidth and uptime, then someone is surely overseeing the security of these application environments -- this is rarely the case. Unless you see periodic vulnerability and penetration testing reports resulting from network and application-level testing for these systems, due care hasn't been established.

Keep in mind that SQL injection vulnerabilities, business logic flaws and weaknesses in password policies can be found and exploited not just by users, but also by criminal hackers who have stolen your legitimate users' login credentials.

Furthermore, systems that are reviewed from the perspective of an untrusted outsider with no authenticated testing being performed is arguably the greatest barrier to reasonable application security -- individuals assume that "trusted" users who can log in and interact fully with the system are not going to do anything bad. Not unlike performing authenticated testing of servers and workstations, there are  myriad security vulnerabilities that are uncovered when testing applications as logged-in users, yet it doesn't happen enough. I'm certainly not suggesting you test your applications from the perspective of every possible user, but you do need to test the important user roles, such as the ones that represent the largest number of users, as well as top-level admin roles, in order to help find application security flaws.

In order to aid the testing process, you should consider rotating through the various user roles while testing is being done throughout the year. If your experience is like mine, you'll find different security vulnerabilities with different user roles. Keep in mind that SQL injection vulnerabilities, business logic flaws and weaknesses in password policies can be found and exploited not just by users, but also by criminal hackers who have stolen your legitimate users' login credentials. When this happens, it can be difficult to discern typical user behavior from malicious behavior.

It should be noted that network security controls that are left enabled can prevent vulnerability scanners, exploit tools and related testing from functioning properly. Many IT managers, security admins and DevOps personnel prefer to leave their enterprise firewalls, intrusion prevention systems and web application firewalls enabled during such testing. While that's all fine and good if you are testing your network security controls, it's not the real world: application security flaws can be overlooked when approached this way. If you do this type of testing -- for example, if you leave your security controls enabled -- then you should make sure that you're also disabling them or, at least, whitelisting the source IP addresses to ensure that the entire attack surface has been fully evaluated.

In a perfect world, we would have a minimal tool set to find the maximum number of application vulnerabilities; however, the world is not perfect. Whether it's standard network vulnerability scanners, application vulnerability scanners, HTTP proxies or source code analyzers, no one tool is going to find everything. In fact, in each category I have found that different scanners usually find different things. While it's a frustrating reality of application security testing, you must do what you can to use multiple tools or you risk leaving vulnerabilities unacknowledged and unaddressed.

Overall, there's no way to fully understand where your applications stand if you're not looking at them in the right ways. While you don't have to do in-depth testing every quarter, every month or in real time, you do need to do it periodically and consistently, as looking from all possible angles is the only way to ensure that the software side of your information security program is free from application security flaws.