ASP. NET Common Security Defects

Author: yanglilibaobao ()
Application assuranceProgramSecurity should be written from the first lineCodeThe reason is simple. With the development of applications, the cost for fixing security vulnerabilities also increases rapidly. According to research by the IBM Institute of systems sciences, fixing defects after software deployment costs 15 times that of detecting and eliminating defects during development.

To ensure the security of applications at minimal cost, developers should take more responsibilities in terms of code security and Attack resistance. However, to ensure program security from the initial stage of development, you must have the corresponding skills and tools, but not many developers can really master these skills and tools. Although it is a complicated process to learn to write secure code, it is best to complete it at university, internal training sessions, and industry meetings, as long as you have mastered the following five common ASP. NET application security defects and recommended correction solutions can take the lead to integrate indispensable security factors into the birth of the application.

1. Do not blindly trust user input
In web application development, the biggest mistake for developers is to trust user input unconditionally. It is assumed that users (even malicious users) are always restricted by browsers and always interact with servers through browsers, this opens the door to attack web applications. In fact, there are many tools for hackers to attack and operate web sites, and they do not have to be limited to browsers, from the original interface (such as telnet) with the lowest level of character mode ), to CGI script scanners, web proxies, and Web application scanners, malicious users may adopt many attack modes and methods.
Therefore, only by strictly verifying the legality of user input can we effectively resist hacker attacks. Applications can perform verification using multiple methods (or even methods with overlapping verification ranges), such as performing verification before authorizing user input to ensure that user input only contains valid characters, in addition, the content length of all input fields does not exceed the range (to prevent possible buffer overflow attacks). On this basis, other verification is performed to ensure that the data entered by the user is not only legal but reasonable. When necessary, you can not only adopt a mandatory length restriction policy, but also verify the input content according to the clearly defined feature set. The following suggestions will help you verify user input data correctly:
(1) Verification is always performed on all user input, and the verification must be performed on a reliable platform and on multiple layers of the application.
(2) do not allow any other content except the data required for the input and output functions.
(3) set up a "trusted code base" to allow complete verification before data enters the trusted environment.
(4) Check the data type before logging on to the data.
⑸ Defines each data format in detail, such as the buffer length and integer type.
Deny strictly defines valid user requests and rejects all other requests.
The condition checks whether the data meets the valid conditions, rather than the invalid test conditions. This is because the data is not legal and is difficult to list in detail.

Ii. Five common ASP. NET security defects
The following five examples illustrate how to enhance the security of applications according to the above suggestions. These examples demonstrate possible defects in the Code, the security risks they bring, and how to rewrite the least code to effectively reduce the attack risk.
2.1 tampering Parameters
◎ Use ASP. NET domain validators
Blindly trusting user input is the first enemy to ensure the security of web applications. The main source of user input is the parameters submitted in the HTML form. If you cannot strictly verify the validity of these parameters, the security of the server may be compromised.
The following C # code queries the back-end SQL Server database. Assume that the values of the user and password variables are directly taken from the user input:
Sqldataadapter my_query = new sqldataadapter (
"Select * from accounts where acc_user = '" + User + "' and acc_password = '" + password, the_connection );
On the surface, these lines of code are no problem, but may actually lead to SQL injection attacks. An attacker can log on to the system smoothly by entering "or 1 = 1" in the user input field, or execute any shell command by adding an appropriate call after the query:
'; Exec master .. xp_cmdshell (oshell command here ')--
■ Risk Analysis
When writing these lines of code, the developer has no intention of making the assumption that the user's input content only contains "normal" data-username words and passwords that meet people's common habits, but it does not contain special characters such as quotation marks, which is the root cause of SQL injection attacks. Hackers can use characters with special meanings to change the query intention and call any function or process.
■ Solution
The domain validators are a mechanism that allows ASP. NET developers to restrict the value of a domain. For example, to restrict that the Domain value entered by a user must match a specific expression.
To prevent such attacks, the first method is to prohibit Special Character Input such as quotation marks, and the second method is stricter, that is, to limit that the content of the input field must belong to a set of valid characters, example: [a-zA-Z0-9] *.
2.2 tampering parameter 2
◎ Prevent Verification Vulnerability
However, the introduction of validators for each input field alone cannot prevent all attacks by modifying parameters. When performing a value range check, you must specify the correct data type.
That is to say, when using the ASP. NET range check control, you should specify the appropriate type Attribute Based on the Data Type required by the input field, because the default value of type is string.
<! -- The input value must be a number between 1 and 9 -->
<Asp: rangevalidator... minimumvalue = "1" maximumvalue = "9".../>
■ Risk Analysis
Because the type attribute value is not specified, the above Code assumes that the type of the input value is string. Therefore, the rangevalidator validators can only ensure that the string starts with a character between 0-9, and "0abcd" is also recognized.
■ Solution
To ensure that the input value is indeed an integer, the correct method is to specify the type attribute as integer:
<! -- The input value must be a number between 1 and 9 -->
<Asp: rangevalidator... minimumvalue = "1"
Maximumvalue = "9" type = "integer"
2.3 Information Leakage
◎ Makes hidden domains more secure
In ASP. NET applications, information about applications can be found in almost all the _ viewstate hidden fields on HTML pages. Because _ viewstate is base64-encoded, it is often ignored. However, hackers can easily decode the Base 64 data and get the details provided by _ viewstate without any effort.
■ Risk Analysis
By default, __viewstate data will include:
(1) Dynamic Data from page controls.
(2) The data explicitly stored by the developer in viewstate.
(3) Signature of the password for the above data.
■ Solution
Enableviewstatmac = "true" and enable _ viewstate data encryption. Then, set the machinekey verification type to 3DES, requiring ASP. NET to use Triple DES symmetric encryption. Algorithm Encrypt viewstate data.

