XSS là gì? Tìm hiểu về tấn công Cross-Site Scripting

Kẻ tấn công có thể đánh cắp dữ liệu, chiếm phiên đăng nhập hoặc thực hiện hành động dưới danh nghĩa nạn nhân với XXS. Vậy XSS là gì, tấn công XSS hoạt động như thế nào và làm sao để phòng chống? Hãy cùng tìm hiểu chi tiết trong bài viết dưới đây.

XSS là gì?

XSS (Cross-Site Scripting) là một dạng lỗ hổng bảo mật web xảy ra khi ứng dụng đưa dữ liệu không đáng tin cậy vào nội dung trang web mà không xử lý an toàn, từ đó tạo điều kiện cho mã độc được thực thi trên trình duyệt của người dùng.

Mã được chèn thường là JavaScript. Nội dung HTML hoặc những loại dữ liệu khác mà trình duyệt có khả năng xử lý cũng có thể trở thành một phần của cuộc tấn công.

Có thể hình dung đơn giản:

Kẻ tấn công → đưa dữ liệu độc hại vào ứng dụng → website trả dữ liệu về trình duyệt → trình duyệt coi dữ liệu đó là mã hợp lệ → mã được thực thi.

Chính đặc điểm này khiến XSS có thể ảnh hưởng trực tiếp đến người đang sử dụng website dù máy chủ không bị chiếm quyền hoàn toàn.

Trong OWASP Top 10:2025, Cross-Site Scripting được xếp trong nhóm A05:2025 – Injection. Dữ liệu OWASP sử dụng cho nhóm này ghi nhận hơn 30.000 CVE liên quan đến Cross-Site Scripting, cho thấy XSS vẫn là vấn đề bảo mật ứng dụng web đáng chú ý.

XSS hoạt động như thế nào?

XSS (Cross-Site Scripting) hoạt động dựa trên cơ chế: kẻ tấn công chèn mã script độc hại (thường là JavaScript) vào ứng dụng web, và trình duyệt của người dùng lầm tưởng đó là mã hợp pháp của trang nên đã thực thi nó.

Cụ thể, quy trình diễn ra qua 3 bước cốt lõi:

• Chèn mã (Injection): Kẻ tấn công đưa đoạn mã độc vào hệ thống thông qua các trường nhập liệu (như ô bình luận, thanh tìm kiếm, URL parameters).
• Thiếu kiểm soát (Reflection/Storage): Ứng dụng web nhận dữ liệu này nhưng không làm sạch (sanitize) hay mã hóa (encode), rồi đưa thẳng vào cấu trúc HTML trả về cho người dùng.
• Thực thi trên trình duyệt (Execution): Trình duyệt của nạn nhân tải trang, phân tích mã nguồn và tự động chạy đoạn JavaScript độc hại đó dưới ngữ cảnh và quyền hạn của chính nạn nhân trên trang web.

Nguyên nhân gây ra lỗ hổng XSS

XSS thường được mô tả đơn giản là hậu quả của việc “không lọc dữ liệu đầu vào”. Tuy nhiên, nguyên nhân thực tế phức tạp hơn. Một ứng dụng vẫn có thể tồn tại XSS ngay cả khi đã kiểm tra input nếu dữ liệu sau đó được đưa vào context không an toàn.

Không xử lý dữ liệu không đáng tin cậy đúng cách

Dữ liệu từ người dùng, URL, API hoặc nguồn bên ngoài không nên được mặc định là an toàn.

Nếu dữ liệu này được đưa trực tiếp vào HTML hoặc JavaScript, ứng dụng có thể vô tình biến dữ liệu thành mã thực thi.

Output Encoding không phù hợp

Output Encoding giúp đảm bảo ký tự đặc biệt được trình duyệt hiểu là dữ liệu thay vì cú pháp HTML hoặc JavaScript.

Tuy nhiên, cách encode phụ thuộc vào vị trí dữ liệu xuất hiện.

Ví dụ, cách xử lý dữ liệu trong:

• Nội dung HTML.
• Thuộc tính HTML.
• JavaScript.
• CSS.
• URL.

không hoàn toàn giống nhau.

Đây là lý do context-aware output encoding đóng vai trò quan trọng trong phòng chống XSS.

Sử dụng API JavaScript không an toàn

Trong ứng dụng web hiện đại, nhiều dữ liệu được xử lý trực tiếp phía client.

Nếu JavaScript nhận dữ liệu có thể bị kiểm soát rồi đưa chúng vào một DOM API không an toàn, XSS có thể xảy ra mà không cần máy chủ trực tiếp tạo đoạn mã độc. Đây là một trong những cơ chế phổ biến của DOM-based XSS.

Cho phép HTML nhưng không Sanitization

Một số hệ thống cần cho phép người dùng nhập nội dung có định dạng HTML, chẳng hạn:

• Trình soạn thảo bài viết.
• Bình luận.
• Email.
• CMS.
• Diễn đàn.

Trong trường hợp đó, chỉ encode toàn bộ HTML sẽ làm mất chức năng định dạng. Ứng dụng cần sử dụng cơ chế HTML Sanitization để giữ lại nội dung hợp lệ nhưng loại bỏ các thành phần nguy hiểm.

Các loại tấn công XSS phổ biến

XSS thường được chia thành ba nhóm chính gồm Reflected XSS, Stored XSS và DOM-based XSS.

Reflected XSS

Reflected XSS xảy ra khi dữ liệu từ một HTTP request được ứng dụng đưa ngay vào HTTP response theo cách không an toàn.

Reflected XSS thường cần nạn nhân thực hiện một hành động như:

• Mở một liên kết.
• Truy cập URL được tạo sẵn.
• Gửi một request chứa dữ liệu do kẻ tấn công kiểm soát.

Do nội dung độc hại thường không được lưu lâu dài trên máy chủ nên Reflected XSS còn được gọi là non-persistent XSS.

Stored XSS

Stored XSS xảy ra khi dữ liệu độc hại được lưu lại trong hệ thống và sau đó được đưa vào trang web mà không được xử lý an toàn.

Dữ liệu có thể được lưu trong:

• Database.
• Bình luận.
• Bài đăng.
• Hồ sơ người dùng.
• Ticket hỗ trợ.
• Nội dung diễn đàn.
• Một số hệ thống xử lý email hoặc dữ liệu bên ngoài.

Khi người dùng truy cập trang chứa dữ liệu đó, mã có thể tự động được gửi về trình duyệt và thực thi.

Stored XSS thường có phạm vi ảnh hưởng lớn hơn Reflected XSS vì payload đã tồn tại trong ứng dụng. Kẻ tấn công không nhất thiết phải gửi riêng một URL độc hại cho từng nạn nhân.

Ví dụ, nếu mã độc được lưu trong một bình luận công khai, bất kỳ người dùng nào xem bình luận đó đều có khả năng bị ảnh hưởng.

DOM-based XSS

DOM-based XSS xảy ra chủ yếu trong mã JavaScript phía client.

Một ứng dụng có thể:

1. Đọc dữ liệu từ URL hoặc nguồn khác.
2. Xử lý dữ liệu bằng JavaScript.
3. Đưa dữ liệu vào Document Object Model (DOM).
4. Sử dụng một phương thức không an toàn.
5. Khiến trình duyệt diễn giải dữ liệu thành mã.

Trong trường hợp này, lỗ hổng có thể tồn tại hoàn toàn ở phía trình duyệt thay vì quá trình render HTML trên server.

DOM-based XSS ngày càng đáng chú ý do các website hiện đại sử dụng JavaScript và kiến trúc client-side ngày càng nhiều.

So sánh Reflected XSS, Stored XSS và DOM-based XSS

Dù cơ chế khác nhau, điểm chung của ba loại là dữ liệu không đáng tin cậy cuối cùng được xử lý trong một context cho phép nó trở thành mã thực thi.

