Input verification prevents more than half of application security attacks

As the saying goes, it can be said that the source of most application security problems is caused by the input entry, but the input entry Security Detection cannot solve all potential security problems, the reason is very simple, that is, when receiving input data, the receiver does not know what the data is used for and what the business logic is involved. Therefore, it is impossible to perform complete and proper security detection and processing at the input entry. However, we still need to emphasize this "but". We cannot ignore it because it cannot solve all the problems here. This article will tell you: well-developed and reasonable "input verification ", 50% is only an experience value and will not be explained later.

Concepts:

1. Input

In the broad sense, "input" is a relative concept relative to the sender and receiver. For HTTP-based web applications, the request packets sent from the browser to the HTTP server are all input, similarly, all data on the request end is input to the server.

2. input verification

The process of verifying the legitimacy of the data from the client based on the business logic needs.

Let's first look at the relationship between the two most familiar security attacks and the inputs.

Example 1: XSS cross-site scripting (XSS). You can try this test link on firefox:

Http://www.testfire.net/search.aspx? TxtSearch = <script> alert % 2812345% 29 <% 2 Fscript>

This is a typical reflection-type cross-site scripting attack. The process is as follows: the string <script> alert % 2812345% 29 <% 2 Fscript> is transmitted to the server through HTTP requests, after processing the service logic, the server returns to the end of the browser. Because the code is not correctly encoded, the server is executed by the browser on the client.

Example 2: SQLInjection (SQL injection attack). You can also test this link on firefox:

Http://www.testfire.net/bank/login.aspx? Uid = admin % 27 + or + % 271% 27% 3D % 271 & passw = admin % 27 + or + % 271% 27% 3D % 271 & btnSubmit = Login

This is a typical SQL Injection problem. The process is as follows. The prototype of the string admin % 27 + or + % 271% 3D % 27% is: admin 'or '1' = '1, which is obviously implemented by guessing the application background, assume that the background program implementers assemble user input into SQL query statements for SQL query, so that hackers can easily inject self-compiled SQL statements, you have cheated the login authentication logic and successfully logged on as an administrator.

There are many input items in the two examples. We only pay attention to the three input points txtSearch/uid/passw, which are the source of these two problems, does input verification make sense? Of course. If our business logic only requires txtSearch/uid/passw, the length of the Input Point only needs 15 characters, and the data type only requires numbers and English letters to meet the product design requirements, then we can do this:

1) The server obtains the txtSearch/uid/passw value.

2) check whether the length exceeds 15.

3) Does the value contain only letters and numbers?

In the background implementation, if the preceding conditions are fully met, further business logic processing is performed. Otherwise, the client is notified of illegal input in a friendly way. Of course, for a better user experience, you can use JavaScript to dynamically prompt the legitimate input that the user can accept on the client side in real time. What are the benefits of doing so?

1) In the first example, if we cause XSS problems due to negligence or unexpected reasons, your restrictions are so harsh that even if there is an XSS problem, it is also difficult for hackers to make good use of it, because there are length restrictions and character set restrictions.

2) for the second example, if we leave SQL Injection security issues due to implementation negligence, it also makes it impossible for hackers to use it for more bad things due to character set and string length restrictions.

The above is just an example of application security issues, such as directory traversal, file upload, buffer overflow, and so on. You can use reasonable and correct input verification methods to reduce, reduce, or even avoid security attacks.

For input verification, individuals divide it into two categories: one is normal string input, the vast majority belongs to this category; the other is support rich text input, for example, edit a document and allow users to enter the entry points of simple tags. For the second type, you can use the AntiSamy (https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project) framework provided by OWASP to help solve the problem.

The last note is that I did not want to express the importance, interests, and significance of all the security problems that can be solved through the above description, I think it is clear. The motto of input validation is: Never trust the input from the client. The input here is not only an explicit user input, but also an implicit Protocol packet.