Guarding against guided attacks

By Peter Coffee  |  Posted 2004-12-13 Print this article Print

Developers may also fail to understand the demands of application configuration management when the enemy is not mere chaos but an actively guided attack. Developers may feel that theyre doing their job, for example, by carefully maintaining a traceable record of application versions, while failing to appreciate the open book that an older and insecure version of an application may provide to a successful snooper.

"Configuration management for Web-based applications is terrible, by and large," said Denim Groups Cornell. "In a file-based application environment, people will leave an old file in place and just rename it."

A current application may now be much more securely designed, but an earlier version—perhaps accessible in a poorly secured archive—may give an attacker all the information needed to overcome that improvement.

Death before disclosure

One of the notable positive trends in application development is increasing attention to data validation, in rigorous terms, at every stage of application function.

"You need a validation function for everything that comes in," said Adam Kolawa, co-founder and CEO of Parasoft Corp., in Monrovia, Calif. "And that represents a security policy."

Makers of coding aids, including Parasofts Jtest and Agitator Software Inc.s Agitator, have joined in urging developers to adopt the conservative doctrine of test-first development. This approach defines every aspect of application behavior by an explicit test that is intentionally failed—to ensure that its catching the possible problem—before the code thats needed to pass that test is added to a work in progress.

Typically, one of the language constructs thats used to strengthen an application in this way is an exception-triggering test that fires if data is other than whats expected. However, this can backfire, so to speak, on the developer.

"The first thing crackers do is try to put the application into a funny state and see what it prints," said Parasofts Kolawa. "Whenever you throw any exceptions, make sure that you control the information thats sent up—not just print the entire stack trace."

The border of validation must also be pushed further outward, Kolawa said, because applications rely on external logic components such as XML parsers. Older parsers, or parsers built on open-source foundations and optimized for particular tasks, may be vulnerable to "XML bombs" (sometimes called SOAP bombs to reflect their abuse of Simple Object Access Protocol mechanisms). These attacks overwhelm a machine with a carefully malformed data structure that essentially explodes into a hugely resource-consuming result as its processed on its way into an application.

The effect may be as benign, relatively speaking, as a simple DoS (denial of service) attack. A more carefully constructed attack may create a specific buffer-overflow state in which malicious code can be inserted to hijack an entire system. XML-level protection must therefore become part of the development teams arsenal. Relevant products include the Reactivity Gateway appliance from Reactivity Inc. and the Forum XWall from Forum Systems Inc.

Whatever the battleground, warned Kolawa, its essential as a matter of developer productivity to place the emphasis on prevention rather than detection. "These are very well defined, logical errors," he said. "You can fix them, but its better practice to prevent them. Finding errors is very difficult to do—its difficult to inject something and see where it comes back. Its easier to prevent it."

Next Page: Hiding problems is not prevention.

Peter Coffee is Director of Platform Research at, where he serves as a liaison with the developer community to define the opportunity and clarify developersÔÇÖ technical requirements on the companyÔÇÖs evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter companyÔÇÖs first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel