Security must be established from the moment application coding begins ­ for the simple reason that the cost of fixing a security flaw grows astronomically as the application evolves. A study by IBM's Systems Sciences Institute found that the relative cost of fixing software defects after deployment is nearly 15 times greater than the cost of detecting and eliminating them during development.

In order to secure applications while minimizing costs, vendors are calling on developers to take more responsibility for delivering secure applications that are resistant to attack. However, few developers have the training or tools needed to implement security at the inception of development. While learning to write secure code is a complex process that should be taught in universities, internal training seminars, and industry conferences, understanding the following five common ASP.NET application security flaws and recommended code fixes will give developers a head start on building security directly into applications at their birth.

Never Trust User Input
The cardinal security sin of Web application development is developers' tendency to trust user input. Assuming that users (even malicious ones) are bounded by the browser and will use only the browser to interact with the site leaves the application wide open to attack. Hackers have a rich toolkit of programs that interact and attack sites outside the boundaries of the browser. From the lowest raw/line-mode interface (e.g., telnet), through CGI scanners, Web proxies, and Web application scanners, malicious users have a diverse spectrum of possible attack modes and means.

The only way to counteract hacker attacks is to validate user input. You can perform several, even overlapping, validations. For instance, a program may validate all its input upon reception, to make sure it consists of valid characters, and that no field is too long (potential buffer overflow). Then some routines carry out further validations, making sure that the data is reasonable and valid for the specific purposes for which it will be used. A more fine-grained character set validation may be applied, as well as length restriction enforcement. Following these maxims will help you to properly validate user input:
1.  Always validate all user input in multiple tiers and on a trusted platform.
2.  Validate input to allow nothing other than the functions expected to be input and output.
3.  Set a trusted code base and validate all data before it can enter the trusted environment.
4.  Test each data type before entry (i.e., Web, registry, file system, configuration files).
5.  Define all data formats (i.e., buffer length, integer type).
6.  Define valid user requests and reject all others.
7.  Look for valid, rather than invalid, data.
8.  Never mirror Web input.
9.  Encode or encrypt output.

How to Avoid Five Common ASP.NET Security Flaws
The following five examples will illustrate how to implement these maxims by demonstrating security flaws as they appear in code, the dangers the flaws present, and how to simply rewrite a few lines to greatly reduce the risk of attack.

Parameter Tampering
Using ASP.NET Field Validators
Trusting user input is the number one enemy of secure Web applications. Parameters submitted in HTML forms are a major source of user input; failing to validate these parameters may result in a severe security threat.

The following C# code queries a back-end SQL server (assuming the variables "user" and "password" are taken directly from the user input):

SqlDataAdapter my_query = new SqlDataAdapter(
"SELECT * FROM accounts WHERE acc_user='" + user +
"' AND acc_password='" + password, the_connection);

These few innocent-looking lines of code enable a vicious SQL injection attack. By entering "OR 1=1" in the "user" input field, the attacker can log in to the system as an arbitrary user, or possibly execute shell commands simply by appending the appropriate call right after the query.

'; EXEC master..xp_cmdshell(Oshell command here')--

Danger
The programmer assumed that the user input consists of solely "normal" data ­ real user names, real passwords that do not contain the character O (apostrophe) ­ enabling unexpected characters, such as O to execute SQL attacks. By executing unanticipated SQL queries from the user input, a hacker could call alternate functions or procedures.

Solution
A field validator is a mechanism that enables an ASP.NET developer to enforce restrictions on the field value, for example, specifying that the user input field match a given expression.

In order to block the attack shown above, forbid the apostrophe character either by specifying what is not valid in the field: "[^']*" ­ or better yet, by allowing only alphanumeric characters in the field: "[a-zA-Z0-9]*".

Parameter Tampering Revisited
Avoiding Validation Pitfalls
However, incorporating validators for every user input field will not protect against all attempts to alter parameters. Range validation must also specify the correct data type.

When using the range validator ASP.NET control, keep in mind that the Type attribute must be set according to the type of input field expected, as the Type attribute defaults to "String":

<!-- check for a number 1-9 -->
<asp:RangeValidator ... MinimumValue="1" MaximumValue="9" .../>

Danger
Since no Type is specified, this code will assume "String", meaning that the order is a lexicographical one. Therefore, the validator will ensure only that the string starts with 0­9. Strings such as "0abcd" will be accepted.

Solution
The right way to test for integer range is to specify the type as "Integer":

<!-- check for a number 1-9 -->
<asp:RangeValidator ... MinimumValue="1"
MaximumValue="9" Type="Integer"

Information Leakage
Keeping Hidden Fields Under Wraps
Information about ASP.NET applications can often be found in the __VIEWSTATE hidden field in nearly all HTML pages. Often overlooked because it is Base64 encoded, hackers can easily decode the Base64 data, exposing the __VIEWSTATE data with minimal effort.

Danger
By default, the __VIEWSTATE data consists of: