XSS là gì? Nhận diện và phòng chống lỗ hổng web

Với doanh nghiệp có website bán hàng, trang thành viên, biểu mẫu liên hệ hoặc khu vực bình luận, XSS không chỉ là chuyện của đội kỹ thuật. Nó có thể dẫn đến mất phiên đăng nhập, đánh cắp thông tin và ảnh hưởng trực tiếp đến niềm tin vào thương hiệu của bạn.

XSS là gì và vì sao nó phá vỡ niềm tin trên website?

XSS là viết tắt của Cross-Site Scripting, một lỗ hổng cho phép kẻ tấn công chèn mã độc, thường là JavaScript, vào nội dung của website. Khi nội dung đó được hiển thị, trình duyệt của người dùng có thể thực thi mã độc như thể đó là mã hợp lệ đến từ chính website.

Hãy hình dung kẻ xấu gửi một bức thư có nội dung nguy hiểm vào một nơi bạn tin cậy. Website vô tình hiển thị nguyên bức thư đó, còn trình duyệt lại tin rằng mọi thứ trên trang đều an toàn. Kết quả là mã độc có cơ hội chạy trong bối cảnh của tên miền hợp pháp.

Điểm nghiêm trọng nằm ở việc XSS làm suy yếu Same Origin Policy. Chính sách này vốn giúp cô lập dữ liệu giữa các website khác nhau, tương tự mỗi ngôi nhà có không gian riêng. Khi mã độc chạy trên website của bạn, nó có thể tiếp cận dữ liệu mà trình duyệt đang dành cho website đó, bao gồm cookie và session token.

Ba dạng tấn công XSS bạn cần phân biệt

Không phải mọi cuộc tấn công XSS đều hoạt động giống nhau. Ba dạng chính khác nhau ở nơi mã độc xuất hiện, cách nó được phát tán và mức độ ảnh hưởng đến người dùng.

Reflected XSS: cái bẫy nằm trong một yêu cầu

Reflected XSS, hay XSS phản chiếu, thường xuất hiện khi kẻ tấn công tạo một đường dẫn có chứa dữ liệu độc hại. Dữ liệu này có thể nằm trong tham số tìm kiếm hoặc một yêu cầu gửi tới website.

Nếu hệ thống phản hồi và hiển thị lại dữ liệu đó mà không xử lý an toàn, mã độc sẽ được trả về trình duyệt. Hình thức này chỉ xảy ra khi nạn nhân tương tác, chẳng hạn nhấp vào đường dẫn đã được chuẩn bị sẵn. Nó giống một cái bẫy tạm thời, người dùng phải bước vào thì cuộc tấn công mới xảy ra.

Stored XSS: mã độc được cài sẵn trên máy chủ

Stored XSS, hay XSS lưu trữ, nguy hiểm hơn vì mã độc được lưu lâu dài trên máy chủ. Nó có thể nằm trong bình luận, bài đăng diễn đàn hoặc dữ liệu được ghi vào cơ sở dữ liệu.

Mỗi khi ai đó truy cập khu vực chứa nội dung này, mã độc có thể tự chạy trên trình duyệt của họ. Không cần tiếp tục gửi đường dẫn lừa đảo, một đoạn mã được lưu sẵn có thể tác động đến rất nhiều người truy cập. Đây là lý do Stored XSS thường được xem là dạng có mức độ nghiêm trọng cao hoặc rất cao.

DOM-based XSS: lỗ hổng ẩn hoàn toàn trong trình duyệt

DOM-based XSS diễn ra ở phía máy khách, tức là bên trong trình duyệt. Mã độc thao túng DOM, cấu trúc nội dung của trang, mà không nhất thiết phải gửi dữ liệu nguy hiểm về máy chủ.

Đây là dạng đặc biệt khó phát hiện bằng các công cụ chỉ kiểm tra phía máy chủ. Vì vậy, bạn cần kiểm soát cách JavaScript lấy dữ liệu từ đường dẫn, biểu mẫu hoặc các nguồn đầu vào khác rồi đưa chúng vào DOM.

Dạng XSS	Nơi mã độc xuất hiện	Điều kiện kích hoạt	Mức độ rủi ro
Reflected XSS	Trong yêu cầu hoặc đường dẫn	Người dùng cần tương tác	Trung bình
Stored XSS	Trên máy chủ hoặc cơ sở dữ liệu	Chỉ cần truy cập nội dung chứa mã độc	Cao đến rất cao
DOM-based XSS	Trong DOM phía trình duyệt	JavaScript xử lý đầu vào không an toàn	Khó phát hiện, tùy phạm vi ảnh hưởng

Hậu quả của XSS đối với website và khách hàng

Khi khai thác thành công XSS, kẻ tấn công không chỉ làm biến dạng giao diện. Họ có thể chiếm đoạt phiên đăng nhập đang hoạt động, đánh cắp thông tin đăng nhập hoặc chèn biểu mẫu giả để thực hiện hành vi lừa đảo.

Mã độc cũng có thể bị dùng để phân phối phần mềm độc hại hoặc biến trình duyệt của nạn nhân thành công cụ đào tiền ảo. Với doanh nghiệp, hậu quả còn là khiếu nại từ khách hàng, suy giảm uy tín và chi phí xử lý sự cố sau tấn công.

Đây không phải rủi ro chỉ có ở các website nhỏ. Năm 2020, một lỗ hổng DOM-based XSS trong quy trình đăng nhập của Facebook đã cho phép chiếm đoạt tài khoản chỉ bằng một cú nhấp chuột. Năm 2022, Zoom Desktop Client được phát hiện có lỗ hổng Reflected XSS. Đến năm 2023, nhiều plugin WordPress phổ biến bị khai thác XSS, ảnh hưởng đến hàng chục nghìn website.

