Comprehensive Summary of XSS (Cross‑Site Scripting) Attacks and Defenses

Introduction

1. Apologies for the recent silence due to personal reasons; I will try to update the public account more regularly. This space is a personal corner where I share useful content and curated materials, hoping readers gain something from it. 2. When learning technology, avoid spending too much time on fragmented public‑account articles; they have limited value for growth. Use them as a tool for quick reference during idle moments. 3. Thank you again to everyone who has quietly followed and supported me.

This article originates from a knowledge‑base compilation at work, gathering useful online resources about XSS. Since links cannot be opened directly in the public account, click the "Read Original" button to view the source.

XSS (Cross‑Site Scripting) Content Summary

Cross‑Site Scripting (XSS)

XSS Overview

Cross‑Site Scripting (XSS) is the most common web‑application security vulnerability. It allows an attacker to inject malicious script code into pages that normal users will visit, causing the script to execute in the victim's browser and enabling actions such as session hijacking, content injection, redirection, malware delivery, or even site takeover.

Impact of XSS

1. Phishing and credential theft; 2. Cookie theft leading to privacy breaches and unauthorized actions; 3. Session hijacking for arbitrary operations (e.g., illegal transfers, forced posts, email sending); 4. Forced ad pop‑ups and traffic inflation; 5. Web page defacement; 6. Malicious operations like data tampering or article deletion; 7. Large‑scale client attacks such as DDoS; 8. Combination with other vulnerabilities (e.g., CSRF) for further exploitation; 9. Propagation of XSS worms.

Stealing various user accounts and permissions. Controlling enterprise data (read, modify, add, delete). Cross‑site business requests (illegal transfers, orders, content posting, email sending, privilege escalation, etc.). Establishing persistent APT attacks to control the site’s core. Worm‑like propagation of malicious code. Site hijacking for phishing, spoofing, redirection, or ad injection.

XSS attacks target the client side; they do not directly harm the web server but exploit browsers that render malicious pages.

XSS Mechanism

HTML treats certain characters (e.g., < ) as the start of a tag. When dynamic pages insert user‑controlled content containing these characters, the browser may interpret them as actual HTML tags. If those tags embed a JavaScript snippet, the script runs in the victim's browser, creating an XSS vulnerability.

The main attack inserts JavaScript into HTML, which can execute malicious code.

Scripts can be placed inside tags or tag attributes. See the blog "XSS Principles Analysis and Dissection" for details. XSS attacks execute arbitrary JS, allowing cookie theft (unless HttpOnly), event triggering, etc.

Reference: XSS Principles Analysis and Dissection

Injection Vectors

Not only user‑generated content (UGC) can be injected; URLs, parameters, and other sources are also untrusted. The following inputs must be considered unsafe:

User‑generated content (UGC)

Third‑party links

URL parameters

POST parameters

Referer header (potentially untrusted)

Cookies (possible sub‑domain injection)

XSS Classification

Based on the source of the attack, XSS can be divided into Stored, Reflected, and DOM‑based types.

Type

Storage

Insertion Point

Stored XSS

Backend database

HTML

Reflected XSS

URL

HTML

DOM‑based XSS

Backend DB / Frontend storage / URL

Frontend JavaScript

Storage: where the malicious code resides.

Insertion Point: who inserts the malicious code into the page.

See the "Frontend Security Series (Part 1)" for more details.

Reflected XSS is the most common: an attacker discovers a vulnerable URL, crafts a payload, possibly encodes or shortens it, sends it to the victim, and upon opening the link the script executes, stealing cookies, URLs, browser info, IP, etc.

Stored XSS does not require the victim to click a specific link; once malicious code is stored (e.g., in a comment board), every user visiting that page is compromised.

If a comment board contains malicious code, all subsequent visitors will be affected.

Reference: QtWebKit‑based DOM XSS detection – Tencent Security Blog

XSS Defense Summary

XSS attacks consist of two main elements:

Attacker submits malicious code.

Backend should escape HTML tags, but care must be taken to correctly handle characters like > and < . Adjust according to business needs (e.g., preserving "2>7").

Browser executes the malicious code.

Many frontend frameworks already provide built‑in XSS mitigation.

Cooperation between backend and frontend can effectively prevent XSS attacks.

XSS Q&A

Source: GitBook

Q: What practical differences exist between XSS attacks in GET vs. POST requests? A: The difference is minor; the request method changes, but both can carry malicious scripts.

Q: How to prevent stolen cookies from being abused? A: Add expiration or bind the cookie to the user.

Q: What is the difference between XSS and CSRF? A: CSRF relies on a trusted user session and can work without JavaScript, whereas XSS requires script execution in the victim's browser. CSRF defenses include HttpOnly cookies, non‑persistent tokens, and secondary authentication for risky actions.

Q: Any quick and effective ways to prevent XSS? A: Use HttpOnly to protect cookies, employ OWASP XSS‑escaping APIs, filter data both on the frontend and backend.

Q: How to handle XSS filtering characters? A: Encode special characters like angle brackets and backslashes, e.g., using ESAPI functions to convert them to numeric entities (e.g., < ).

Q: Any book recommendations on XSS? A: "XSS Cross‑Site Scripting Attack Analysis and Defense" (red cover, Roman helmet logo) is a comprehensive resource.

Q: How to start learning OWASP Top 10 and become a white‑hat? A: Set up a local test environment (e.g., IIS with a firewall) and practice on vulnerable labs. Focus on filling knowledge gaps rather than chasing every new vulnerability.

Q: How to exploit a stolen XSS cookie? A: Use it as a credential to replace the login cookie and gain authenticated access.

References

XSS Cross‑Site Scripting Attack Analysis and Defense: https://zhuanlan.zhihu.com/p/87756976

XSS Principles Analysis and Dissection: https://www.freebuf.com/articles/web/40520.html

Second part of XSS Principles Analysis: https://www.freebuf.com/articles/web/42727.html

Seven Principles for Defending XSS: https://www.freebuf.com/articles/web/9977.html

Common XSS Attack Scripts Collection: https://blog.csdn.net/qw_xingzhe/article/details/80712840

Spring Boot XSS Protection: https://www.cnblogs.com/dslx/p/11551542.html

HttpServletRequestWrapper XSS Injection Implementation: https://www.cnblogs.com/zdd-java/p/7528496.html

Frontend Security Series (Part 1) – How to Prevent XSS: https://tech.meituan.com/2018/09/27/fe-security.html

This article is highly recommended.

How do Vue, React, etc., defend against XSS? https://www.zhihu.com/question/338939262

Java open‑source HTML filter utility: http://opensource.finn.no/xss-html-filter/