Input verification-avoid 50% (only experience) and above 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 ", it can solve more than 50% of enterprise application security attacks (only experience values, which 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
It is the process of verifying the legitimacy of the data from the client on the server (emphasizing that it is the server rather than the client) based on the needs of the business logic. Let's first look at the relationship between the two most familiar security attacks and the inputs.
Example 1: XSS (Cross-Site Scripting). 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 cross-site scripting reflection attack. The process is as follows: the string <script> alert % 2812345% 29 <% 2 Fscript> is sent to the server through an HTTP request. After processing the service logic, the server returns to the browser, because the code is not correctly encoded after the return, it is executed by the browser on the client.
Example 2: SQL Injection (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 like this. The prototype of the string admin % 27 + or + % 271% 27% 3D % 271 is: admin' or '1' = '1, this is obviously implemented by guessing the background Implementation of the application. Assume that the background program implementers assemble user input into the SQL query statement for SQL query, as a result, hackers can easily inject self-compiled SQL statements, cheat the login authentication logic, and successfully log 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) whether the value contains only letters and numbers in the background. If the preceding conditions are fully met, perform further business logic processing. 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 (for example, an HTTP web application) 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. If you are interested, I will show you in the next article the series of blog articles "using browser rendering (HTML/JS/CSS) principles to fundamentally solve XSS problems, I believe that there are many different solutions to completely solve XSS problems than you think. (Http://www.testfire.net is an experimental platform, it is not a real application, you can do a security vulnerability on the experiment without touching the law.