Cross-Site Scripting-Why filter dangerous strings

Preface not counted as Preface
It seems that I haven't written security questions for a long time.ArticleIn the so-called security circle, you may think that Xuan Mao has disappeared. However, I think Xuan Mao, as a hacker, may have never appeared. That's right. I'm Xuan Mao. If you saw a private security magazine like "hacker XFile" or "hacker manual" two years ago, you may have seen this name.
Or, sorry, sometimes "Xuan Mao, Xuan Mao..." appears on your site ......" I am sorry for this prompt box or text. The vulnerability exploitation tools I wrote have been abused on your website.ProgramClerk and webmaster must be quite a few. I am here to apologize to you too.

What is XSS attack?
OK. Let's go to the text. By convention, I will first give an official definition of "cross-site scripting ".
Cross-Site attack, that is, Cross Site Script Execution (usually abbreviated as XSS), refers to the HTML that attackers use website programs to filter out insufficient user input, and the input can be displayed on the page to affect other users. Code Attackers can steal user information, use user identities to perform certain actions, or perform virus attacks on visitors.
Three key points are mentioned in this definition:
First, what-why is a cross-site scripting attack.
Cross-site scripting attacks are generated because programmers do not consider writing programs well. Of course, they may not consider them at all. There is a famous saying on Security: "Never trust user input ". Here, as a common user, do not despise your distrust of you, as an availability expert, or scold me for not attaching importance to users, as a programmer, you are going to wash your face with cold water, so that you can feel the spirit.
When you wrote a program, did you consider whether the content entered by the user is displayed on the website.
What's the problem? Aside from my cross-site scripting attacks, do you find that sometimes user input leads to page deformation? In this case, in addition to saying, oh, this user is really troublesome. Do you still have to consider why it is distorted.
For example, you wrote a page to display the user input articles. Here, the user part is shown as follows:
<Div id = "content"> <% = sarticlecontent 'Here, we assume that this variable is the user-input article content retrieved from the database %> </div>
If the user inputs the same plain text as I did in this article, then naturally there is no problem, ah, but if there is a user with two knives, he must want to write some HTML code to describe his article, but he just wrote In this example, the user inputs only common HTML characters. What if he inputs JavaScript Characters? Well, if I am a bad user who likes to play pranks, I may enter <SCRIPT> while (1 = 1) {alert ('this webmaster is dump') ;}</SCRIPT>. So what will happen? Yes! When this page is accessed, your innocent visitor will find that no matter how he presses "OK", the stubborn prompt box will chatter.
In short, this is a cross-site scripting attack.
In this attack, I am a bad user who likes pranks and uses you, this will always believe that the programmer entered by the user forgets to filter out the code content that may cause harm to other visitors, and successfully carries out a prank-cross-site scripting attack.
2. Who can use cross-site scripting attacks.
As for the "who" question, I 'd like to give you a general understanding of the above content. Here I will give you a bit more nagging about it, not only users who like prank can use it, but sometimes common users, when you enter the file, you may encounter unexpected issues on the page.
Of course, what we do not want most is that hackers have used this vulnerability. As for how far it can be used, please pull it down, see "what are the dangers of XSS attacks ".
Third, how much-what are the dangers of XSS attacks.
Some "hackers" in the so-called security circles tend to sneer at cross-site vulnerabilities and think that's just a matter of playing around with customers, I think this is a very naive view of a fish student called the cross-site Wang (now a system security engineer at discuz.
However, cross-site attacks can make your page layout messy simply. What's more serious is that hackers can write HTML code, then he can do anything you think of or don't think. For example ...... <IFRAME src = "webpage Trojan address" width = "0" Height = "0"> </iframe> you can easily insert a webpage Trojan on your website. hidden frameworks (often called "Trojan ").
As a website administrator, if you simply think that cross-site vulnerabilities can only cause attacks to visitors, you will be wrong. Don't forget that when you access a webpage with a cross-site attack, your identity is also a common user. On the one hand, if you are in the Trojan, you can easily download the password information from the FTP software. On the other hand, if you have logged on to the Management page, can you create a management page, in addition, it is entirely possible for you to operate as you do without knowing it, and it often appears.
Build cross-site scripting attacks
Haha, if you are a bad user, you will be very happy here. You think you will learn how to be a hacker, but I can only tell you with regret, don't even think about it. Haha, repeat what I often say. The following content is forbidden for immature minors. The content involved is only used for teaching and research, it is strictly prohibited to use the knowledge given here for illegal infringement.
Here I will take out several previous case notes (most of the full text is published in the "xxfile"). I will analyze and explain these cases in this case. Do not underestimate these cases, most of these cases are well-known programs that have been used by a large number of websites on the Internet, which can be imagined as dangerous.
Case 1: WAP Cross-Site vulnerability in the discuz4.1.0 Forum
The discuz Forum allows you to access the Forum through a mobile phone. When you access the Forum through WAP, you can view and send posts and short messages, however, the processing process on the server side does not filter the title of the WAP post, so that we can enter specially constructed characters to cause cross-site attacks.
As a programmer, do you think that when users access the Forum through mobile WAP, they cannot write malicious code to prevent attacks and not process the WAP part? Then you are wrong. In fact, there are a lot of software that can simulate access to WAP, opera can, and use some specific client software (winwap, opera) on the PC to access the WAP website, you can enter cross-site characters. Here, you can enter <SCRIPT> alert ('xss') </SCRIPT> In the title. This code is triggered when a PC user accesses the forum.
In this case, you should learn not to think that the client's restrictions can be neglected to detect and filter user input. As long as you can access the client through the HTTP protocol, no matter what the client is, any restrictions are not safe.
Case 2: Cross-Site vulnerabilities in the "Apsara stack" website diary.
First of all, let's take a look at the Apsara stack diary service. Generally, XSS is a cross-site vulnerability that can be viewed by more than one person, such as a diary. In the following content, we try to use the Code <SCRIPT> alert ("Xuan Mao, Xuan Mao, and Xuan Mao must take the college entrance examination ") </SCRIPT> to test whether our Javascript script can be run on the page.
Open a diary page, first test whether the content can be written into a cross-site script, the diary title is casually written, and the content is written into a <SCRIPT> alert ("Xuan Mao, Xuan Mao, xuan Mao wants to take the college entrance examination ") </SCRIPT>. Then, it's easy to see that the script we wrote is replaced with s second, and (figure 1) there is a space in the middle, try again to change the case sensitivity. Write <SCRIPT> alert ("Xuan Mao, Xuan Mao, and Xuan Mao must take the college entrance examination") </SCRIPT>, it seems that we have to think of a work ing method. Let's look for some other options that can be output. Right, the title, but some friends may have questions. The title should contain 10 words, not enough, we will save the file to the local machine and study form verification: There is a <Form ID = frmannounce name = frmannounce onsubmit = "Return checkform ();" code in row 232, which is not hard to see, the onsubmit function is used to check the number of words in the title. We delete onsubmit = "Return checkfor M (); ", then complete the action, and enter the title in <SCRIPT> alert (" Xuan Mao, Xuan Mao, Xuan Mao must take the college entrance examination ") </SCRIPT>, content can be written and submitted at will. On the page refreshed later, our dialog box pops up elegantly, and the cross-site operation is successful.