Tấn công XSS có thể gây ra những hậu quả gì?

Mức độ nguy hiểm của XSS phụ thuộc vào website, loại lỗ hổng, quyền của nạn nhân và các cơ chế bảo mật đang được sử dụng.

Một lỗ hổng trên trang công khai có thể có tác động khác hoàn toàn so với XSS xuất hiện trong hệ thống quản trị mà administrator thường xuyên truy cập.

Đánh cắp dữ liệu nhạy cảm

Mã chạy trên trình duyệt có thể tìm cách truy cập dữ liệu mà JavaScript của trang được phép đọc, sau đó gửi chúng tới hệ thống bên ngoài.

Dữ liệu bị ảnh hưởng có thể gồm thông tin hiển thị trên trang, token hoặc các dữ liệu ứng dụng khác.

Chiếm hoặc lợi dụng phiên đăng nhập

Nếu session token được lưu trữ hoặc xử lý theo cách không an toàn, XSS có thể được sử dụng để chiếm phiên người dùng.

Cookie có thuộc tính HttpOnly sẽ hạn chế JavaScript truy cập trực tiếp vào cookie đó, nhưng HttpOnly không loại bỏ bản thân lỗ hổng XSS.

Thực hiện hành động dưới danh nghĩa người dùng

Một đoạn script chạy trong phiên hợp lệ có thể gửi request hoặc tương tác với ứng dụng bằng quyền mà nạn nhân đang có.

Nếu nạn nhân là administrator, tác động có thể nghiêm trọng hơn đáng kể.

Thay đổi nội dung website

XSS có khả năng thay đổi DOM và nội dung người dùng nhìn thấy trên trang.

Kẻ tấn công có thể lợi dụng đặc điểm này để:

• Chèn nội dung giả mạo.
• Hiển thị form đăng nhập giả.
• Chuyển hướng người dùng.
• Thay đổi đường dẫn.
• Thực hiện phishing ngay trong website hợp lệ.

XSS vì vậy không chỉ là vấn đề “xuất hiện popup trên trình duyệt”. Trong thực tế, khả năng thực thi mã trong context của website mới là rủi ro cốt lõi.

Cách phát hiện lỗ hổng XSS

Phát hiện XSS cần kết hợp kiểm tra mã nguồn, kiểm thử ứng dụng và theo dõi luồng dữ liệu từ nguồn đầu vào đến vị trí dữ liệu được render.

Kiểm tra các điểm nhận dữ liệu

Trước tiên cần xác định những vị trí ứng dụng tiếp nhận dữ liệu bên ngoài như:

• URL parameter.
• Form.
• HTTP header.
• API.
• Cookie.
• Dữ liệu trong database.
• Dữ liệu từ dịch vụ bên thứ ba.

Sau đó kiểm tra dữ liệu được đưa tới đâu và có được encode hoặc sanitize phù hợp trước khi hiển thị hay không.

Rà soát source và sink trong JavaScript

Đối với DOM-based XSS, cần đặc biệt chú ý tới luồng:

Source → xử lý JavaScript → Sink

Source là nơi dữ liệu có khả năng bị kiểm soát đi vào ứng dụng, trong khi sink là nơi dữ liệu được đưa vào DOM hoặc thực thi theo cách có thể trở nên nguy hiểm.

Việc thay thế unsafe sink bằng các API an toàn là một trong những biện pháp quan trọng để hạn chế Client-side XSS.

Sử dụng công cụ kiểm thử bảo mật

Doanh nghiệp có thể kết hợp:

• Static Application Security Testing (SAST).
• Dynamic Application Security Testing (DAST).
• Code review.
• Vulnerability scanning.
• Penetration testing.
• Kiểm thử thủ công.

Công cụ tự động giúp mở rộng phạm vi kiểm tra nhưng không nên được xem là phương pháp duy nhất, đặc biệt với các luồng DOM và business logic phức tạp.

Cách phòng chống XSS hiệu quả

