Author: BIBI
Whenever we think of hackers, a hacker is often like this: a lonely person who quietly enters other people's servers to destroy or steal other people's secret information. Maybe he changes our homepage, or even steals customers' credit card numbers and passwords. Additionally, hackers can attack customers who visit our website. At the same time, our server also became his accomplice. Microsoft calls this attack a "cross-site scripting" attack. Most of these attacks occur when the website dynamically generates web pages, but the hacker's target is not your website, but the customers who browse the website.
Description of cross-site script attacks
In a magazine called ＜＜ADVISORY CA--2000-02＞＞, CERT warns everyone: If the server does not effectively verify the customer's input, the hacker will enter some malicious HTML code , when these HTML code input is used in SCRIPT programs, they can use it to cause damage, such as inserting some disgusting pictures or sounds, etc., and at the same time, it can also interfere with customers' correct browsing of the web page.
We know that some friends have been induced to some suspicious free websites, and all they got were 10 to 20 small windows. These windows are often accompanied by invalid buttons generated by JAVA or JAVASCRIPT. This is called a mouse trap. Closing these windows is in vain. Every time we close a window, 10 more windows will pop up. This situation often occurs when the administrator is not available. Mouse incidents are a typical example of hackers using cross-site SCRIPT methods to attack customers.
Malicious tags and scripts are not just pranks, they can even steal data and corrupt systems. A smart or even not-so-smart hacker can use SCRIPT to interfere with or alter data input to the server. SCRIPT codes can also be used to attack customer systems and completely damage your hard drive. And you have to know that while you are using the server, the hacker's SCRIPT is also running in a safe place on your server! If customers trust your server, they will also trust malicious SCRIPT code. Even this code comes from the hacker's server in the form of <SCRIPT> or <OBJECT>.
Even using a firewall (SSL) cannot prevent cross-site SCRIPT attacks. That's because if the device that generated the malicious SCRIPT code also uses SSL, our server's SSL won't be able to identify the code. Are we just going to hand over the website that our customers once trusted so much to hackers? And the existence of this kind of destruction will completely damage the reputation of your website.
1. Cross-site SCRIPT attack example:
According to CERT information, dynamic input generally has the following forms: URL parameters, table elements, COOKISE and data requests. Let us analyze this website with only two pages, the website name is: MYNICESITE.COM. The first page uses a form or COOKIE to obtain the user name:
＜%@ Language=VBScript %＞
＜% If Request.Cookies("userName") ＜＞ "" Then
Dim strRedirectUrl
strRedirectUrl = "page2.asp?userName="
strRedirectUrl = strRedirectUrl & Response.Cookies("userName")
Response.Redirect(strRedirectUrl)
Else %＞
＜HTML＞
＜HEAD＞
＜TITLE＞MyNiceSite.com Home Page＜/TITLE＞
＜/HEAD＞
＜BODY＞
＜H2＞MyNiceSite .com＜/H2＞
＜FORM method="post" action="page2.asp"＞
Enter your MyNiceSite.com username:
＜INPUT type="text" name="userName"＞
＜INPUT type="submit" name= "submit" value="submit"＞
＜/FORM＞
＜/BODY＞
＜/HTML＞
＜% End If %＞
The second page returns the user name to welcome:
＜%@ Language=VBScript %＞
＜% Dim strUserName
If Request.QueryString("userName")＜＞ "" Then
strUserName = Request.QueryString("userName")
Else
Response.Cookies("userName") = Request.Form("userName")
strUserName = Request.Form("userName" )
End If %＞
＜HTML＞
＜HEAD＞＜/HEAD＞
＜BODY＞
＜H3 align="center"＞Hello: ＜%= strUserName %＞ ＜/H3＞
＜/BODY＞
＜/HTML＞
When you normally When typing text, everything works fine. If you enter the Script code: ＜SCRIPT＞alert('Hello.';＜/script＞, the JavaScript warning label will pop up:
the next time you visit, this warning label will also appear; this is because the Script code is It's already in the cookie when you first visit. This is a simple example of a cross-site attack.
If you think this is a special case, you might as well look elsewhere on the Internet and try it yourself. . I have tested some large government websites, educational websites, and commercial websites, and some of them do have the above situation. I even found that the website where I often use credit cards does not filter the input. , it’s really scary to think about.
Whenever we think of hackers, a hacker is often like this: a lonely person who quietly enters other people’s servers to destroy or steal other people’s secret information. Maybe he will change our homepage. , or even steal customers' credit card numbers and passwords. In addition, hackers also attack customers who visit our website. Microsoft calls this attack a "cross-site script" attack. . Most of these attacks occur when the website dynamically generates web pages, but the target of the hacker is not your website, but the customers who browse the website.
The description of cross-site script attacks
is in a book called ＜＜ADVISORY CA. --2000-02>>In the magazine, CERT warned everyone: If the server does not effectively verify the customer's input, hackers will enter some malicious HTML codes. When these HTML code inputs are used in SCRIPT programs, they can Use it to cause damage, such as inserting some disgusting pictures or sounds, etc., and at the same time, it can also interfere with customers' correct browsing of the web.
We know that some friends have been induced to some suspicious free websites, and what they got was only 10. To 20 small windows, these windows are often accompanied by invalid buttons generated by JAVA or JAVASCRIPT. This is called a mouse trap. Closing these windows is in vain. Every time we close a window, there will be 10 more windows. Pop-up. This situation often occurs when the administrator is not present. Mouse incidents are a typical example of hackers using cross-site SCRIPT methods to attack customers.
Malicious tags and SCRIPT are not just simple pranks, they can even steal data and destroy the system. . A smart or even not smart hacker can use SCRIPT to interfere with or change the input of server data. Using SCRIPT code can also attack the client system, and you need to know that while you are using the server. , the hacker's SCRIPT is also running in a safe place on your server! If customers trust your server very much, they will also trust those malicious SCRIPT codes, even if the code starts with <SCRIPT> or <OBJECT>. The form comes from the hacker's server.
Even using a firewall (SSL) does not prevent cross-site SCRIPT attacks. That's because if the device that generated the malicious SCRIPT code also uses SSL, our server's SSL won't be able to identify the code. Are we just going to hand over the website that our customers once trusted so much to hackers? And the existence of this kind of destruction will completely damage the reputation of your website.
1. Cross-site SCRIPT attack example:
According to CERT information, dynamic input generally has the following forms: URL parameters, table elements, COOKISE and data requests. Let us analyze this website with only two pages, the website name is: MYNICESITE.COM. The first page uses a form or COOKIE to obtain the user name:
＜%@ Language=VBScript %＞
＜% If Request.Cookies("userName") ＜＞ "" Then
Dim strRedirectUrl
strRedirectUrl = "page2.asp?userName="
strRedirectUrl = strRedirectUrl & Response.Cookies("userName")
Response.Redirect(strRedirectUrl)
Else %＞
＜HTML＞
＜HEAD＞
＜TITLE＞MyNiceSite.com Home Page＜/TITLE＞
＜/HEAD＞
＜BODY＞
＜H2＞MyNiceSite .com＜/H2＞
＜FORM method="post" action="page2.asp"＞
Enter your MyNiceSite.com username:
＜INPUT type="text" name="userName"＞
＜INPUT type="submit" name= "submit" value="submit"＞
＜/FORM＞
＜/BODY＞
＜/HTML＞
＜% End If %＞
The second page returns the user name to welcome:
＜%@ Language=VBScript %＞
＜% Dim strUserName
If Request.QueryString("userName")＜＞ "" Then
strUserName = Request.QueryString("userName")
Else
Response.Cookies("userName") = Request.Form("userName")
strUserName = Request.Form("userName" )
End If %＞
＜HTML＞
＜HEAD＞＜/HEAD＞
＜BODY＞
＜H3 align="center"＞Hello: ＜%= strUserName %＞ ＜/H3＞
＜/BODY＞
＜/HTML＞
When you normally When typing text, everything works fine. If you enter the Script code: ＜SCRIPT＞alert('Hello.';＜/script＞, the JavaScript warning label will pop up:
the next time you visit, this warning label will also appear; this is because the Script code is It's already in the cookie when you first visit. This is a simple example of a cross-site attack.
If you think this is a special case, you might as well look elsewhere on the Internet and try it yourself. . I have tested some large government websites, educational websites, and commercial websites, and some of them do have the above situation. I even found that the website where I often use credit cards does not filter the input. , it’s really scary to think about it.
Part 2: Preventing Cross-Site Script Attacks.
1. How to prevent servers from being attacked by cross-site scripts.
Fortunately, the technology to prevent cross-site script attacks is becoming more and more perfect. Currently, several methods can be adopted to prevent cross-site Script attacks:
1. Encode the characters of the dynamically generated page.
The first thing you need to do is to encode the characters of the dynamically generated page. You must do this, otherwise hackers will be very vulnerable. It's possible to change your character settings to easily get past your defenses. If our website is an English website, then we only need to set the character encoding to Latin character ISO-8859-1. The specific situation is as follows:
<META http-equiv="Content-Type" content="text/html;charset= ISO-8859-1">
2. Filter and limit all input data.
This is the second method to prevent cross-site script attacks. When logging in, do not allow those special characters to be entered. Therefore, we can add the JAVASCRIPT program to the ONSUBMIT method to complete this function. In this example we limit the input to 15 characters. This prevents the input of longer scripts.
In the book ＜＜Knowledge Base Article QA252985＞＞Microsoft provides a short Javascript program to complete the filtering of input data. We also introduced this code for our example according to the specific situation, such as:
function checkForm() {
document.forms[0].userName.value = _
RemoveBad(document.forms[0].userName.value);
return true;
}
// MICROSOFT'S CODE
function RemoveBad(strTemp) {
strTemp = strTemp.replace(/＜/＞/"/'/%/;/(/)/&/+/- /g,"");
return strTemp;
}
Using this method, you can filter these characters contained in the input:
% ＜ ＞ [ ] { } ; & + - " '( )
3. Use HTML and URL encoding
despite using the above The above-mentioned method of filtering and restricting input is a very important defensive method, but it is still powerless against my email-based attack. Because I put the URL parameters directly in the email. In response to this situation we have to take a more powerful security measure. If we use ASP, it will be relatively easier to solve. Just HTML and URL encode the dynamically generated web pages. For the situation in our example, we made the following changes to the redirect URL in the first input page:
strRedirectUrl = strRedirectUrl & _
server.URLEncode(Response.Cookies("userName"))
In the execution page, we added:
strUserName =server .HTMLEncode(Request.QueryString("userName"))
and
strUserName =server.HTMLEncode(Request.Form("userName"))
Microsoft recommends that all input and output of dynamic pages should be encoded. This should be true even when storing and retrieving data from the database. This way you can avoid cross-site script attacks to a large extent.
To do this, add in Page1.asp:
＜%@ Language=VBScript %＞
＜% If Request.Cookies("userName") ＜＞ "" Then
'redirect if detect the cookie
Dim strRedirectUrl
strRedirectUrl = "page2.asp?userName="
strRedirectUrl = strRedirectUrl & _
server.URLEncode(Request.Cookies("userName"))
Response.Redirect(strRedirectUrl)
Else %＞
＜HTML＞
＜HEAD＞
＜META http-equiv="Content-Type"content="text/html; charset=ISO-8859-1"＞
＜TITLE＞MyNiceSite.com Home Page＜/TITLE＞
＜/ HEAD＞
＜script LANGUAGE="javascript"＞
＜!--
function checkForm() {
document.forms[0].userName.value =
RemoveBad(document.forms[0].userName.value);
return true;
}
//************************************************ ******
//Programmer: NOT ORIGINAL CODE - COMES FROM MICROSOFT
//Code Source: Microsoft Knowledge Base Article Q25z985
//Description: Removes bad characters.
//****************** *****************************************
function RemoveBad(strTemp) {
strTemp =strTemp.replace(/＜/＞/"/'/%/;/(/)/&/+/-/g, "");
return strTemp;
}
//-->
＜/SCRIPT＞
＜BODY＞
＜BR＞
＜H2＞MyNiceSite.com＜/H2＞
＜BR＞
＜FORM method="post"action="page2.asp" onsubmit="return checkForm ();"＞
Enter your MyNiceSite.com username:
＜INPUT type="text"name="userName" width="10" maxwidth="10"＞
＜INPUT type="submit"name="submit" value=" submit"＞
＜/FORM＞
＜/BODY＞
＜/HTML＞
＜% end if %＞
Add the following to Page2.asp:
＜%@ Language=VBScript %＞
＜% Dim strUserName
If Request.QueryString("userName")＜＞"" Then
strUserName =server.HTMLEncode(Request.QueryString("userName"))
Else
Response.Cookies("userName") =Request.Form("userName")
strUserName = server.HTMLEncode(Request.Form("userName"))
End If %＞
＜HTML＞
＜HEAD＞
＜META http-equiv="Content-Type" content="text/ html;charset=ISO-8859-1"＞
＜/HEAD＞
＜BODY＞
＜H3 align="center"＞Hello: ＜%= strUserName %＞＜/H3＞
＜/BODY＞
＜/HTML＞
Now due to this The attack was effectively prevented. After those malicious tags and scripts are encoded, they are displayed in the form of text, as shown below:
We can also add an IIS component to filter all special characters from dynamic input. For those websites that have already been developed, it is very easy to use this method to prevent cross-site script attacks. Our control can intercept the REQUEST target from the ASP page, and can detect the contents of tables, cookies, request strings and programs:
We can also add statistical data to this component by writing log files. Whenever a client enters an illegal character, this component logs its IP address and the time. For details, please see Doug Dean's ＜＜Roll your Own IIS Application on ASPToday＞＞ article.
We only need to take some simple steps to effectively prevent cross-site script attacks. In addition to the three methods mentioned above, Microsoft and CERT also strongly recommend the use of a method they call "sanity check". For example, if there is an input window that only allows the input of numbers, we will limit it to only allow the input of numbers 0-9. The method used by Microsoft and CERT to limit input characters is much better than filtering special characters alone. By taking these steps you can protect the customers who visit your website while they are there.
2. How to protect your browser from hacker attacks:
How to avoid being attacked when you are roaming on the Internet? Microsoft and CERT advise against messing around online. In response to this situation, the author of a column in PC Magazine named John Dvorack gave an interesting answer. He believes this is a premeditated act by Microsoft: to scare Internet surfers into browsing on safe sites such as America Online and MSN.com.
In our example, even if you don't wander around on the Internet, you can't avoid being attacked by hackers online. Ironically, most of the dangers come from the websites we trust most. If you want your website to be trouble-free, you have to not download any dynamic content or any cookies. For details, please refer to your browser's relevant information.
Microsoft also warns you to set your browser's Active Script to a severely restricted state and your email to a severely restricted receiving mode. Be careful when clicking links in emails. For further information please refer to a book called ＜＜Microsoft's Knowledge Base Article Q253117＞＞. Just in case, you'd better have more experience online and be careful at all times.
Conclusion
If you are a former UNIX programmer, you may not know what cross-site scripting means. You know that the user name and password for administrators of many sites to log in are root and root respectively. Similarly, the name and password of many database administrators are sa and password respectively. You also know Webzine (such as Phrack and Alt2600). The methods they provide can let you know the weaknesses of a certain server step by step. On this kind of hardware, you also know that many website database servers and web servers do not protect themselves. Once it encounters a hacker, the machine will be paralyzed.
Although it is easy to take steps to protect our systems from hackers, our systems are always exposed to hackers. There is every reason to believe that some new security vulnerabilities will emerge over the next year. A paper completed under the guidance of Mr. John Howard of CERT Company mentioned: "According to current research, every website with a domain name on the Internet is attacked by hackers at least once a year on average."
For servers Even just one such attack is unbearable. Cross-site scripting attacks are another method hackers can employ. But we can prevent this form of attack from happening as long as we carry out some simple processing mentioned above.