The gentle killer-Cross station ASP script attack

Author: BIBI

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 tested some large government websites, educational websites and commercial websites, and some of them do have some of the above, and I've even found that websites that I use credit cards with are not filtering any of the input, so it's scary to think.

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 tested some large government websites, educational websites and commercial websites, and some of them do have some of the above, and I've even found that websites that I use credit cards with are not filtering any of the input, so it's scary to think.

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.

Conclusion

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.