XSS Attack and Defense

There have been articles on cross-site scripting attacks and defense on the Internet, but with the advancement of attack technology, the previous views and theories on cross-site scripting attacks cannot meet the current attack and defense needs, and due to this confusion in understanding cross-site scripting, as a result, many programs, including the current dynamic network, have the problem of loose filtering of Cross-Site scripts. I hope this article will bring some ideas for writing programs and research 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 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.

The following is a reference clip:

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:

The following is a reference clip: 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:

The following is a reference clip:

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

The following is a reference clip: 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 following is a reference clip:

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

The following is a reference clip: 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:

The following is a reference clip:

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:

The following is a reference clip:

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:

The following is a reference clip:

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? Even