Guarantee the security of the application should start from writing the first line of code, the reason is simple, with the development of application scale, the cost of repairing security vulnerabilities is also growing rapidly. According to the IBM's Systems Science Association, the price is equivalent to defects during the development period if the software deployment is repaired after the software deployment.
In order to protect the safety of the application with the smallest cost, the developer should take more responsibility in terms of the security of the code itself, the ability to resist the attack. However, to ensure the security of the program from the development of the initial stage, it is necessary to have the corresponding skills and tools, and developers who truly master these skills and tools are not a lot. Although learning to write a safe code is a complex process, it is best to complete at universities, internal training sessions, and industry conferences, but as long as they have mastered the following five common ASP.NET application security defects and recommended revision programs, they can lead One step, incorporate an indispensable security factor into the birth of the application.
First, can not blindly believe in user input
In web application development, developers' biggest mistakes are often unconditionally trustworthy user input, assuming that users (even malicious users) are always limited by the browser, always interacting through browsers and servers, thus opening the attack web application The gate. In fact, there are many tools for hackers attack and operating the web site. It is not necessarily limited to the browser, from the original interface of the lowest character mode (such as Telnet), to the CGI script scanner, web agent, web application scanner, malicious There are many attack patterns and means that users may adopt.
Therefore, only the legitimacy of the user input is strictly validated to effectively resist the hacker attack. The application can perform verification with a variety of methods (or even a method overlap overlap), for example, verify before approved user input, ensuring that the user input contains only legal characters, and all the contents of all input domains have no exceeding range ( To prevent possible buffer overflow attacks), on this, other validations are performed, ensuring that the data input by the user is not only legal, but also reasonable. It is necessary to take a mandatory length restriction strategy, but also perform verification on the input content in accordance with the characteristic set of clearly defined. The following suggestions will help you verify the user's input data:
(1) Always perform verification on all user inputs, and verify that must be performed on a reliable platform and should be performed on multiple layers of the application.
(2) Do not allow anything else in addition to the data necessary to input and output function.
(3) Setting up the "Trust Code Base", allowing the data to enter the trust environment to perform thorough verification.
⑷ Check the data type before logging in to the data.
⑸ Detailed define each data format, such as buffer length, integer type, etc.
⑹ Strictly define legitimate user requests to reject all other requests.
⑺ Test whether the data meets the legitimate conditions, rather than testing the conditions for non-legal. This is because the data is not legal, it is difficult to list more.
Second, five common ASP.NET security defects
Five examples are given below how to enhance the security of applications as described above. These examples demonstrate the possible defects in the code, as well as the security risks they bring, how to rewrite the minimum code to effectively reduce the risk of attacks.
2.1 tampering parameters
◎ Using the ASP.NET Domain Verifier
Blind trust user input is the first enemy that guarantees the security of Web applications. The main source of users entered is the parameters submitted in the HTML form. If the legality of these parameters cannot be strictly verified, it is possible to endanger the security of the server.
The following C # code query the backend SQL Server database, assuming that the value of the user and password variables are taken from the user input:
Sqldataadapter my_query = new sqldataadapter ("Select * from accounts where ac_user = '" user "" password, the_connection); From the surface, these lines of code are unable, actually may lead Come to SQL Injection Attack. An attacker can enter "OR 1 = 1" in the user input field, or you can perform any shell command as long as the appropriate call is added after the query:
'; EXEC MASTER..XP_CMDSHELL (Oshell Command Here') -
■ Risk analysis
When writing these lines of code, developers have unintentionally assumed this: the user's input content contains only "normal" data - the user name, password, password, password, but will not contain quotation marks. Special characters, this is the root cause of SQL injection attacks. Hackers can use some of the original meaning of the query with some special meaning characters, and then call any function or process.
■ Solution
The domain validator is a mechanism for performing restrictions on the value of the ASP.NET developer to the domain, for example, restricting the domain value entered by the user must match a particular expression.
It is necessary to prevent the above attack behavior, the first method is to prohibit special character inputs such as quotation marks, the second method is more stringent, that is, the contents of the defined input domain must belong to a collection of legal characters, such as "[A-ZA- Z0-9] * ".
2.2 Tampering parameters
◎ Avoid vulnerabilities for verification operations
However, only the import domain introduced into the validator and cannot prevent all attacks implemented by modifying parameters. When performing a numerical range check, specify the correct data type.
That is, when checking the control using ASP.NET, the appropriate Type property should be specified according to the data type required by the input domain, because the default value of Type is String.
■ Risk analysis
Since there is no specified Type property value, the above code will assume that the type of input value is String, so the RangeValidator verifier can only ensure that the string begins between 0-9, "0Abcd" will be recognized.
■ Solution
To ensure that the input value is indeed an integer, the correct way is to specify the Type property as an Integer:
2.3 Information Leakage ◎ Let the hidden domain safer In ASP.NET applications, information about applications can be found in almost all __viewstate hidden domains of the HTML page. Since __viewstate is Base 64 encoded, it is often overlooked, but the hacker can easily decode Base 64 data, you can get the details provided by __viewstate without spending any effort. ■ Risk analysis By default, __viewstate data will include: (1) Dynamic data from page controls. (2) The developer is fully saved in ViewState. (3) The password of the above data is signed. ■ Solution Set EnableViewStatmac = "True" to enable __viewstate data encryption. Then, set the MachineKey Verification Type to 3DES, requiring ASP.NET to encrypt ViewState data with the Triple DES symmetrical encryption algorithm. 2.4 SQL injection attack ◎ Using SQL parameter API As described in the "Tamper Parameters" section of the foregoing, an attacker can insert special characters in the input domain, change the intention of SQL queries, and deceive the database server to perform malicious queries. ■ Risk analysis Malicious query is possible to get any information saved by the backend database, such as the list of customer credit card numbers. ■ Solution In addition to the previously described method - use the program code to ensure that the input content contains only a valid character, another more robust approach is to use the SQL parameter API (such as API provided by ADO.NET), so that the underlying API of the programming environment Cube) to construct queries. When using these APIs, developers or provide a query template, or provide a stored procedure, then specify a series of parameter values, embed the parameter value to the query template by the underlying API, and then submit the constructed query to the server query. The advantage of this approach is to ensure that the parameters can be embedded correctly, for example, the system will transform the quotation marks, fundamentally eliminate the occurrence of SQL injection attacks. At the same time, quotation marks in the form is still a valid character that allows input, which is also an advantage of using the underlying API. According to this idea, modify the examples of the "tampering parameters" part of the foregoing, 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-station script execution ◎ Code the outstanding data Cross-site scripting refers to embed a malicious user input to a response (HTML) page. For example, although the following ASP.NET page is simple, it contains a major security defect: <% @ Page language = "vb"%>
