Are your Web applications secure? Online businesses apps, which are wide open at port 80, put that question to...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the test daily. Developed for functionality with little thought to security, custom apps are typically vulnerable to attacks such as buffer overflow exploits, cross-site scripting and SQL injection.
If companies don't lock down their Web apps, security risks will increase as corporate dependency on Internet and intranet applications rises, along with site complexity, language depth and overall functionality.
The Web apps' exposure to attack is driving the need for developers with both expert application security and deep programming skills. Faced with the need to develop secure applications in the absence of uniform expertise, organizations have two basic options:
- A range of services that employ security development specialists to design, vet and/or troubleshoot applications.
- A growing field of generally immature but promising products that identify security issues both before and after a business application reaches production status.
The evolution toward secure programming languages will alleviate the need for many of the critical bolt-on security packages, but, for at least the next decade, securing applications will remain a complex problem requiring a combination of products, services and education. While there are plenty of choices, there's no one solution.
Securing your applications Learning Guide: App security testing techniques
Using fuzzer tools to find vulnerabilities
Product roundup: New tools to ensure application security
The problem is daunting. No two programmers write the same way, which challenges the security products to deal with highly individualized styles and methods. Web app developers also work in various programming languages, each with its own pitfalls. Compiled languages like C, C++, C# and J# directly access memory and are vulnerable to problems like buffer overflows and format string bugs. Runtime languages--such as Perl, ASP and PHP--fall prey to attackers because developers aren't locking down frontend access (for example, through forms that take names and addresses) to backend database resources. The resulting script errors leave data unprotected against attacks such as cross-site scripting, SQL injection and SQL manipulation.
In general, outsourcing source code reviews to a service provider will be a more expensive proposition than rolling your own using commercial or freeware tools. The service provider route is a more comprehensive approach. Specialists typically conduct a line-by-line app review, which usually takes a lot of time by a highly trained specialist--one reason the outsourcing option is more expensive. A 500,000-line application may take as long as four weeks for two engineers to thoroughly review.
Here are some of the tests you can contract for:
Web penetration tests are analogous to network pen tests. They're no-holds-barred assaults on the app's front-end or user interface. Testers use automated attack scripts or proxy tools like @stake's WebProxy or the freeware Achilles, which lets them manipulate individual requests--modify every field, look at cookies before storing them or alter packets. Web pen tests are aimed at completed, released applications and aren't as comprehensive as code reviews. Testers often don't include code recommendations for identified bugs, though this is increasingly in demand and will likely become standard procedure in cases where source code is provided.
Architectural reviews give organizations the best bang for their buck. An application security guru is brought into the "roundtable" during the design period--giving initial guidance rather than postmortem fixes on the completed app. This proactive approach ensures the product is securely designed and implemented upfront, potentially saving thousands of dollars in corrective action. The designs and reviews should include externally connected applications (databases, media servers), development plans, third-party protection software (firewalls, IPS), external library usage, and discussions of how security should be injected into the software development process.
Managed Web app assessments usually combine network and application scanning technologies. Service providers will typically conduct port and vulnerability scans to get the basic OS design and to understand the environment in which the Web app is set up, then use either proprietary or commercial Web app scanners to detect vulnerabilities.
Automated Solutions on the Rise
The other basic approach to vetting security bugs and vulnerabilities from your custom code is to acquire software that performs the same function as the expensive outsourced consultant. While most of the available solutions are relatively immature and limited in scope, as a group they offer you a variety of ways for testing app security and robustness.
Products fall into four general groups: source code scanners, application scanners, compile-time analyzers and secure development resources. The first three allow programming teams to verify the security of their applications, while the fourth tackles the security of applications from the developer's perspective.
Network scanners like Nessus and Internet Security Systems' System Scanner are frequently used to scan Web apps, but they do little more than look for static attacks, which have little to no chance of being resident in live apps.
Source code scanners are developer and quality assurance tools that identify potentially dangerous functions and methods and can make educated guesses as to the vulnerabilities residing in the app. The newly productized scanners (some consultancies have similar tools they use in their practice) traverse source code trees to identify vulnerabilities with far fewer false positives than their freeware predecessors, such as RATS, Flawfinder and Splint.
Ounce Lab's Prexis scans C, C++ and, soon, Java code. Prexis uses contextual analysis to determine if function calls are correct and secure. For example, it can look at the strcpy() function, whose frequent misuse in C and C++ results in buffer overflows. Prexis flags it as a risky function and determines if its input variables would allow an attacker to cause a buffer overflow.
It also has the ability to "score" a Web app's overall risk. This doesn't help the developer much, but is useful to product and development managers, who can use the scoring to gauge the Web app's security.
Application scanners employ either interface scanning or binary analysis. Interface scanners crawl Web sites, conduct source code sifting to identify potentially confidential information, and determine, for example, the existence of cross-site scripting, SQL injection and directory traversal attacks. They also pound on all user authentication forms with brute-force and dictionary attacks.
While not adept at detecting race conditions or buffer overflows, these tools will detect many common flaws and are critical for testing enterprise Web apps prior to release. AppScan from Sanctum (recently acquired by Watchfire), Kavado's ScanDo, SPI Dynamics' WebInspect and Application Security's AppDetective are leading scanners. Each has a database of Web attacks in addition to multiple signatures for analyzing spidered source code trees and attacking a site's forms.
Cenzic's Hailstorm has a smaller signature database than its competitors, but it also has a top-notch "fuzzer" that applies fuzzy logic to make it extremely proficient at finding buffer overflows.
Binary analysis products are frequently used for final QA by software companies before going GA or by large companies that implement their own commercial-grade proprietary apps. These tools analyze compiled apps' binaries to find potential memory leaks, buffer overflow injection points, format string bugs and race conditions. Products include @stake's SmartRisk Analyzer, HBGary's BugScan and Halvar Flake's open-source BugScam project. Security Innovations plans to introduce a binary analysis product derived from internally developed scripts and tools.
The first compile-time analyzer on the market is Fortify Software's Fortify Source Code Analysis Suite. It can automatically identify nearly 75% of bugs before an app is released, using a mock compiler to look for insecure coding patterns. Fortify's 1,500 trace-path signatures (i.e., rules) look for everything from improper system calls to weaknesses that could allow for SQL injection or race conditions. It can also detect flaws that allow local log forging, which lets an attacker overwrite a log or manipulate data.
Although this tool is one of the best available for post-development code analysis, Fortify is currently limited to C, C++ and Java.
Secure development resources are getting closer to the goal of intrinsically secure programming languages and libraries. The best code security tool is the one you don't need. The market is a long way from bulletproof programming languages, but there has been progress in proactive application security development, led by SPI Dynamics and Microsoft.
Microsoft's .NET framework has a steep learning curve, but shops already developing .NET and C# apps will have fewer vulnerabilities. Buffer overflows are gone, eliminating more than one-third of critical vulnerabilities. Other benefits include privilege management and easily integrated cryptography libraries for data transmission and storage.
SPI Dynamics' SecureObjects suite of Visual Studio .NET objects are easily implemented into new or existing programs. Instantiating these objects allows developers to quickly develop apps because the objects and methods are vetted as secure. SecureObjects shines in terms of verifying user input by automatically blocking or disallowing suspicious characters and known attacks commonly used to bypass authentication forms.
Catalyst Development offers secured socket libraries for use in commercial applications--a tremendous resource considering how many vulnerabilities spawn from receiving malformed network input. These libraries ensure that data fed to apps via the network is parsed into the proper formats and stored where it can be securely accessed during execution.
Mix 'n Match
Selecting the right approach to securing your custom code is a tradeoff. The thoroughness and expertise that comes with service provider contracts also come at a high price per application. Automated app security tools offer a less-expensive alternative, but they come with a different kind of price tag. Many of these tools are still immature and not ready to replace the expertise brought to the table by qualified engineers, but they're definitely worth keeping an eye on.
The best approach to QAing the security of your Web apps involves a mixture of outside services, products and developer education. Contract a service provider for high-end, high-availability, highly visible applications; the money you spend securing the app will pay huge dividends down the line. For smaller apps that have lower security exposure, try the commercial or freeware product route. It just doesn't make sense to spend $100,000 to secure an app "worth" less than $500,000. In these cases, it may make sense to implement the 80/20 rule (20% of the vulnerabilities pose 80% of the risk) by eliminating common vulnerabilities that are exploited by automated attacker tools.
Finally, the fact that we now have more options for identifying coding vulnerabilities doesn't relieve your developers from their responsibility to follow secure programming principles. An ounce of prevention is worth a pound of cure, and your greatest investment should be in the continued education of your quiet, cube-dwelling techies.
About the Author
James C. Foster (firstname.lastname@example.org) is deputy director of global security solution development at Computer Sciences Corp. He was technical advisor for Hacking the Code(Syngress, 2004) and lead author for the upcoming Advanced Security Code Development (Addison-Wesley, 2004 ) and The Ultimate Security Programmer's DeskRef (Syngress, 2004).
This article orginally appeared in Information Security magazine.