- Written by Xie Yong
- Editor｜Wang Congli, Yu Zhenni
- Information Collection｜Xie Yong
table of Contents
1 Introduction
The previous article introduced "reflected XSS" in cross-domain scripting attacks, enumerating and explaining some of the main methods of malicious script injection and evasion methods. In fact, in addition to directly injecting JavaScript, attacks can also be carried out through third parties such as flash, Java applet, etc. These third-party tools have their own operating environment. For example, Flash uses ActionScript as a script, which can realize rich and flexible functions, and also provides an opportunity for XSS. Therefore, it is necessary to avoid loading user-defined flash; Java applet can be passed through Java API to get the information of the local machine. XSS defense against third-party tools also needs attention.
2. What is stored XSS
Stored XSS is an attack method that saves malicious code to the server. Whenever a user visits a page containing malicious code, the code execution is triggered to achieve the purpose of the attack. Different from the characteristic of reflective XSS that only one attack can be performed once, once the malicious script of the stored XSS is stored on the server, it can be used many times, which is called "persistent XSS".
Video introduction link: https://mp.weixin.qq.com/s/6c2D7wZDLtl78uiXfwvfrg
3. Principle of Attack
As shown in Figure 1, the principle of the stored XSS attack is that the attacker enters malicious code on the interactive page and then submits it to the web program. If the web program does not provide XSS protection for the input content, the malicious code will be stored in the database. . Next, as long as there is a user to access and view the content submitted by the attacker, when the web application responds to the user's request, the malicious code will be read from the server and executed. Therefore, the malicious code stored on the server can attack different users multiple times. For example, there is a website that publishes dynamics. An attacker can submit malicious code in the dynamic publishing form. When other users view the attacker's dynamic message, these malicious scripts are loaded from the server and parsed by the browser. And execution.
The payload of the stored XSS is not much different from the reflective XSS, and it is also the reason for injecting code into HTML. Therefore, when we discuss stored XSS, we are concerned about how to use the XSS vulnerabilities of web applications to submit malicious code to the server, which is the black arrow in Figure 1. An important condition is that there is a certain amount of interaction between users in a web application, rather than playing differently. For example, blogs, forums, etc., this kind of mutual access system is the soil for the growth of storage XSS. Secondly, in the web system, find the input locations that can be stored in the database, such as elements such as forms and text boxes, and perform normal operations in these elements, so that malicious scripts are stored in the database as ordinary input data. Of course, you must use tags and events that are not filtered by the web application, otherwise the code that can cause XSS will be destroyed after the input data is filtered.
For example, the attacker "Xiao Hei" entered the content of Figure 2 on a forum with stored XSS vulnerabilities and published it on the forum. This code was saved to the database by the server without processing. When the victim "Little Pot" visited this forum, he clicked on the content posted by Xiaohei. This code was returned to Xiaoguo's client in the response content, and was added to the DOM tree by the browser and parsed. Since the content pointed to by src does not exist, the onerror event is triggered, the malicious script is executed, and the small pot sees a pop-up message displaying "1", as shown in Figure 3. Xiaohei can also enter malicious codes into the input boxes of his nickname, profile, etc. When others click on Xiaohei's personal information page, he will be attacked by malicious codes.
4. Ways of Defense
Storage type XSS is more harmful than reflection type XSS because it does not need to construct a special URL, and the user visits a normal URL can also be attacked; on the other hand, it is persisted on the server side, and the scope of impact can be compared Reflective XSS is wider. The method of defending against stored XSS is similar to that of reflective XSS. It checks and encodes input and output to minimize the possibility of data containing codes.
