News

Rule of secure coding: 'See input as evil'

• By Jack Vaughan
• April 15, 2003

We recently asked security maven Steve Orrin to tell us some of the tenets of secure coding today. While this was once an administrator's main look-see, it has become part of the developer's job in the wake of some high-profile snafus.

Above all, said Orrin, developers should be wary of any program portions that invite input from users. ''The number one thing for developers to realize is that you need to treat input as evil,'' he said.

Orrin, who serves as CTO at security expert Sanctum Inc., said that besides input dialogs, developers should be especially careful when they implement authentication and authorization functions. User input is a ''trust problem.'' If input isn't validated or sanitized, it is trouble waiting to happen, he indicated.

Specifically, insertion of dangerous keyboard characters leads to attacks like cross-site scripting (which often uses JavaScript as its mechanism). Culprits employ cross-site scripting to reflect-back user data from an unwary site to the user's browser where authentication cookie data, for example, can be captured and then sent to the computer culprit's cove. Such tricks could be part of a growing problem known as ''identity theft.''

''It has become a problem because, too often, there is no validation or sanitation of the input,'' said Orrin.

As Microsoft has avowed a new emphasis on secure software, we asked Orrin how the software giant was doing on that front.

''We've seen a significant commitment to improving security by Microsoft, and this has been evidenced in Visual Studio .NET,'' he said. ''Sanctum's security experts have done quite a bit of testing on Visual Studio .NET and have been impressed by several key security enhancements.

''First,'' he said, ''[Microsoft has] made it rather easy to implement signing and encrypting the ViewState. Secondly, with Visual Studio .NET 1.1, Microsoft added a generic validator to help catch many of the Cross Site Scripting (XSS) variants. Finally, one can use the Regular Expression and Range Validators to perform User Input Validation and Sanitation to prevent attacks like XSS, SQL Injection and Buffer Overflow.''

On the Java side, application-level security is still in need of some work, though Orrin noted that Java environments by default have protections against Buffer Overflows.

Orrin noted positive moves in that the Eclipse plug-in bus can more easily support add-ons that handle authentication and authorization.

''But as with much of the Java and open-source world, features such as validation and sanitization are left to the user to 'do-it yourself,''' he said.

Useful Links:
Sanctum Inc.'s AppScan Developer Edition (DE) 1.5 for developers: http://www.sanctuminc.com/solutions/appscan/de/index.html

Writing Secure Code Second Edition by Michael Howard and David LeBlanc on the Microsoft Press Web site: http://www.microsoft.com/mspress/books/5957.asp

Information on encrypting the form ViewState can be found on the ASP101.com Web site at http://www.asp101.com/lessons/viewstate.asp

Information on encrypting the form ViewState can be found on the MSDN.com Web site at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp11222001.asp

For other Programmers Report articles, please go to http://www.adtmag.com/article.asp?id=6265