Strategic Security: Web Applications Scanners

Web 2.0 encompasses lots of big ideas, but we've found it's the concept of RIAs that keeps many information security pros awake at night. Splitting intelligence between server and client, as is done with Rich Internet Applications, is a fundamental shift ... and a risky one given the sad state of browser security. Moreover, while it affects only a subset of RIAs, the Ajax development model has both momentum and traits that make eliminating vulnerabilities a real challenge.

Web application scanners can help, but implementation is tricky. For this Rolling Review, we decided that instead of simply focusing on boxed Web application scanners, we'd consider the entire decision-making process. What we found are at least four distinct paths to RIA and Ajax security. (For more on what we plan to test, see our Web Application Scanners Rolling Review scenario box.)

Targeting The RichSo why are RIAs so insecure? Put very simply, in a conventional Web application, the intelligence is in the Web server. Browsers basically act as dumb remote displays. Yes, ActiveX, Java applets and other techniques did (and still do) provide for more "intelligent" data transfer. But RIAs take this to a new level, with browsers hosting interactive applications that directly query servers for data.

Today, Ajax applications share the RIA stage with Adobe's Flash and Apollo, Sun's Java, Microsoft's Windows Presentation Foundation, and ActiveX. But Ajax clearly has the most momentum.

Ajax, which stands for Asynchronous JavaScript and XML, has become a key Web 2.0 buzzword--so much so that its use has grown beyond just applications that actually use asynchronous JavaScript and XML! Most applications labeled "Ajax" do indeed use asynchronous JavaScript--the initial page loads from the server with JavaScript that makes asynchronous requests back to the server as needed, loading only the data and parts of the Web page that must be adjusted for whatever action is being taken.

Typically, data is transferred between the server and client in Ajax applications using XMLHttpRequest API calls transferring XML. However, because of the extra complexity and slight overhead of processing XML messages, many applications use the same XMLHttpRequest calls with alternatives like JSON (JavaScript Object Notation). JSON uses JavaScript objects as the data transport instead of XML. In this way, the client half of the application can execute the data returned from the server to have access to the results of its action directly without the parsing required for XML.Similarly, some applications return raw HTML results, which JavaScript can add to the DOM (Document Object Model), the browser's programming model for JavaScript to interact with HTML and XML, modifying the page asynchronously without XML or JSON.

Still, the name stuck, and even applications that use JSON or HTML instead of XML as a data transport mechanism are often lumped together as "Ajax." If there were a more accurate descriptor, we'd be glad to swap out the misnomer, but for now we're stuck with it.

Note that other RIAs may well catch up--Flash and Java in particular seem to have large, and growing, followings. Problem is, neither of these is commonly assessed by Web application scanners. With Java, we recommend supplementing an external scanner, like those we'll be evaluating in the course of this Rolling Review, with a source-code scanner, such as those we reviewed recently (see "Code Scanners Run the Gauntlet").

Continue Reading This Story...

Count The WaysHaving Web browsers directly query servers impacts application security in a variety of ways.

There are obvious pitfalls, such as implementing security only in the client. Then there's the broader issue that Ajax applications are almost always written in at least two languages--JavaScript for the client, as well as whatever language is running on the Web server. As always, complexity is inversely proportional to security.

Finally, entirely new classes of vulnerabilities are only now being discovered, and this trend will likely continue as more scrutiny is brought to bear on the difficult problem of running applications in such a disadvantageous--securitywise, anyway--configuration (see "Reports of InfoSec Demise Greatly Exaggerated").

Tough Row To Hoe

There's been some healthy debate recently about the value of penetration testing, but the fact remains that scanning applications and networks for vulnerabilities is a productive way for an organization to decrease risk.Conventional vulnerability scanners have been around for some time, and even Web application scanners now comprise an established market. What's new, however, is how Web application scanners handle Ajax applications.

Web application scanners have a lot of extra work to do when auditing Web 2.0 applications. First, before checking an application for vulnerabilities, the scanner must exercise all its functions and map or spider every nook and cranny. That's relatively easy to do with conventional applications--Web spiders have been around for some time, and though it's always possible that a spider could take some unintended action, most Web application scanners should be able to restrict particular URLs or subdirectories.

For Ajax applications, however, it's a whole different ballgame. To accurately understand the application and exercise all its functionality, scanners must analyze the JavaScript to know what it's capable of, as well as how it formats and sends data. The scanner must also know how to parse server responses.

Moreover, when scanning Ajax applications, not only must Web application scanners handle the complexity of modeling and analyzing Ajax-specific vulnerabilities, they also must deal with conventional Web application vulnerabilities. Think these older, better-understood vulnerabilities are uncommon?

Nope. Seven in 10 Web sites contain flaws that leave them open to attack, according to a study released in February. As part of a promotion, Acunetix, a Web site security company, provided free scans to 3,200 sites over the course of a year. It found 210,000 vulnerabilities. Although the population sample for this study was self-selecting, participants presumably cared enough about the security of their sites to sign up for a free scan. We expect that the actual percentage of vulnerable sites is at least as high, if not higher. Read more about this study.To top it off, in the midst of all these Web application vulnerabilities, the browser is increasingly the battleground where problems are found. Many successful attacks against Web servers succeed not because the server was unpatched, or even because the application was insecurely written, but because the developer was unaware of browser quirks.

If you're ever in doubt about the seriousness or prevalence of browser bugs, spend an afternoon or two perusing sla.ckers.org and ha.ckers.org, a Web forum and a blog, respectively, where you'll find enough vulnerabilities and exploits discussed and demonstrated that you'll consider permanently disabling JavaScript, Flash, Java, even images, before feeling safe surfing the Web again.

Pick Your Path

OK, so RIAs need locking down. Unfortunately, this isn't as simple as buying an application scanner and turning it loose on your network. Enterprises must choose between multiple options: dedicating an in-house security professional to Web application scanning, manually or with one of the commercial tools we'll be evaluating; purchasing a tool, but placing it in the hands of developers or QA (quality assurance) testers, rather than security staff; or taking advantage of external vendors, going the SaaS (software as a service) route, or with custom external consulting.

Throughout the course of this Rolling Review, we'll evaluate not only the applications and how they perform from the perspectives of a dedicated security tester and a QA tester or developer, but we'll also examine the SaaS options that presumably take all the hard work out of your hands--without the high costs of custom consulting engagements.No matter which road you take, a few best practices--many of which apply to both Web applications and other types of application development--are crucial. These include:

Web application scanners are only one piece of developing secure software. Many of the enterprise versions of the tools we'll evaluate over the course of this review offer integration into workflow tracking systems, developer education programs and other resources. If you're building a ground-up SDLC (software development lifecycle) with a big budget and strong need for security, be sure to consider these options as well (see "Cleaning Up Your Code" at right).

Some organizations will have compliance as a motivation for purchasing a Web application scanner. The PCI-DSS (Payment Card Industries Data Security Standard) specifically requires scans of applications handling credit-card data by a qualified security professional. Although the current version is vague as to whether this needs to be an outside security pro or if the scan can be done in-house, future versions are expected to indicate more clearly that internal auditors, if they have the appropriate skills, will suffice.

No matter your organization's motivation, follow our Rolling Review to see which options best suit your needs.Head Of The Class

One new AJAX vulnerability received a lot of press on April 2, when Fortify Software released an advisory titled, "JavaScript Hijacking." The article is primarily a generalization of a specific vulnerability discovered in January 2006 by Jeremiah Grossman of WhiteHat Security. However, it also covers a large number of Ajax development frameworks that are vulnerable to the attack, and describes what is probably the first general class of vulnerability unique to Ajax applications.

For more details on the advisory, see our blog entry, "Web 2.0 Inherently Insecure?".Reports Of Infosec Demise Greatly Exaggerated

At A Security Conference Two Years Ago, A Programmer Who Worked On One of the first commercial IDSs told us that the security industry was dead, or at the very least dying. Developers were getting serious about writing bulletproof code. Security would be built into all our network protocols from the ground up, and sooner or later, a whole lot of security companies were going to go out of business.

With no end in sight for even "traditional" software vulnerabilities--Microsoft's recent ANI repeat being a perfect example--that prognostication seems even less likely now than it did then. A whole new class of vulnerabilities are being discovered regularly, and application security is getting harder, not easier.Fortunately, there are many good online references for those looking to integrate security into their SDLCs (software development lifecycles).

A discussion of Microsoft's SDLC, for example, is available at "The Trustworthy Computing Security Development Lifecycle" white paper, for more information.

Other useful references include those from the DHS National Cyber Security Division, the authors of "The Art of Software Security Testing", and the SANS Software Security Institute, which recently unveiled a new program to help assess a developer's secure coding knowledge.

And that developer who left the security industry for dead? He stumbled across some intriguing algorithms being used in the academic community and has since started a security company that uses those algorithms to add more intelligence to security products.

Jordan Wiens is an NWC contributing technology editor and a network security engineer at the University of Florida, where he works on IDS/IPS, forensics, vulnerability assessment and system security. Write to him at [email protected].