Ba lớp phòng thủ cốt lõi để chống XSS

Không có một biện pháp đơn lẻ nào đủ để loại bỏ toàn bộ rủi ro. Website của bạn cần kết hợp kiểm soát đầu vào, xử lý đầu ra và chính sách hạn chế khả năng chạy mã không đáng tin cậy.

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

Nguyên tắc đầu tiên là không mặc định tin dữ liệu do người dùng cung cấp. Nội dung từ biểu mẫu, bình luận, thanh tìm kiếm, tham số đường dẫn và dữ liệu từ hệ thống bên ngoài đều cần được kiểm tra trước khi xử lý hoặc lưu trữ.

Bạn nên xác định rõ dữ liệu nào được phép nhận, định dạng nào hợp lệ và ký tự nào không phù hợp với nhu cầu nghiệp vụ. Việc xác thực đầu vào giúp giảm khả năng dữ liệu nguy hiểm đi sâu vào hệ thống.

2. Mã hóa dữ liệu đầu ra theo đúng ngữ cảnh

Đây là lớp phòng thủ quan trọng nhất. Khi hiển thị dữ liệu không đáng tin trên trang, bạn cần mã hóa dữ liệu để trình duyệt hiểu đó là văn bản, thay vì coi nó là mã HTML hoặc JavaScript có thể thực thi.

Ngữ cảnh hiển thị rất quan trọng. Dữ liệu xuất hiện trong HTML, URL, JavaScript hoặc CSS cần được xử lý phù hợp với từng ngữ cảnh. Với những trường hợp buộc phải cho phép nội dung HTML, thư viện DOMPurify có thể hỗ trợ làm sạch nội dung trước khi đưa lên trang.

3. Thiết lập Content Security Policy

Content Security Policy, thường gọi là CSP, hoạt động như danh sách nguồn mã được phép chạy trên trình duyệt. Chính sách này giúp giới hạn script chỉ được tải từ các nguồn đáng tin cậy mà bạn đã khai báo.

CSP không thay thế cho xác thực đầu vào và mã hóa đầu ra, nhưng nó là lớp bảo vệ bổ sung rất giá trị nếu vẫn có lỗi lọt qua. Bạn có thể tham khảo hướng dẫn Content Security Policy để hiểu cách áp dụng chính sách này trên máy chủ.

Những sai lầm khiến website dễ bị XSS

• Hiển thị trực tiếp dữ liệu người dùng: Nội dung bình luận, tên hiển thị hoặc từ khóa tìm kiếm được đưa lên trang mà không mã hóa an toàn.
• Chỉ kiểm tra phía máy chủ: Điều này dễ bỏ sót DOM-based XSS phát sinh từ JavaScript chạy trong trình duyệt.
• Cho phép HTML tùy ý: Khi website hỗ trợ nội dung phong phú nhưng không làm sạch HTML, vùng nhập liệu có thể trở thành điểm chèn mã độc.
• Xem CSP là giải pháp duy nhất: CSP là lớp bổ sung, không thể thay thế xác thực đầu vào và mã hóa đầu ra.
• Để bảo mật ở giai đoạn cuối: Khi thiết kế và lập trình đã hoàn tất mới kiểm tra bảo mật, chi phí sửa lỗi thường cao hơn nhiều.

Tư duy bảo mật phải bắt đầu từ lúc viết mã

Bảo mật không phải là một tính năng để thêm vào sau khi website đã vận hành. Nó là một tư duy cần có từ khi thiết kế luồng dữ liệu, chọn cách hiển thị nội dung và viết từng phần mã xử lý đầu vào.

Bảo mật không phải là một tính năng, đó là một tư duy.

Ngay cả những nền tảng lớn vẫn có thể có lỗ hổng. Vì vậy, thay vì giả định website của mình an toàn, bạn nên xây dựng quy trình rà soát định kỳ, kiểm tra các điểm nhận dữ liệu và đánh giá lại cách ứng dụng hiển thị nội dung do người dùng cung cấp.

Để có hướng dẫn chi tiết hơn về cách phòng ngừa, bạn có thể đối chiếu quy trình phát triển của đội ngũ với danh sách thực hành phòng chống XSS của OWASP.

Câu hỏi thường gặp

XSS có phải là virus không?

Không. XSS là lỗ hổng bảo mật web cho phép mã độc chạy trong trình duyệt thông qua một website đáng tin cậy. Nó không phải virus, nhưng hậu quả có thể bao gồm đánh cắp phiên đăng nhập và thông tin đăng nhập.

Dạng XSS nào nguy hiểm nhất?

Stored XSS thường nguy hiểm nhất vì mã độc được lưu trên máy chủ và có thể tấn công bất kỳ ai truy cập nội dung chứa mã đó. Một lần chèn thành công có thể tạo ra phạm vi ảnh hưởng lớn.

CSP có thể ngăn hoàn toàn XSS không?

Không. CSP giúp hạn chế nguồn script được phép chạy và giảm thiểu thiệt hại khi có lỗi xảy ra. Bạn vẫn cần xác thực dữ liệu đầu vào và mã hóa dữ liệu đầu ra đúng ngữ cảnh.

Nếu website của bạn có biểu mẫu, khu vực thành viên hoặc nội dung do khách hàng tạo, một quy trình thiết kế website và bảo mật nền tảng bài bản sẽ giúp kiểm soát rủi ro XSS ngay từ kiến trúc hệ thống.