Understanding the nature of Web application security issues

Transfer from http://blog.csdn.net/iwebsecurity/article/details/1688304

I believe that we have heard more or less about various Web application security vulnerabilities, such as: cross-site scripting attacks (XSS), SQL injection, upload vulnerability ... Various.
Here I do not deny the various naming and classification methods, nor the reasonableness of its naming, I would like to tell you that all kinds of security loopholes, in fact, the nature of security problems are often only a few. I personally attributed the security nature of Web applications to the following three parts:
1. Input/output verification (input/output validation)
2, role verification or certification (role authentication)
3. Ownership verification (Ownership authentication)
Speaking of which, readers must wonder what my three classifications have to do with various security issues. Here I give you a summary of the answers:

Input/Output verification
The input and output here is actually in the user interface (users Interface) this level, such as: You submit a registration information on a site, often receive a lot of tips: "Illegal user name", "name can not use English" ... This is actually an example of input validation.　What is the output?　For example, after you successfully submit a registration information, the system will return a confirmation page (registerred confirmation), often on this page will be displayed when you register to submit some or all of the information, then the information shown here is one of the output instances I said, input need to do what verification? If you enter in the Address field at the time of submission: <script>alert ("iwebsecurity"); </script&gt, what happens when you arrive at the registration confirmation page? If the confirmation page does not have output validation processing, it is clear that a JavaScript-typed cue box will appear when the confirmation page arrives. This is actually a small example of a cross-site scripting attack. Of course, the simple input/output verification involves the face can be able to write a small book, efforts in the follow-up article to explain.

role verification or authentication
Let's take csdn for example, the user has these roles: one can be said to be a tourist, that is, the browser is not logged in the role of the second is a free registered users , perhaps in the future csdn in-depth development, business has been updated, there will be fees for registered users. These are just user roles, and there will be administrator roles within the CSDN company, as well as the possibility that administrators can be divided into different roles depending on the plate.　You see, the csdn you visit every day may have a total number of roles?　The next question is the question of permissions, why do they have a role? is to control the permissions. Each role has its own specific and public permissions, the logical relationship of these permissions is quite complex, and if a Web application does not have a detailed and reasonable design in the role, it will bring untold pain and trouble to the developer. Now I want to ask a few questions: can you guarantee that each character can only do its part? How do you make sure of it? Is the method reliable? Any loopholes?　...... That's what I'm talking about. Role verification or authentication. BTW: Why do I say verification or certification? You can understand that the character exists in two stages, one entry stage, such as the moment you log in, you enter a specific role, and the other phase is the maintenance phase, how do you ensure that you always log in as the identity of the operation? The former can be said to be: certification, the latter is verified. (A little wordy?)
Give a role authentication/verification of the virtual case, such as: an online movie service provider, will give you a free trial role, if the trial role of improper authentication, may result in user rights promotion and become a legitimate fee users, and this fee users you often do not receive any of his fees.

ownership validation
The existence of this problem is also role-based, except that it is concerned with permissions issues between roles at the same level. Take csdn For example, I am a free user of csdn, and so are you. Now the question is: can I do it for you, can I post it for you? Can I change your personality settings? If not, how is csdn implemented? Although you and I are ordinary users, but you have your privacy I also have my privacy, how to ensure strict ownership verification is particularly critical. It's easy, that's what I call ownership verification.

I can confidently tell you that as long as it is a Web application security problem, it can not escape in these three parts, you may not be able to put all kinds of web application security issues and these three sections corresponding and reasonable explanation, but there is only such a simple number of parts

Interpreting the nature of Web application security issues