RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


All Input Data Is Evil—So Make Sure You Handle It Correctly and with Due Care

Neglecting to check all application input to ensure it contains only valid content is simply asking for trouble.

T professionals agree that input is a big source of trouble. Input ultimately determines how applications work and wrong or malicious input may cause serious damage. It is extremely important that developers have this fact firmly in mind and consequently apply adequate countermeasures. Starting from the perspective that all input is evil is a good approach. Reasoning in terms of a whitelist instead of a blacklist is another excellent strategy. Working with strongly typed data is the third pillar of secure applications. This article discusses the role of input data and related attacks in the context of ASP.NET applications.

According to recent statistics, XSS and SQL injection are the most successful and common attacks. These attacks share two key features: they exploit vulnerabilities frequent in Web applications and are favored by bugs and holes in data validation. When designing a serious Web application, therefore, any developers should have clearly in mind that all input is evil, until proven otherwise.

In software as in everyday life, any dangerous items require special care and often some special equipment. What's so treacherous and scary in software that could be labeled as a dangerous item? Code is rarely harmful on its own, because it is (or should be) extensively tested before reaching the production stage. Of course, this doesn't mean that code is always perfect; more simply, it is normally safe to assume that a lot of effort has been made to ensure that the code works as expected. Even after this statement, can one stay quiet and relaxed and let the software run? Unfortunately, no.

The quality and correctness of a piece of software is double-linked to the quality and correctness of the tests it goes through. In the imperfect world in which we live, code normally works except in some statistically irrelevant number of situations. We all call these situations "bugs." Should you consider a bug a dangerous item? I'd say no, although a bug can sometimes have a disruptive effect on the application and any infrastructure or machinery it controls. A bug in a function can lead to a serious crash; but would you say that a function call is dangerous per se?

Instead, input data is a treacherous companion item to most software applications. A piece of software may work correctly, except when it receives certain data. Bad data becomes dangerous only if it starts a flow of execution that ends in anomalies and if you cannot detect and properly handle those anomalies.

Every professional involved with software agrees that input data is a potential enemy and should be handled with extreme care.

All Input Is Evil, Eugene
The importance of software security has grown significantly with the rapid success of Web applications. Anybody can connect to a site and practice entering any sort of data. The site should be safe enough to detect and reject any incongruous data. If this doesn't happen, an otherwise perfect and functioning application starts misbehaving and may eventually cause serious damage.

Over the years, practicing with data on sensitive and alluring Web sites has become a new profession; subsequently, developers had to implant a harsh defense. In general, I assume all input is evil until proven otherwise.

Developers nowadays design most Web applications (and other applications) following this guideline. On this topic, you might want to read about the habits of an authentic guru of security: Michael Howard (see Sidebar 1, "Michael Howard's Secure Habits").

However, some developers are led to assume that any incoming data is in the right format, or in a small number of possible wrong formats. Basically those developers tend to assume that data is correct until proven otherwise. I think a complete turnaround is required to clinch security.

Editor's Note: This article was first published in the May/June 2007 issue of CoDe Magazine, and is reprinted here by permission.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date