The gentle killer--Cross station ASP script attack

Attack

Whenever we think of hackers, hackers tend to be such a portrait: A lonely person, sneaking into someone else's server to sabotage or steal other people's secret information. Perhaps he will change our homepage, who will steal the customer's credit card number and password. In addition, hackers will attack customers who visit our site. At the same time, our server has become his accomplice. Microsoft called the attack a "Cross-site script" attack. Most of these attacks occur when the Web site is dynamically generated, but the goal of the hacker is not your site, but the customer browsing the site.

　　Description of cross-station script attack

In a magazine called < >, cert warns that if the server does not validate the customer's input, the hacker will enter some malicious HTML code, when the HTML code input is used for the script program, They can use it to destroy, such as inserting some disgusting pictures or sounds, and also can disturb the customer to browse the Web page correctly.

We know that some friends have been lured to suspicious free sites, and they get just 10 to 20 small windows, often accompanied by invalid buttons generated by Java or JavaScript, called mouse traps. Closing these windows is futile whenever we close a window and there will be 10 more windows popping up. This often happens when the administrator is not there. Mouse events are a typical example of a hacker exploiting a cross-site script approach to attack customers.

Malicious tags and script are not simple pranks, they can even steal information and smash systems. A smart or even smart hacker can use script to interfere with or change the input of server data. The use of script code can also attack the customer system, so that your hard drive loss. And you know, when you use the server, the hacker's script is also running in the safe place of your server! If the customer is very trusting of your server, they will also trust the malicious script code. Even this code comes from a hacker's server in the form of 〈script〉 or 〈object〉.

even using a firewall (SSL) does not prevent Cross-site script attacks. That's because if the device that generates the malicious script code uses SSL, the SSL on our server cannot identify the code. Do we have to hand over to the hacker the website that the customer once so trusts? And the existence of this kind of destruction, will let your website reputation is damaged.

　　Example of a cross-site script attack:

According to Cert's data, dynamic input has roughly these forms: URL parameters, table elements, cookise, and data requests. Let us analyze this, this is only two pages of the site, the site name is: mynicesite.com. The first page uses a table or cookie to get 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%>

mynicesite.com Home Page

mynicesite.com

Enter your mynicesite.com username:

<% 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%>

hello: <%= strusername%>

When you are typing text, everything is normal. If you enter the SCRIPT code: , the JavaScript warning label will bounce out:

The warning tag will also appear on your next visit, because the script code has been left in the cookie after the first visit. This is a simple example of a cross station attack.

If you think this is a special case, you might as well go to another place on the internet and try it out for yourself. I have been to a number of large government websites, educational websites and commercial websites

Go through the test, they do have part of the above mentioned situation, I even found that my regular use of credit card site also did not do any filtering, think it is terrible.

　　Second, use e-mail for cross-station script attack

Cross-site script attacks are particularly easy to use on list servers, Usenet servers and mail servers. The following is an example of the Mynicesite.com Web site. Because you often browse this website, its content also really let you love not fondle admiringly, so unknowingly you change the browser to always trust this dynamic site content settings.

Mynicesite.com websites always earn revenue by selling email addresses that subscribe to their email messages, which is a really bad idea. So I bought one of its email addresses. A lot of emails were sent to you. In the letter I told you to visit this website as soon as possible and to check the latest information on your account usage. I have also made a link in this letter in order to make it convenient for you. I licked the script code in the username parameter in the link URL. Some customers have unwittingly clicked on this link, which means that I have been on my account, and I have benefited from it:

It works like this, and when you click on the link, the script code in the link will guide your browser to download my JavaScript program and execute it. My script checks to see that you are using IE browser, and then start downloading the Acticex control ParticularlyNasty.dll. Since you've previously considered the content of this site to be always secure, my script code and active controls can be run freely on your machine.

　　iii. Description of the ActiveX attack

When discussing ActiveX, neither Cert nor Microsoft mentioned the dangers posed by the Cross-site script approach. The security issue of ActiveX is described in more detail in the << Security FAQ. Java applets are severely restricted in their control of the system. When Sun developed it, it stipulated that only those operations that did not pose a threat to the security of the system were allowed to run.

On the other hand, ActiveX operations on the system are not strictly limited. If one is downloaded, you can do what they want to do like an executable program installed. For this feature, IE browser also made some restrictions, such as for those insecure sites, in its default settings will not allow you to download or will give you warning tips. Companies that are developing based on ActiveX, such as the VeriSign Company, have numbered ActiveX controls. When you download the control, IE will warn you and show you how trustworthy it is. The user decides whether to trust the control. As a result, the security of the system increases.

However, for those users who have little experience, they often unconsciously modify the original settings so that they are downloaded without any hint. In addition, for a novice, even in the case of a hint, you will not be able to download those controls without any markup. In our example, because of your trust in the site, you changed the browser's settings so that the ActiveX control was downloaded without any hint and started to run unconsciously on your machine.