Không có một biện pháp duy nhất có thể ngăn chặn tất cả XSS. Cách tiếp cận phù hợp là xây dựng nhiều lớp bảo vệ từ quá trình phát triển ứng dụng đến lớp bảo mật khi hệ thống hoạt động.

1. Xác thực dữ liệu đầu vào

Ứng dụng nên xác định rõ dữ liệu nào được phép nhập.

Ví dụ:

• Trường số điện thoại chỉ nhận định dạng phù hợp.
• ID chỉ chấp nhận cấu trúc dự kiến.
• URL phải thuộc các protocol được cho phép.
• Các trường có danh sách lựa chọn nên giới hạn đúng giá trị hợp lệ.

Input validation giúp giảm dữ liệu bất thường đi sâu vào hệ thống.

Tuy nhiên, chỉ lọc input là chưa đủ để chống XSS vì kẻ tấn công có thể tìm nhiều cách biểu diễn dữ liệu khác nhau và dữ liệu vẫn có thể trở nên nguy hiểm tùy context.

2. Encode dữ liệu đầu ra theo context

Output Encoding giúp biến ký tự đặc biệt thành dạng mà trình duyệt coi là dữ liệu thông thường.

Quan trọng nhất là sử dụng đúng cách encode cho từng context:

• HTML context.
• HTML Attribute context.
• JavaScript context.
• CSS context.
• URL context.

Không nên sử dụng một hàm encode chung cho tất cả trường hợp.

3. Sanitization khi cần cho phép HTML

Nếu ứng dụng cho phép người dùng nhập rich text hoặc HTML, nên sử dụng thư viện sanitization được duy trì tốt.

Sanitization có nhiệm vụ giữ lại các thành phần HTML hợp lệ đồng thời loại bỏ hoặc vô hiệu hóa nội dung nguy hiểm.

Không nên tự xây dựng bộ lọc HTML đơn giản bằng một vài quy tắc regex vì HTML và cơ chế parsing của trình duyệt rất phức tạp.

4. Sử dụng API DOM an toàn

Đối với ứng dụng JavaScript phía client, cần hạn chế đưa dữ liệu không đáng tin cậy trực tiếp vào những API có khả năng diễn giải chúng như HTML hoặc code.

Khi có thể, hãy sử dụng các API xử lý dữ liệu dưới dạng text thay vì HTML. Đây là lớp bảo vệ đặc biệt quan trọng đối với DOM-based XSS.

5. Tận dụng cơ chế bảo mật của framework

Các framework web hiện đại thường cung cấp cơ chế auto-escaping hoặc encoding mặc định.

Developer nên:

• Giữ framework và thư viện được cập nhật.
• Hạn chế bypass cơ chế escaping mặc định.
• Kiểm tra kỹ những API cho phép render HTML trực tiếp.
• Không mặc định rằng sử dụng React, Angular, Vue hoặc framework khác đồng nghĩa ứng dụng không thể bị XSS.

Framework giúp giảm rủi ro nhưng không loại bỏ hoàn toàn lỗi do developer tạo ra.

6. Triển khai Content Security Policy

Content Security Policy (CSP) là cơ chế cho phép website quy định những loại tài nguyên hoặc script nào trình duyệt được phép tải và thực thi.

Một CSP nghiêm ngặt có thể giới hạn:

• Inline script.
• Script từ nguồn không được phép.
• Một số hành vi tải tài nguyên ngoài dự kiến.

CSP sử dụng nonce hoặc hash có thể giúp kiểm soát script nào được phép thực thi. Tuy nhiên, CSP nên được xem là một lớp defense-in-depth, không phải phương pháp thay thế output encoding và sanitization.

7. Bảo vệ cookie

Các cookie quan trọng nên áp dụng những thuộc tính phù hợp như:

• HttpOnly
• Secure
• SameSite

Trong đó, HttpOnly giúp hạn chế JavaScript truy cập trực tiếp vào cookie và có thể giảm một số hậu quả khi XSS xảy ra.

8. Kiểm thử bảo mật thường xuyên

Ứng dụng liên tục thay đổi theo các bản release, dependency, API và tính năng mới. Do đó, kiểm thử XSS không nên chỉ thực hiện một lần trước khi hệ thống đi vào hoạt động.

Doanh nghiệp nên kết hợp secure coding, code review, vulnerability scanning và penetration testing vào vòng đời phát triển phần mềm.

9. Sử dụng WAF như một lớp bảo vệ bổ sung

Web Application Firewall có thể giúp phát hiện và ngăn chặn một số request chứa mẫu tấn công đã biết trước khi chúng tới ứng dụng.

Tuy nhiên, WAF không thể thay thế việc sửa lỗ hổng trong source code. Đặc biệt, những XSS xảy ra hoàn toàn phía client như một số trường hợp DOM-based XSS có thể không đi qua lớp kiểm tra request theo cách WAF có thể phát hiện.

Một số câu hỏi thường gặp về XSS

XSS viết tắt của từ gì?

XSS là viết tắt của Cross-Site Scripting. Ký hiệu XSS được sử dụng thay vì CSS để tránh nhầm lẫn với Cascading Style Sheets.

XSS có phải virus không?

Không. XSS là một dạng lỗ hổng và kỹ thuật tấn công trên ứng dụng web, không phải một loại virus máy tính.

Kẻ tấn công lợi dụng cách website xử lý dữ liệu để khiến nội dung ngoài ý muốn được trình duyệt của nạn nhân thực thi.

JavaScript có phải nguyên nhân gây ra XSS không?

Không.

JavaScript thường được sử dụng trong các cuộc tấn công XSS vì trình duyệt có khả năng thực thi JavaScript, nhưng bản thân JavaScript không phải lỗ hổng.

Nguyên nhân nằm ở cách ứng dụng xử lý dữ liệu không đáng tin cậy và đưa chúng vào những context có thể thực thi.

XSS có thể đánh cắp mật khẩu không?

XSS có thể được sử dụng để thu thập dữ liệu người dùng nhìn thấy hoặc nhập vào trang nếu điều kiện khai thác cho phép. Nó cũng có thể hỗ trợ giả mạo giao diện, đánh cắp token hoặc thực hiện hành động trong phiên người dùng.

Mức độ ảnh hưởng thực tế phụ thuộc vào vị trí lỗ hổng và các biện pháp bảo mật của ứng dụng.

WAF có chống được XSS không?

WAF có thể chặn một số request mang đặc điểm tấn công XSS nhưng không thể đảm bảo loại bỏ toàn bộ XSS.

Đặc biệt, WAF không xử lý được nguyên nhân gốc nằm trong source code và có thể không phát hiện những trường hợp DOM-based XSS diễn ra hoàn toàn ở phía client.

XSS và CSRF khác nhau như thế nào?

XSS tìm cách đưa và thực thi nội dung độc hại trong context của website, trong khi CSRF lợi dụng phiên đăng nhập sẵn có để khiến người dùng gửi một request mà họ không chủ động thực hiện.

Hai lỗ hổng có thể liên quan nhưng cần các biện pháp phòng chống khác nhau.

Kết luận

Hiểu XSS là gì giúp doanh nghiệp nhận diện một trong những rủi ro phổ biến đối với ứng dụng web. Reflected XSS, Stored XSS và DOM-based XSS có cơ chế khác nhau nhưng đều xuất phát từ việc dữ liệu không đáng tin cậy được xử lý trong context không an toàn.

VNPT Cloud cung cấp hệ sinh thái hạ tầng và giải pháp bảo mật giúp doanh nghiệp xây dựng, vận hành và bảo vệ ứng dụng trên môi trường Cloud. Doanh nghiệp có thể lựa chọn giải pháp phù hợp với quy mô hệ thống và yêu cầu bảo mật để nâng cao khả năng phòng vệ trước các mối đe dọa trên Internet.