Comprehensive analysis of network attacks cross-site scripting attacks XSS

Turn from: http://netsecurity.51cto.com/art/201006/204283.htm

As the business manager of the website, when appreciating the rich business and interesting experience that he offers to the customer, have you ever thought that the website will become the medium that the attacker attacks the third party, thus causes the credibility to be greatly damaged. As a visitor to a website, have you ever thought that when you visit the site you are familiar with, your private information has been stolen by others.

All of these are related to cross-site scripting attacks. Let's take a look at this type of attack in detail below.

One, what is a cross-site script.

Cross-station scripting (Cross-site scripting, referred to as XSS) is an attack technique that forces Web sites to echo executable code that is provided by an attacker and eventually loaded by the user's browser. Unlike most attacks (typically involving only attackers and victims), XSS involves three parties, the attacker, the client, and the Web site. XSS's target is to steal the client's cookies or sensitive information that other Web sites use to identify the client. After obtaining the information of a legitimate user, an attacker can even impersonate an end user to interact with the Web site.

An XSS vulnerability is due to the fact that Web applications of dynamic Web pages do not adequately filter the user submission request parameters, allowing the user to add HTML code to the submitted data (most notably ">", "<"), and then output it to a Third-party user's browser without coding. The malicious submission of the attacker's code would be interpreted by the victim user's browser.

Second, the XSS abbreviation source.

In accordance with the English abbreviation habit, referred to as cross-station script for CSS. This causes it to be confused with another noun "cascading style sheet" (cascading style sheets,css). This CSS is not a CSS. To make a difference, some security people are accustomed to simply refer to Cross-site scripting as XSS.

Iii. What are the threats to XSS?

An attacker could exploit an XSS vulnerability and exploit a vulnerable web site to attack other users browsing related Web pages, steal sensitive information such as user names and passwords (possibly contained in cookies) in a user's browsing session, and perform a horse-mount attack on the user by inserting malicious code. XSS vulnerabilities can also be used by attackers for web tampering, but most cases are not directly tampered with in order to maximize economic benefits.

Iv. The prevalence of XSS vulnerabilities is high.

The latest data [4] of the International Web Application Security Organization WASC (Web application secure Consortium) indicates that 10,297 Web sites were sampled, with 31.47% sites having XSS vulnerabilities, And XSS accounted for 41.41% of the total number of vulnerabilities found, topped the list.

Figure 1. The most pervasive Web application security vulnerabilities [4]

can you enumerate examples of XSS?

In the 2005, a MySpace user named Samy himself created an XSS worm, and within 24 hours the number of its friends in cyberspace rose from 73 to 1 million.

2006, PayPal was an XSS attack, the attacker will be the PayPal site to redirect visitors to a new page, warning users their account is no longer safe, need to reset, and prompted to enter PayPal login information, social Security information and credit card information.

ebay in May 2008 acknowledged an XSS vulnerability in its PayPal page that could be used by attackers to steal user certificates or cookies.

Vi. How an attacker steals cookies through an XSS attack.

Here, just give examples to help readers understand the idea of XSS attack. The examples in this article come from.

First, let's assume that there is a website www.vulnerablee****.com. There is a script welcome.cgi on the Web site with the parameter set to name. This script reads the portion of the HTTP request, and then, without any security validation, echoes the request part or all back to the response page.

Typically, if the client sends the following request:

Get/welcome.cgi?name=sammi http/1.0 Host:www.vulnerablee****.com

The server will respond with the following:

Hi Sammi welcome! ...

Pop-up Alert window sample

How will these mechanisms be used by attackers? Let's first enumerate an intuitive approach. Often, an attacker would use social engineering (Social Engineering) to trick a victim into clicking on a carefully constructed link by an attacker, such as sending a message titled "Listen to the Lincoln Park Beijing Live Concert" for free.

The malicious links constructed by an attacker are as follows:

Http://www.vulnerablee**.com/welcome.cgi?name=

Once the victim clicks on a malicious link, it sends the following request to the Www.vulnerablee***.site site:

Get/welcome.cgi?name= http/1.0 Host:www.vulnerablee****.com ...

The site returns the following response:

Hi welcome! ...

