Web application security issues intrinsically decrypted

I believe we all have heard more or less about various Web application security vulnerabilities, such as: Cross-site scripting attacks (XSS), SQL injection, uploading vulnerabilities ... Various.

Here I do not deny all kinds of naming and classification methods, also do not evaluate the rationality of its naming or not, I want to tell you that all kinds of security vulnerabilities, in fact, the inherent security problems are often only a few. I personally attribute the Web Application Security essentials to the following three parts:

1. Input/output verification (input/output validation)

2. Role verification or authentication (roles authentication)

3. Ownership verification (ownership authentication)

Speaking of which, the reader must want to know what my three categories relate to a variety of security issues? Below I give you one by one the rough answer:

Input/output validation

Here, the input and output are actually in the user interface (users Interface) on this level, such as: You submit a registration information on a site, often receive many prompts: "User name is illegal", "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 show you the registration of some or all of the information submitted, then the information shown here is what I said one of the output instances, input needs to do what validation?

If you are submitting, type in the Address column:

<script>alert("iwebsecurity");</script>

What happens when you get to the registered confirmation page? If the confirmation page does not have output validation processing, it is obvious that a JavaScript-typed balloon will appear when you reach the confirmation page. 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, and strive to in the follow-up article to give you a detailed explanation.

Role validation or authentication

Let's take csdn for example, users have these roles: one can be said to be a tourist, that is, the browser does not log on the role of the second is a free registered users, perhaps in the future CSDN in-depth development, the business is updated, there will be fees registered users. The above is only the user role, that within the CSDN company will also have the Administrator role, there may be administrators can be divided into different roles according to the plate. As you can see, how many roles do you csdn to visit every day? The next question is the permission question, why is there a role? is to control the rights. 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 on the role, it can cause untold pain and trouble to the developer. Now I'm going to ask you a few questions: can you guarantee that each character can only do its job? How are you going to make sure? Is the method reliable? Is there a loophole? ...... This is what I want to say about role validation or authentication. BTW: Why do I say authentication or authentication? You can understand that there are two stages in the role, one that enters the stage, such as the moment you log in, you enter a specific role, and the other stage is the maintenance phase, how do you make sure that you are always logged in as a login when you log on? The former can be said to be: Authentication, the latter is verified.

To a virtual case of role authentication/validation, for example: an online movie service provider, will be free to give you a trial role, if the trial role of improper validation, may lead to user rights to promote and become a legitimate toll users, and this charge users you often do not receive any of his fees.

Ownership verification

The existence of this problem is also role-based, except that it is concerned with the issue of permissions between roles at the same level. Take Csdn to say, I am a free user of csdn, you too.

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. Quite simply, that's what I call ownership verification.

I can confidently tell you that, as long as it is a Web application security issue, it cannot escape in these three parts, you may not be able to make a variety of Web application security issues with the three parts of the corresponding and reasonable explanation, but there are only such a simple few parts.