TheServerSide.com SearchSoftwareQuality.com TheServerSide Java Symposium TechTarget Application Development Media TheServerSide.NET SearchWebServices.com The Ajax Experience Ajaxian.com SearchVB.com E-Guide Software Testing and Debugging Software Testing and Debugging provides an overview of how to detect and test code performance and security vulnerabilities early in the development cycle; best practices for Web application source code analysis; how to identify and resolve race conditions and other concurrency defects; understand the complex interleavings that exist within multi-threaded applications; implement - ing fundamental secure development practices throughout the SDLC and more. Sponsored By: Software Testing and Debugging Table of Contents E-Guide Software Testing and Debugging Table of Contents: Eight reasons to do source code analysis on your Web application Static code analyzer tests for dangerous race conditions Application security shouldn’t involve duct tape, Band-Aids or bubble gum Resources from Coverity Sponsored by: Page 2 of 15 Software Testing and Debugging Eight reasons to do source code analysis on your Web applications Eight reasons to do source code analysis on your Web application By Kevin Beaver Given the visibility and vulnerabilities that make up many Web applications, I’m surprised to see that the underlying source code isn’t being analyzed. Be it ignorance, lack of budget or anything in between, there’s a lot that can come from performing this exercise in the name of reducing business risks. Here are eight reasons for placing a higher priority analyzing the source code of your Web applications: 1. It’s easy to do Source code analysis sounds very technical and hands-on. Who outside of the techiest of all developers and IT byteheads wants to get involved with something like that? Actually, this difficulty factor is a myth. Once you get analysis tools installed (which happens to be the hardest part I’ve experienced), it’s simply a matter of pointing them to the source files and clicking Go. The tools I’ve used are mature and chock-full of handy features that most anyone can use without expending too much brain power. 2. High benefit and (relatively) low cost I’ve yet to perform a source code analysis where the developers haven’t come back and said, “Oh, I didn’t think of that.” In many cases, the vulnerabilities that source code analysis tools have found wouldn’t have been discovered by developers in a million years but could be exploited at any minute by an attacker. Finding just one vulnerability easily justifies the few thousand dollars you’ll spend on any tools you’ll buy. 3. Web applications are a prime target Think about where Web applications are located. They’re accessible to any and all. Both internal users and external attackers can connect and do bad things—oftentimes even without a valid user account. Contributing to the prob - lem is the fact that most attacks will go unnoticed even with logging enabled and basic log auditing taking place. There’s just too much noise to keep up with. Finally, many Web applications are the entry point to all that makes up the business. There’s so much accessibility and so much to lose. 4. Security is as important as functionality and the user experience It’s funny how so many people—testers, QA engineers, product managers and even upper management—are often involved in making sure software is just right in the eyes of the customer. As long as the software does what it’s sup - posed do, that’s all that really matters. But what about the security flaws that could impact the user on a grander scale? The priorities are shifting slowly, but the “requirement” of secure code is still not where it needs to be. 5. Traditional security testing tools go only so far I’m a firm believer that you’ve got to have good tools to find good vulnerabilities. I’ve also experienced how imper - fect Web application vulnerability scanning tools can be. You often have to manually validate what the tools find and then some. But manual analysis is not going to uncover everything either. That leaves the third and final option— Sponsored by: Page 3 of 15 Software Testing and Debugging Eight reasons to do source code analysis on your Web applications auditing checklists. But we all know how little value those provide. You’ve got to look at the entire attack surface of your Web applications from all possible angles. That includes the source code. 6. Enhanced development processes A nice side benefit of source code analysis is that it will often uncover weaknesses in the software development lifecycle (SDLC) and broader problems with business processes that would otherwise go unnoticed. Plus, security integration earlier on will save time, effort and money for everyone involved. 7. Competitive differentiation A lot of people are talking about source code analysis. I don’t buy into vendor hype, but I do listen when end users start talking about issues such as this. Apparently the need is growing. A lot of security assessment work is the result of a third party -- be it a customer, auditor or business partner—asking for an independent view of software vulnerabilities. When the time comes for someone to ask, “How do I know your software is secure?” it will pay to have a good response and perhaps a source code analysis report to share with him. 8. Compliance as a side effect Be it meeting service-level agreements (SLAs), internal policies or the mish-mosh of industry and government regu - lations we’re all up against, having higher-quality source code can help businesses meet their compliance and legal requirements. In fact, fixing the vulnerabilities in your Web applications could be the one thing that makes the business compliant or helps it look better on its next audit. Arguably many businesses could benefit from certain financial gains as the result of growing the customer base, building trust and loyalty, and putting out more and more software. Those benefits come when they root out Web security problems where they often begin—in the source code—and create more secure and higher-quality software. Consider giving source code analysis a whirl. Most tool vendors provide some sort of free trial of their products. It won’t hurt to at least try it out to see what’s uncovered. It may end up being the best thing you do to improve software quality and minimize security risks for some time to come. About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has more than 19 years of experience in IT and specializes in perform - ing information security assessments revolving around IT compliance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He’s also the creator of the Security On Wheels series of audiobooks. Sponsored by: Page 4 of 15 UNDETECTED DEFECTS LURKING IN YOUR CODE CAN PROVE DISASTROUS FOR YOUR BUSINESS. Hidden bugs in your valuable source code can have serious consequences for your software—countless patches, drops in customer satisfaction, product recalls or worse. You need to know all your code is clean. Coverity offers advanced source code analysis products for the detection of hazardous defects and security vulnerabilities. Catastrophic errors are identified immediately as code is written. Assuring the highest possible code quality—no matter how complex your code base. This allows your developers to spend less time searching for bugs and more time adding value to your product. Your code is either coverity clean—or it’s not. Ceratitis Capitata, or Medfly Unchecked, crop damage estimated at $821 million. Electron Micrograph, 80X © 2008 Coverity, Inc. All rights reserved. © 2008 Coverity, Software Testing and Debugging Static code analyzer tests for dangerous race conditions Static code analyzer tests for dangerous race conditions By Colleen Frye Testing for race condition defects in code is like looking for the proverbial needle in the haystack, according to Ben Chelf, chief technology officer of Coverity Inc. “You might see something strange, but you may not see the same behavior twice in row, and you don’t have complete control of the system, even in the test lab.” Now, with new concurrency defect detection capabilities in the Coverity Prevent SQS static code analyzer, develop - ers will be about to identify race conditions and other concurrency defects earlier in the development cycle, before it gets to test, according to the company. With the advent of multi-core hardware, developers are being pushed to develop multi-threaded applications. In multi-threaded applications, race conditions occur when two threads are trying to access the same data at the same time, which can corrupt the data. “Developers need to develop with multiple threads to take advantage of multi-cores,” Chelf said. “With single-core, it was less critical for developers to think multithreaded development. With single-threaded programming, the developer has complete control over what happens—they can see every condition and determine what will happen when you run a program.” With multithread there’s a combination of what’s happening in code, but it’s also dependent on the platform operating system where the code is running. The operating system starts making decisions for you; it schedules the thread. If the program is not designed well, it can make the program behave differently depending on what the operating system does with the threads, Chelf said. So while testers can exercise the system to look for race conditions, “it’s almost impossible to test for all the paths in the code and interleaving threads, and developers don’t have control over how threads are to be scheduled,” Chelf continued.