Why ALL of your apps need security testing
When it comes to application security, are you looking in all the right areas for all the right issues? Odds are, you’re not. Many people will argue they’re testing their critical enterprise applications and that’s what matters. That’s true to an extent. Prioritization is key in any business endeavor. In fact, there’s a fundamental time management principle that says you need to focus on what’s urgent (has a deadline or otherwise needs to be addressed ASAP) and important (is considered a crucial task). This principle translates nicely to application security, but it’s not the whole story.
Attacks are equal opportunity
Considering the bigger picture, practically anything with an IP address or URL is fair game for attack and abuse. Business risks can be introduced by seemingly benign web applications such as business unit applications with minimal visibility, web services with a marginal footprint, and even network system web interfaces such as firewalls, storage, and physical security control systems. Perhaps the most underrated type of presence in terms of security risk are marketing websites and their content management systems, since they’re often believed to have nothing of value. But the reality is, all systems do have something of value to an attacker.
Common flaws I see in practically every web security assessment I perform are as follows:
- Cross-site scripting
- Cross-frame scripting
- Unhandled exceptions
- Default or temporary passwords that are easily guessed
- Hard-coded database access/functionality
- Weak user passwords often combined with no intruder lockout in the login mechanism
- Poor user session management
- The presence of SSL and SSL/TLS misconfigurations, such as missing patches and unencrypted logins on admin pages
- Open web proxies
Although not as common as the web security vulnerabilities above, I often find malware-infected web pages as well as SQL injections that are providing direct access to critical databases—both of which, in all likelihood, will go undetected without the proper compensating controls. Sometimes these findings are present on brand-new web applications that are still in development and have never been tested for web vulnerabilities. It’s great to catch such flaws before the applications go into production. Still, others have been in production for quite some time and have been tested for security flaws for years.
Such findings underscore the need to test web applications periodically and consistently over time. There are also cloud-based applications that may be hosted by a third party that’s quick to share its SOC report showing how secure its data center is. Unfortunately, such reports say little to nothing about the security posture of web applications themselves. Even the open source web applications that every business relies on in some form—and that have supposedly been vetted for security issues—have shown time and again they’re not impenetrable.
All in on keeping risk to a minimum
At the end of the day, every single web application tied to your business has the potential to create risks that you may or may not be prepared to take on. When external attackers or rogue insiders stumble across these applications and, especially, the low-hanging fruit most of them are serving up, odds are they’ll be abused for ill-gotten gains. The question then becomes, what are you doing about it?
Getting back to priorities, you certainly need to focus on your highest payoff tasks—that is, your financial systems, customer-facing applications, business partner web service connections, and the like. Once you’ve done that, you need to maintain your momentum and start drilling down further into your network. You likely know which additional systems exist that haven’t been tested or haven’t been a priority, including the seemingly unimportant systems I listed above.
Much of this web security testing process likely exists solely in your head. If so, it’s time to start documenting your priorities and plans. You might consider consulting with teams outside of IT and security, such as your business continuity planning, finance, and legal teams. They might be contractually bound to test specific web applications. Or perhaps these teams have performed business impact analyses that include web systems you never knew about. It’s shadow IT at its finest, but it’s up to you to acknowledge what’s where and get things under control. Eventually you will want to start building all of your web applications into your security testing plans and scope.
When you’re testing, be sure to look at your environment from multiple perspectives—from the outside in and from the inside out, testing both publicly accessible applications as well as internal applications. Do both unauthenticated and authenticated testing. You might run scans for one month, or quarter, and then perform manual analysis for the next go-around. If you have the time and resources, you might even consider rotating testing certain web application functionality for security flaws.
What workflows present the greatest risks? Do specific systems have to be in place or connected in order to access—and exploit—this functionality? Are there specific user roles that present greater threats to your web environment than others? Even source code analysis, ideally using an automated static source code analyzer, should not be out of the question.
One step at a time
The important thing with all of this is to practice what I call relentless incrementalism. Test your entire web application environment a little bit at a time, over and over again, and eventually it will all add up to positive results.
How broad is your approach to app security testing? Are you ramping up and testing more, or prioritizing only high-value systems? Is this a workable approach?