XSS Cross-site scripting attacks

Read Catalog 1, Introduction 2, Reason resolution 3, XSS attack classification 3.1, reflective XSS attack 3.2, storage XSS attack 3.3, DOMBASEDXSS (DOM-based cross-site scripting attack) 4, XSS attack Example analysis 1, simple XSS attack Example 2, stealing Cookie 5, XSS bug fix 5.1, HTML entity 5.2, HTML Encode 5.3, Fix vulnerability guideline 5.4, corresponding function in PHP 5.5, data filter class back to top 1, Introduction

Cross site script is referred to as XSS in order to avoid confusion with style CSS.

XSS is a computer security vulnerability that often occurs in Web applications and is the most prevalent attack in the web. So what is XSS?

XSS is the disadvantage of a malicious attacker exploiting a website without escaping or filtering the user's submitted data, and then adding some code to embed it in a Web page. Enabling other users to access will execute the appropriate embed code.

In order to steal user data, use the identity of the user to carry out some kind of action or a virus attack on the visitor.

The hazards of XSS attacks include:

1, stealing all kinds of user accounts, such as machine login account, user network Bank account, all kinds of administrator account

2, control enterprise data, including read, tamper, add, delete enterprise sensitive data ability

3, the theft of business important business value of the information

4. Illegal transfer

5. Mandatory e-mail delivery

6. The website hangs the horse

7. Control the victim's machine to launch attacks on other websites

Back to top 2, reason analysis

Main reason: Too much trust in the data submitted by the client.

Workaround: Do not trust any client-submitted data, as long as the data submitted by the client should be the appropriate filtering processing before the next step can be done.

Further analysis details:

The data submitted by the client is required by the application, but a malicious attacker leverages the trust of the Web site to submit data to the client, inserts some symbols into the data, and the JavaScript code, which becomes part of the application code. Then the attacker can attack with impunity.

So we can never trust any client-submitted data ...

Back to top 3, XSS attack category

"Understand, do not scrutiny, XSS root is not fully filtering the data submitted by the client" back to top 3.1, reflective XSS attack

Also known as non-persistent cross-site scripting attacks, it is the most common type of XSS. The vulnerability arises because the data injected by the attacker is reflected in the response. A typical non-persistent XSS contains a link with an XSS attack vector (that is, each attack requires a user's click).

Simple example

Send Message normally:

Http://www.test.com/message.php?send=Hello,World.

The recipient will receive the message and display the Hello,word

Non-normal Send message:

Http://www.test.com/message.php?send=<script>alert (' foolish! ') </script>.

When the receiver receives the message, it will pop up a warning window back to the top 3.2. Storage type XSS attack

Also known as persistent cross-site scripting, it typically occurs when an XSS attack vector (commonly referred to as an XSS attack code) is stored in a Web site database and executed when a page is opened by the user. The script executes whenever the user opens the browser. Persistent XSS is more harmful than non-persistent XSS attacks because the script executes automatically whenever the user opens the page and views the content. Google's orkut once suffered from XSS.

Simple example:

It is known from the name that a storage-type XSS attack is to store the attack code in the database and then execute the attack code when the client opens. such as message board

form fields in the Message board form: <input type= "text" name= "content" value= "Here is the data that the user fills in" >

Normal operation:

The user submits the corresponding message, stores the data to the database, and the other user accesses the message board, applies the data and displays it.

Non-normal operation:

The attacker fills in the value <script>alert (' foolish! ') </script> "or HTML other tags (break style ... ), an attack-type code ";

Store the data in a database;

When other users take out the data display, these offensive code will be executed back to top 3.3, DOMBASEDXSS (DOM-based cross-site scripting attack)

The DOM-based XSS is sometimes referred to as TYPE0XSS. This vulnerability can occur when a user is able to interactively modify the DOM (Documentobjectmodel) in a browser page and display it on a browser, which is, in effect, a reflection-type XSS.

The XSS formed by modifying the DOM node of the page is called DOMBASEDXSS.

The premise is that a vulnerable website has an HTML page that takes an unsafe way from document.location or document. The URL or document.referrer gets the data (or any other object that the attacker can modify).

Simple example:

1 <HTML>
 2 <TITLE>Welcome!</TITLE>
 3 Hi
 4 <SCRIPT>
 5 var pos=document. Url.indexof ("name=") +5;
 6 document.write (document. Url.substring (pos,document. url.length));
 7 </SCRIPT>
 8 <BR>
 9 Welcome to our system ...
</HTML>

This example is a welcome page, name is the name parameter that intercepts the get over the URL

Normal operation:

Http://www.vulnerable.site/welcome.html?name=Joe

Non-normal operation:

Http://www.vulnerable.site/welcome.html?name=<script>alert (Document.cookie) </script>

An XSS condition is generated. Let's see why: The victim's browser receives this link, sends an HTTP request to Www.vulnerable.site, and receives the HTML page above. The victim's browser begins parsing this HTML for Dom,dom contains an object called Document,document that has a URL attribute that fills the URL of the current page. When the parser arrives at the JavaScript code, it executes it and modifies your HTML page. If the document is referenced in the code. URL, then this part of the string will be embedded in the HTML at parse time and then parsed immediately, and the JavaScript code will be found (alert (...)). and executes it on the same page, which creates the condition for XSS.

Attention:

1. Malicious program scripts are not embedded in the natural state of HTML pages at any time (this is not the same as other kinds of XSS).

2. This attack only works if the URL character is not modified by the browser. When the URL is not directly entered in the Address bar, Mozilla. will automatically convert characters < and > (converted to%3c and%3e) in Document.url, so it will not be attacked by the above example, and there is no conversion < and no under IE6; So he is vulnerable to attack.

Of course, embedding directly into HTML is just one mount point of an attack, and there are many scripts that don't need to rely on < and > vulnerabilities, so Mozilla is often unable to prevent these attacks.

"This paragraph from: Http://www.oschina.net/translate/dom-based-xss-of-third-kind"

Back to top 4, XSS attack case analysis back to top Example 1, simple XSS attack

Message class, simple injection JavaScript

There is a form field: <input type= "text" name= "content" value= "This is user-filled data" >

1. If the user fills in the data as follows: <script>alert (' foolish! ') </script> (or <script type= "Text/javascript" src= "./xss.js" ></script>)

2. After the submission, a foolish warning window will pop up and the data will be stored in the database

3, wait until other clients request this message, the data will be taken out to show the message will execute the attack code, will display a foolish warning window.

"Changing the data to an HTML tag will disrupt the original style .... "Back to top Example 2, stealing cookies