In this case, the simplest test content is input, that is, a dialog box is displayed. When the website code is filtered out, the script is tried again, if the programmer simply filters the script, the script may be available, but the final result is still unavailable, then go to the title, obviously, the maxlength attribute is used in the title to limit the maximum number of bytes that can be entered in the text box, And the JS script is used to detect user input. Of course, this is not a problem, we only need to save the page to the local machine, and then we can modify it. After deleting the maxlength attribute and verifying the js code, we can submit it again.
From this case, you should learn:
1. When filtering dangerous characters, check whether the characters can be bypassed by uppercase/lowercase conversion.
2. The validity of user input detected by JS scripts is invalid.
3. The user may directly submit data to the server. Here I tell you that the so-called code that prevents external submissions is absolutely invalid. This method is implemented by detecting the HTTP header of http_reffer, in fact, this HTTP header can also be forged.
Case 3: XSS Vulnerability Phparticle is a full-site article system based on PHP + MySQL. The page is refreshing, fast, and fully functional, in particular, the background has a function to record the wrong password entered when others attempt to log on ...... More practical ...... You can also peek at what passwords are used by others (when a common user tries a password, they always try someone else's password according to their own habits), But I suddenly thought, what if we try to enter special characters in the wrong user name or password ......
Go to the background login page, and then enter the user name and password to write the cross-site code we constructed for testing.
Enter in "User Name:
<SCRIPT> alert ("XSS") </SCRIPT>
Fill in the "password:
<SCRIPT> alert ("XSS") </SCRIPT>
Then, we use the Administrator's password to log on to the background and view "Management logs-> illegal logon records". The first dialog box is displayed. Click "OK" and a second dialog box is displayed, it seems that these two locations have cross-site vulnerabilities.
Okay. Now that we have determined that there are cross-site vulnerabilities, let's take a look at how we can use them to maximize the benefits ...... Here we will use it to enhance the permissions of website users.
It is necessary to introduce to friends who are not familiar with phparticle that the administrator password should be changed in the background to enter the current password, so we cannot use it, I have not come up with a good method for other operations. Now we have to add our registered users to the system administrator Group to improve the permissions.
When we can insert arbitrary code on the page, we have many options, such as inserting Javascript script content, when limiting the number of submitted characters, We can insert a Javascript script file (<SCRIPT src = ""> </SCRIPT> ), you can also insert IFRAME to hide any webpage (hackers use it to mount Trojans). Here, we use the administrator login identity to enhance permissions, therefore, we mimic the user management page of the program to create a page and use the IFRAME method to insert it here.
Now let's take a look at how to construct a form.
Before constructing a form, determine whether this form allows external submissions. After logging in as an administrator, open the member Edit page: http://www.xxx.cn/admin/user.php? Action = mod & userid = 38, save it locally, modify the action attribute of the Form Control, open it, and submit it. The program prompts that the modification is successful, it seems that external submission is allowed (in fact, you can directly look at the code ...... Hey, I'm not lazy ).
Because PA pages are too non-compliant with web standards, JavaScript errors always occur during automatic submission. we construct a form by ourselves and view Source code We can construct a form with only a few required fields, and then add the attribute onload after the body tag, with the value javascript: document. forms [0]. submit (), that is, the form is automatically submitted when the page is loaded.
Here, we also need to pay attention to our userid. We need to use this value when constructing the form. How can we get the userid, we need to find the pauserid value in cookies after logging on.
In this case, we have taken a very "vicious" approach when constructing cross-site exploitation, that is, inserting an iframe pointing to our own webpage. In this webpage, we have completely copied the form part of the original code, modified some content into the operations we need, and finally let the form be automatically submitted.
How to prevent cross-site scripting attacks
I think through the above content, you have deeply understood that the dangers of cross-site scripting attacks are very large, so how to prevent this vulnerability.
The simplest way is to escape the content entered by the user in HTML. In this way, you do not have to consider what content the user inputs and which dangerous characters in the content need to be filtered. For example, in ASP, we can use server. htmlencode () to escape, PHP can use the htmlspecialchars () function.
However, this method cannot be called the optimal solution, which is actually a negative method. Because the content entered by the user may be dangerous, it is escaped. The better method is to replace it with a regular expression. Of course, UBB Code also plays this role. Programmers disable HTML code and replace it with a small number of UBB agreed to replace HTML, to achieve good results.
I will not detail the details of each UBB function because of the length. Here I will list some common cross-site methods that few people know, for your reference, whether these methods have been filtered.

Copy content to clipboard

Code:



(using HTML entities)
(use utf8 Character Set)








(note, expression is very flexible. For example, if you filter the expression, you can also use exp/**/resssion. You have filtered /**/, it can also use exp/* sometext */ression)