2.4 SQL injection attacks
◎ Use SQL parameter API
As described in the "Tampering Parameters" section above, attackers can insert special characters in the input domain to change the meaning of SQL queries and fool the database server to execute malicious queries.
■ Risk Analysis
Malicious queries may obtain any information stored in the backend database, such as the list of customer credit card numbers.
■ Solution
In addition to the method described earlier-use program code to ensure that the input content only contains valid characters, and a more robust method is to use SQL parameter APIs (such as ADO. API provided by net), so that the underlying API of the programming environment (rather than the programmer) to construct the query.
When using these APIs, the developer can either provide a query template or a stored procedure, and then specify a series of parameter values. The underlying API can embed the parameter values into the query template, then, the constructed query is submitted to the server for query. The advantage of this method is to ensure that the parameters can be correctly embedded. For example, the system will escape the quotation marks to fundamentally prevent the occurrence of SQL injection attacks. At the same time, the quotation marks in the form are still valid characters that can be entered, which is also an advantage of using the underlying API.
Follow these steps to modify the preceding example of "Tampering with Parameters". The result is as follows:
Sqldataadapter my_query = new sqldataadapter ("select * from accounts
Where acc_user = @ user and acc_password = @ pass ", the_connection );
Sqlparameter userparam = my_query.select_command.parameters.add (
"@ User", sqldb. varchar, 20 );
Userparam. value = user;
Sqlparameter passwordparam = my_query.select_command.parameters.add (
"@", Sqldb. varchar, 20 );
Passwordparam. value = password;
2.5 Cross-Site Scripting
◎ Encode data sent externally
Cross-Site s cripting refers to embedding malicious user input into the response (HTML) page. For example, although the following ASP. NET page is simple, it contains a major security defect:
<% @ Page Language = "VB" %>
<Asp: Label id = "label1" runat = "server">
Label text
</ASP: Label>
<Form method = "Post" runat = "server" id = "form1">
Enter feedback here <br/>
<Asp: textbox id = "feedback" runat = "server"/> <br/>
<Asp: button id = "cmdsubmit" runat = "server"
TEXT = "Submit! "Onclick =" do_feedback ">
</ASP: button>
</Form>
<S restart runat = "server">
Sub do_feedback (sender as object, e as system. eventargs)
Label1.text = feedback. Text
End sub
</S response>
■ Risk Analysis
Attackers can use javas Pipeline Code to construct a malicious query. When a link is clicked, javas pipeline will run. For example, the script can be embedded using the following user input:
<S events> alert (events. Cookie)
</S response>
■ Solution
In a dual-layer security system, the browser performs input verification and HTML encoding on outgoing user data displayed on the HTML page to ensure that the browser only treats user input data as pure text, instead of other content with special meanings, such as HTML code and javas pipeline script.
In this example, you only need to add an htmlencode call:
Label1.text = server. htmlencode (feedback. Text)
In this way, the response html stream contains the HTML-encoded version of the content entered by the user. That is to say, the browser does not execute the javas Pipeline Code entered by the user, because there is no "<s pipeline>" mark in the HTML, the characters "<" and ">" entered by the user have been replaced with HTML-encoded versions, namely "<" and "> ".

Iii. Use automatic security testing tools
Due to the constantly changing customer requirements, some organizations need to deploy new applications every three months on average. At the same time, due to the flow of people, developers are expected to develop robust and high-quality code quickly. Although it is necessary to train all developers in code security technology, it is undeniable that tools that automatically detect code security vulnerabilities can also help to quickly develop secure applications.
So far, tools commonly used by developers can only cover specific aspects of functional testing, such as performance testing and bug/fault point detection. Manual check code has many inherent limitations and requires developers to have rich code security experience. Therefore, for writing high-quality applications, application-oriented security and tools for malicious environment downlink are also critical.
To quickly improve the quality and security of applications, the most effective way is to provide developers with a tool to automatically test applications. During the unit test, if the tool detects the security defects of the application and embeds the repair suggestions into the code, the developer can immediately identify the errors in the code, it not only facilitates modification of existing errors, but also helps avoid making the same mistakes in the future and continuously improve the Code's ability to resist attacks.
Conclusion: Web service applications are exploding, and more applications are being launched out of the firewall. The risks of vulnerable Web applications will only increase. At the same time, developers are facing increasing pressure to quickly complete application development before the deadline. Pay attention to the security issues during code writing and Invest necessary resources to prepare for future Web service applications and ensure the high quality of the current applications. Only by taking the right measures from the date of birth of the application to ensure its security can we construct high-quality and secure applications.