Detailed analysis of cross-site scripting attacks and defense

Www.2cto.com: Old article

The following articles mainly describe the cross-site scripting attack and defense. On the Internet, there was a text about cross-site scripting attack and cross-site scripting defense, however, with the continuous development of attack technology, the previous views and theories on cross-site scripting attacks cannot meet the current attack and defense needs, and because of this confusion about cross-site scripting .....

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 visitor. As a result, HTml code can be executed as a browsing user in the browser of the visitor. 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 the user can introduce it without restrictions, it is clear that he can fully manipulate an Html Tag, such as this form, which is absolutely not allowed for security-pursuing programs, so the first thing to do is to <> use 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 the form of & # ASCii rather than the attribute itself. For example, the above Code can be changed to the following:

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

Replace (str, "&", "&") line, & lost its original meaning, the user cannot represent the Html attribute value 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:

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!

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, [img] http://www.loveshell.net [/img] will be converted into this is a good safety 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, the last step is to prevent the user from passing through the check in the form of & # and switch it out!

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, therefore, they focus on the nature of xss ids detection. As long as they discover insecure things, they will convert, but the attack is unpredictable. Beautiful things are always fragile and limited, someone will be sorry. 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! The above content is a detailed analysis of cross-site scripting attacks and defense, and I hope you will gain some benefits.