　　Four, 16-encoded ActiveX Script attacks

It is very difficult to distinguish between the labels and the script with bad intentions. The script can also hide itself in the form of 16. Let's take a look at the following e-mail example, okay? It is sent out in the form of a 16:

This is almost a complete message containing a 16-forged URL parameter: sender=mynicesite.com. When the user clicks on the link, the user's browser will immediately start the first example of the processing process and pop-up warning window.

　　Part Two: anti-crime of cross-station script attack

　　first, how to prevent the server from cross-station script attack

Thankfully, the technology to prevent a Cross-site script attack is becoming perfect. There are several ways in which you can now prevent Cross-site script attacks:

1. Encode the characters of dynamically generated pages

The first thing you have to do is code the characters that dynamically generate the page, you have to do this, or the hacker is likely to change your character settings and easily pass your line of defense. If our site is an English site, so long as we set the character encoding into a Latin character iso-8859-1 on the line, the specific situation is as follows:

2. Filter and restrict all input data

This is the second way to prevent Cross-site script attacks, and do not allow those special characters to enter when you log in. So we can do this by adding JavaScript programs to the OnSubmit method. In this case we limit the maximum of 15 characters. This blocks the input from the longer script.

In < >, Microsoft provides a short JavaScript program to filter the input data. We have also introduced this code to our example based on the specific circumstances, 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;

}

In this way, you can filter the characters that are included in the input:

% [] {}; & +-"' ()

3. Use HTML and URL encoding

Although using the filtering and limiting input described above is a very important defense, it has no way of doing anything with my email attack. Because I put the parameters of the URL directly in the message. We have to adopt a more forceful security measure against this situation. If we use ASP, it is much easier to solve it. As long as HTML and URL encoding are always used for dynamically generated Web pages. For the case 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 add:

strUserName =server. HTMLEncode (Request.QueryString ("UserName"))

And

strUserName =server. HTMLEncode (Request.Form ("UserName"))

Microsoft recommends that all dynamic page input and output should be encoded. This should be even in the case of storing and fetching database data. This way you can largely avoid a cross-site script attack.

To do this, add in the 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%>

mynicesite.com Home Page

!--

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;

}

-->

mynicesite.com

Enter your mynicesite.com username:

<% End If%>

Page2.asp In addition:

<%@ 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%>

hello: <%= strusername%>

This attack is now being effectively compromised. When the malicious tags and scripts are encoded, they are displayed in the form of text, as follows:

We can also add an IIS component to filter all the special characters from dynamic input. For sites that are already doing well, it is easy to use this approach to prevent script attacks from across the site. 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 a log file. Whenever a customer enters an illegal character, the component notes its IP address and time. For more information, see Doug Dean's < >.

We only need to take some simple steps to effectively stop the Cross-site script attack. In addition to the three methods mentioned above, Microsoft and Cert also strongly recommend using a method they call "sanity check". For example, if you have an input window that only allows you to enter a number, let's limit it to just 0-9 digits of input. Microsoft and Cert used this method to qualify the input characters much better than a separate filter-specific character. With these measures, you will be able to allow those who visit your site to be protected when visiting your site.

　　Second, from hackers to attack our browser method:

When you roam the Internet, how to avoid attack? Microsoft and cert suggest not to bump into the Internet. In response to this situation, a PC magazine named John Dvorack, the author of an interesting answer. He sees it as a premeditated act of Microsoft: to intimidate people surfing the web into safe sites like AOL and msn.com.

In our example, even if you do not wander on the Internet, you cannot avoid hacking attacks on the internet. Ironically, most of the dangers come from websites that we most trust. If you want to make sure that the site does not go wrong, you have to not download any dynamic content or any cookies. For more information, please refer to the browser for details.

Microsoft also warns you to set the browser's active script to a strictly restrictive state and to set the email to a strictly restricted reception mode. Be careful when clicking on a link in a message. For further information, please refer to a book called < >. Just in case, you'd better have a little more Internet experience and be cautious at all times.

　　Conclusions

If you are a former UNIX program developer, you may not know what a cross station script means. You know that many of the site's administrator login username and password are root,root. Similarly, many database administrators have names and passwords of Sa,password. You also know that webzine (such as Phrack and Alt2600) can provide you with a step-by-step idea of a server's weaknesses, based on the methods they offer. On this kind of hardware, you also know that many Web sites ' database servers and Web servers do not protect themselves. Once a hacker is caught, the machine is paralyzed.

While it is easy to take measures to prevent the system from being hacked, our system has been exposed to hackers. We have every reason to believe that there will be some new security vulnerabilities in the coming year. "According to current research, every site with a domain name on the internet is hacked at least once a year," says a paper published under the guidance of Mr. John Howard, a cert company. ”

For the server that is afraid of just one such attack is also unbearable. Cross-site script attacks are another method that hackers can use. But we can prevent this form of attack simply by doing some simple processing mentioned above.