Also talk about cross-site scripting attacks and defense

Cross-site scripting attacks and defense Article However, as the attack technology advances, the previous views and theories on cross-site scripting attacks cannot meet the current attack and defense needs, in addition, due to this confusion about cross-site scripting, many Program Including the current dynamic network, there is a problem of loose filtering of Cross-Site scripts. I hope this article will bring some ideas for writing programs and researching programs.
First, let's look at the cause of the cross-site scripting vulnerability. The so-called cross-site scripting vulnerability is actually a problem of HTML injection, malicious user input is not strictly controlled and enters the database and is finally displayed to the visiting user. As a result, attackers can execute HTML as a browsing user in the browser of the visiting user. Code The data process is as follows:

Malicious user HTML input ----> web program ----> enter database ----> web program ----> user browser

In this way, we can clearly see how HTML code enters the victim's browser. We can also discuss cross-site scripting attacks and defense based on this process!
1. What is HTML input?

Here is an example of HTML code.

Many programs eventually convert user input into this form. As you can see, <> indicates that the browser is an HTML Tag, IMG indicates the name of the HTML Tag, Src indicates the first attribute of the tag, and = indicates the value of this attribute, the width following is the second attribute, and the onerror is the tag's event attribute. As you can see, an HTML Tag contains many elements. It is not in the traditional sense that only input <> can inject HTML. In fact, as long as your input is in the HTML tag, when new elements or attributes are generated, cross-site scripting is implemented! In fact, most of the hidden cross-site scripting attacks do not need to <>, because the UBB tag now puts you in the HTML tag, which is very interesting, isn't it?

2 Where is the source of evil?

Since our goal is to introduce code to execute in the browser of the target user, let's see where HTML code can be introduced! If you can introduce it without restrictions, it is obvious that you can fully manipulate an HTML Tag, such as <SCRIPT> alert ('xss') </SCRIPT>, this is absolutely not allowed for security-pursuing programs, so the first thing to convert is <>, through the following code:

Filter code:
Replace (STR, "<", "<")
Replace (STR, ">", "> ")
Well, you may not be able to construct your own HTML Tag. What if you use an existing attribute? The following code can still work well:

Because many HTML markup attributes support the form of javascript: [Code], it is very good. Many programs realize this and may make the following conversions:

Filter code
Dim re
Set Re = new Regexp
Re. ignorecase = true
Re. Global = true
Re. pattern = "javascript :"
STR = Re. Replace (STR, "javascript :")
Re. pattern = "jscript :"
STR = Re. Replace (STR, "jscript :")
Re. pattern = "VBScript :"
STR = Re. Replace (STR, "VBScript :")
Set Re = nothing

As long as you find that JavaScript and other script attributes are filtered out, the loss of the script code will not work! Is this perfect? In fact, the value of the HTML attribute is represented in ASCII format instead of the attribute. For example, the code above can be changed to the following:

The code is executed again! It seems that you have missed something. Add this code!

Replace (STR ,"&","&")

All right, & lost its original meaning. Users cannot represent HTML attribute values in other ways! Wait, can such filtering be believed? As long as you find this keyword filtering mechanism, it is a simple problem:

No JavaScript keywords! Note that the tab key is in the middle! The keyword is split! This is a very troublesome issue. Many people forget these special characters! Some people want to filter spaces. Let's look at other things before filtering! Maybe the src attribute we are currently in cannot be used, but we can still generate our own property or event mechanism! You can still execute HTML code. First, let's talk about the event mechanism:

In this way, the code can still be executed! Understand what the problem is, isn't it? Some programmers seem to understand that what I'm talking about is that the mobile network is a typical example. Isn't the event attribute onerror required? Many people start to use regular expressions, and find that the key words such as onerror will be converted or prompt the user not to execute. Is there no chance?
Of course not. An event is just a way to run the code instead of all. If you can define an event, you can implement your own attributes. Try the following:

Oh, it's still executed! After keyword filtering, someone finds that spaces are used to separate attributes. Well, they are blocking spaces (many people think this way, haha )! Is it a common method to convert spaces into spaces? Yes? You can even make other people unable to split keywords. Don't be too confident. Try the following code to see how:

Hey, good work! It seems that the annotation in the script will be expressed as a blank space! What should we do? What we mentioned above seems to have been conducting passive attack defense all the time. Why didn't we grasp his source? Where is the problem? Where is the problem!

3 Essence

The above problem seems to be essentially a thing, that is, the user goes beyond the tag where the user is located, that is, the obfuscation of data and code. The way to deal with such obfuscation is to limit supervision, this allows users to perform activities in a safe space, which may be known through the above analysis, after filtering out the characters that everyone can kill, users can put their input in the output between "". The general programs do this now, for example, it will be converted into This is a good security habit, then? It is necessary to put user input in a safe field. This can be achieved by filtering user input "", but do not forget that the label itself is not safe, if spaces and Tab keys are filtered out, you don't have to worry about keywords being split. Then, you can use the methods mentioned in the article to filter out the script keywords. Finally, you can prevent users from skipping the check in this way, switch out!

4. Confusion

As you can see from the token mentioned in the article, data conversion and filtering can be performed in three places. When receiving data, data can be converted, it can be converted when you enter the database, or when you output data, but where is the confusion? One problem has to be solved is that many programmers are reluctant to make such a huge application sacrifice for security. Security is costly. For example, the current mailbox is unwilling to discard HTML tags, because it is necessary to support multi-resource and colorful pages, they focus on the nature of xss ids detection, as long as they find insecure things will be converted, but the attack is unpredictable, beautiful things are always fragile and restricted, so someone will definitely get bored. This article has no technical skills. I just hope that the security script staff can better understand XSS and cross-site scripting. It is not that simple!