A New WAS, An Eternal Challenge

Welcome to a new series of resources to accompany the release of our Web Application Scanning (WAS) 3.0 solution. We’ll cover common questions about the solution and, more importantly, we’ll show how scanning ties into the broader challenge of securing web apps.  Web apps are usually the most exposed part of an organization’s network. They serve as everything from a fancy brochure with static data, to interactive services where we connect with others, to apps that collect personal data, to apps that generate millions of dollars in revenue.  All of these apps carry risk for an organization. Not only is it important to know how secure an app is, it’s important to know where all of your apps are in the first place.

And there’s a huge number of web sites to secure. Netcraft’s May 2013 internet survey shows that we’re getting close to the 700 million mark of active web sites. Sure, a lot of those sites have spam links, phishing, malware, and stale content; but far more have apps that need to be secure in order to protect our data, our money, and their owner’s networks.

We designed WAS with automation and scalability in mind. Automation reinforces manual web app testing, it doesn’t replace it. Many parts of a web app testing methodology can be automated. For example, crawlers collect links and forms on a site to help identify attack vectors or find sensitive points like login pages. This is a time-consuming process for manual testing; using a crawler lets the tester focus on areas of a site that require complex interactions or specific sequences of clicks and inputs.

Many kinds of attacks can be automated. For example, most HTML injection (a.k.a. cross-site scripting) and SQL injection attacks follow a simple formula: inject a payload into part of an HTTP request, inspect the server’s response. These kinds of vulns have plagued web apps since the dawn of HTML. Scanners take a straight-forward approach to finding these kinds of vulns since the kinds of payloads required to find them and the kinds of errors that indicate they’re present are well-defined and well-known. This lets a tester focus on finding the more complicated ways these kinds of vulnerabilities manifest themselves.

Scalability addresses the most difficult part of manual testing — trying to keep up with the pace of development and the amount of growth for web apps. It’s not uncommon for an organization to have a dedicated group of a dozen security testers responsible for several hundred web apps. Being able to rely on a scanner enables the web app security testers to apply more effective triage that separates complex, higher-risk sites that require manual attention from other sites whose potential vulns are more easily found by automation. Plus, you can unleash a scanner against sites on a continuous basis, it doesn’t need to take a break or relax early on a Friday afternoon.

There’s a lot to expand on from this post. There are nuances to testing vulns like HTML injection that a scanner must be aware of in order to avoid false positives. And there are plenty of testing methodologies a scanner needs to be aware of in order to avoid missing vulns as well. Even crawling a site requires careful attention by the scanner in order to make sure it obtains good coverage against the app.

We’ll take a look at those issues and more. Plus, we’ll take some detours along the way to talk about infamous web site compromises, how web app security will change with HTML5, and what the future holds for making the entire browsing experience more secure.