Common security flaws and solutions in web development

web| Security | solve

One, can not blindly believe that user input
Two or five kinds of common asp.net safety defects
2.1 Tamper Parameters
2.2 Tamper Parameter bis
2.3 Information leaks
2.4 SQL Injection attack
2.5 Cross-station script execution
Iii. use of automated safety testing tools

Body:

Ensuring application security should start when writing the first line of code, for the simple reason that as the scale of application grows, the cost of patching up security vulnerabilities increases rapidly. According to the IBM System Science Association (Systems Sciences Institute), if you wait until the software is deployed to fix the bug, it costs 15 times times as much to detect and eliminate defects during development.

In order to secure the application with minimal cost, developers should assume more responsibility for the security of the code itself, the ability to resist attacks, and so on. However, to protect the security of the program from the earliest stages of development, you must have the appropriate skills and tools, and there are not many developers who really master these skills and tools. While learning to write safe code is a complex process, preferably in universities, in-house training sessions, industry meetings, but as long as you have mastered the following five common asp.net application security flaws as well as recommended corrective solutions, you can lead a step forward to integrate the necessary security factors into the application of the birth of the time.

One, can not blindly believe that user input

In Web application development, developers most often fail to trust user input unconditionally, assuming that users (even malicious users) are always restricted by browsers and always interact through browsers and servers, opening the door to attacking web apps. In fact, many of the tools that hackers attack and manipulate Web sites do not have to be limited to browsers, from the raw interface of the lowest-level character mode (for example, Telnet) to CGI script scanners, web proxies, Web application scanners, and malicious users who may be using a lot of attack patterns and tools.

Therefore, only rigorously verifying the legality of user input can effectively resist hacker attacks. An application can perform validation in a variety of ways, even with a range of validation scopes, for example, to perform validation before authenticating user input, to ensure that user input contains only legitimate characters, and that the content length of all input fields does not exceed the range (to prevent possible buffer overflow attacks). On this basis, other validation is performed to ensure that the data entered by the user is not only legitimate but also reasonable. When necessary, not only can you take a mandatory length restriction policy, but you can also perform validation on the input according to a well-defined set of features. The following recommendations will help you validate user input data correctly:

⑴ always performs validation on all user input, and validation must be performed on a reliable platform and should be performed on multiple layers of the application.

⑵ do not allow anything else except the data that is required for input and output functions.

⑶ establishes a "trusted code base" that allows data to be thoroughly validated before it enters a trusted environment.

Check the data type before ⑷ the login data.

⑸ defines each data format in detail, such as buffer length, integer type, and so on.

⑹ strictly defines legitimate user requests and rejects all other requests.

⑺ test data satisfies legitimate conditions, rather than testing illegal conditions. This is because there are many cases of illegal data and it is difficult to enumerate them in detail.

Two or five kinds of common asp.net safety defects

Here are five examples of how to enhance the security of your application as suggested above. These examples demonstrate possible flaws in your code, the security risks they pose, and how to rewrite the least code to effectively reduce the risk of attack.

2.1 Tamper Parameters

Using the ASP.net domain validator

Blindly trusting user input is the first enemy to secure Web application. The primary source of user input is the parameters submitted in an HTML form, which can be compromised if the legality of these parameters is not rigorously validated.

The following C # code queries the back-end SQL Server database, assuming that the values of the user and password variables are directly taken from user input:

SqlDataAdapter my_query = new SqlDataAdapter (

"SELECT * from Accounts WHERE acc_user= '" + user +

"' and acc_password= '" + password, the_connection);

On the face of it, these lines of code have no problems, but they can actually lead to SQL injection attacks. An attacker who enters "OR 1=1" in the user input domain can successfully log on to the system, or execute arbitrary shell commands as long as the appropriate invocation is followed by the query:

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

Risk analysis

When you write these lines of code, developers inadvertently make the assumption that the user's input contains only "normal" data-the user's usual custom name, password, but not the special characters such as quotes, which is the root cause of the SQL injection attack to succeed. Hackers can use some characters with special meanings to change the original meaning of the query, and then invoke any function or procedure.

Solution

A domain validator is a mechanism that lets asp.net developers limit the value of a domain, for example, restricting the field values entered by the user must match a particular expression.

To prevent this attack from succeeding, the first approach is to prohibit special character input such as quotes, and the second approach is stricter, that is, the contents of a qualifying input field must belong to a collection of legitimate characters, such as [a-za-z0-9]*.

2.2 Tamper Parameter bis

Avoid a vulnerability to validation actions

However, the introduction of validators for each input domain alone will not prevent all attacks that are implemented by modifying parameters. When you perform a numeric range check, you also specify the correct data type.

That is, when you use the scope of ASP.net to check the control, you should specify the appropriate type property based on the data type required by the input field because the default value for type is string.

<!--require that the input value must be a number between 1-9-->

<asp:rangevalidator ... Minimumvalue= "1" maximumvalue= "9" .../>

Risk analysis

Because no type attribute value is specified, the above code assumes that the type of the input value is string, so the RangeValidator validator 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 way is to specify the type attribute as Integer:

<!--require that the input value must be a number between 1-9-->

<asp:rangevalidator ... Minimumvalue= "1"

Maximumvalue= "9" type= "Integer"

2.3 Information leaks

Make hidden fields more secure

In the ASP.net application, information about the application can be found in almost all __viewstate hidden fields of the HTML page. Since _viewstate is base 64 encoded, it is often ignored, but hackers can easily decode base 64 data, and no effort is needed to get the detailed information __viewstate provides.

Risk analysis

By default, __viewstate data will contain:

⑴ Dynamic Data from a page control.

⑵ the data that developers explicitly save in viewstate.

⑶ the above data to sign the code.

Solution

Set enableviewstatmac= "True" to enable the __viewstate data encryption feature. Then, the machinekey authentication type is set to 3DES, which requires asp.net to encrypt viewstate data with Triple DES symmetric encryption algorithm.

[1] [2] Next page