Because the server-side returned HTML page contains a section of JavaScript code, the victim's browser interprets the execution. After this code is executed, it is allowed to access cookies belonging to the www.vulnerablee***.com site in the browser. At this point, an alert window pops up on the user's side browser.

Web site Collection Cookie sample

In the real attack step, these cookies are sent to the attacker. The attacker would build a Web site (called www.attackere**.com), and a script would be used to receive the stolen cookie. An attacker would write a malicious code that could be used to access an attacker's site and invoke a script to receive cookies. Eventually, the attacker could get cookies from the Www.attackere**om site.

The malicious links constructed are as follows:

Http://www.vulnerablee**om/welcome.cgi?name=

The server response content is displayed as:

Hi welcome! ...

The browser loads the server-side return page, executes the embedded JavaScript, and sends a request to the collect.cgi script on the Www.attackere**om site, saved www.vulnerablee*** in the browser. The cookie value for the COM site is also sent to the past. The attacker obtains a cookie from the customer at the www.vulnerablee***.com site and can impersonate the victim.

VII. encryption can effectively protect against XSS attacks.

It is generally thought that if the site uses HTTPS to provide more secure security, it can be spared from XSS attacks. In fact, this is a misunderstanding. HTTPS provides only the security of the transport layer, and still faces an XSS threat at the application level.

viii. Whether an XSS vulnerability could cause an illegal execution of the command.

If the browser settings are not secure enough, an XSS vulnerability allows JavaScript to be inserted, which means that an attacker may gain restricted client execution permissions. If an attacker proceeds to exploit a browser vulnerability, it is possible to execute commands illegally on the client. In short, XSS vulnerabilities can help further exploit browser vulnerabilities.

how to protect against XSS attacks from the website developer's point of view.

From the owasp of application Security International, the best protection against XSS should be combined with the following two methods: validating all input data, effectively detecting attacks, and encoding all output data appropriately to prevent any successfully injected script from running on the browser side. Specifically as follows:

Input validation: A standard input validation mechanism is used to validate the length, type, syntax, and business rules of all input data before a data is accepted as available for display or storage.

Strong output encoding: Before data is exported, ensure that the data submitted by the user has been properly entity encoded, it is recommended that all characters be encoded and not limited to a subset.

Explicitly specify the encoding of the output (such as ISO 8859-1 or UTF 8): Do not allow attackers to choose the encoding for your users.

Note the limitations of the blacklist verification approach: simply finding or replacing characters (such as "<" > "or" Script-like keywords) can easily be bypassed by XSS variant attacks.

Beware of canonicalization errors: Before validating input, it must be decoded and normalized to conform to the application's current internal presentation method. Make sure the application does not decode the same input two times.

10, from the site user perspective, how to protect against XSS attacks.

When you open an email or an attachment or browse a forum post, a malicious script may be executed automatically, so be cautious when doing so. It is recommended that you turn off JavaScript in your browser settings. If you use IE browser, set the security level to high. Specific reference to the browser security related articles.

Once again, XSS attacks are accompanied by a successful application of social engineering, which requires increased security awareness and trust in only trustworthy sites or content.

11, if the repair of XSS vulnerabilities to the site is more difficult, do not repair how.

If an XSS vulnerability is not patched in time, the site could be a medium for attackers to attack third parties, compromised by a victim of a Web site, and sensitive information. In reality, there are some objective reasons why it is impossible to fix vulnerabilities, such as the fact that Web application development is older or the cost of correcting code is too high. In this case, choosing a Web security gateway would be a reasonable choice. Proper application of this type of security tool can greatly mitigate XSS attacks and reduce security risks.

12, the next generation of XSS will be what.

The

with Ajax (asynchronous JavaScript and XML, asynchronous JavaScript and XML) technology, the XSS attack Hazard will be magnified. The great advantage of using AJAX is that you can maintain data without updating the entire page, and Web applications can respond more quickly to user requests. Ajax handles the rich information from the Web server and from third parties, which provides a good opportunity for XSS attacks. The AJAX application architecture leaks More details about the application, such as function and variable names, function parameters and return types, data types, and valid ranges. AJAX application architectures also have more application input than traditional architectures, which increases the number of points that can be attacked.