# XSShield: Defending Against Stored XSS Attacks Using LLM-Based Semantic Understanding
## 2 Background and Motivation  
### XSS Attack Mechanisms  
XSS is a type of security vulnerability that allows attackers to inject malicious client-side code (typically JavaScript) into web pages viewed by other users. When users visit these compromised pages, the injected code executes in their browsers within the security context of the vulnerable website, potentially leading to severe security consequences. XSS attacks can result in unauthorized access to user data, session hijacking, cookie theft, credential harvesting, and website content tampering [1, 6]. The core mechanism of XSS attacks exploits the trust relationship between users and websites. When a website fails to properly validate, sanitize, or encode user-supplied input before incorporating it into its output HTML, attackers can insert malicious scripts that browsers will interpret as legitimate code from the trusted domain. As web applicationsbecome increasingly prevalent and complex, the threats posed by XSS attacks continue to escalate, making the in-depth research and development of effective defense methods a critical topic in cybersecurity. Figure 1 illustrates the different types of XSS attacks. XSS attacks can be categorized into two major types based on how the malicious payload is delivered and made to persist: reflected XSS and stored XSS. Reflected XSS (non-persistent XSS) is a form of immediate execution attack characterized by embedding malicious scripts within user requests sent to the server, which, without proper validation, are directly reflected back to the user's browser for execution. This type of attack typically requires active user triggering, such as clicking specific URLs or submitting forms containing malicious payloads. For example:  
* **Reflected XSS Scenario:** URL: [[https://vulnerable-site.com/search?q=](https://vulnerable-site.com/search?q=)]([https://vulnerable-site.com/search?q=](https://vulnerable-site.com/search?q=)){payload} Code: <input type=\"text\" value=\"{payload}\">  
In this scenario, the malicious script is embedded in the URL query parameter, which is then reflected in the search results page without proper sanitization. For reflected XSS, researchers have developed various effective runtime detection and elimination techniques, such as intercepting scripts after HTML parsing and skipping malicious scripts during the parsing phase. These traffic monitoring-based defense methods can capture the immediate characteristics of attacks, effectively identifying and blocking reflected XSS attacks [7]. In contrast, stored XSS (persistent XSS) exhibits significantly different characteristics, presenting greater challenges for defense. Stored XSS attacks persistently store malicious scripts in the target server's backend systems (such as databases, file systems, or caches), creating a distinct temporal asynchronicity between the injection and execution phases [8]. For instance:  
* **Stored XSS Scenario:** URL: [[https://vulnerable-site.com/profile](https://vulnerable-site.com/profile)]([https://vulnerable-site.com/profile](https://vulnerable-site.com/profile))  
Figure 1: Comparison of detection mechanisms between reflected XSS and stored XSS attacks. The left diagram illustrates how in reflected XSS attack scenarios, the differential analysis successfully detects malicious payload within the request–response traffic and issues a “ban” signal to prevent the attack from completing. The right diagram demonstrates how in stored XSS attack scenarios, the differential analysis becomes ineffective and issues a “pass” signal, allowing the attack to complete, since the attack payload only appears in the response but not in the request traffic. In the stored XSS case (right), when the victim user accesses the compromised page through normal request (3), the attack payload embedded in the server’s database is delivered in the response without any corresponding malicious content in the current request.