XSS là gì? Giới thiệu và cách phòng tránh.

Một phần khá thú vị trong "Bảo mật nhập môn" của tác giả Phạm Huy Hoàng, đưa cái nhìn trực quan về XSS, bài viết này mình xin trích dẫn một phần trong đó.

Giới thiệu về XSS

XSS (Cross Site Scripting) là một lỗi bảo mật cho phép hacker nhúng mã độc (javascript) vào một trang web khác. Hacker có thể lợi dụng mã độc này để deface trang web, cài keylog, chiếm quyền điều khiển của người dùng, dụ dỗ người dùng tải virus về máy.
Các bạn có thể xem thêm demo trong vụ hack Lotte Cinema trước đây. Đây là một trong những lỗi bảo mật thường gặp nhất trên các trang Web.
Các hệ thống từ lớn đến nhỏ như Facebook, Twitter, một số forum Việt Nam, ... đều từng dính phải lỗi này.
Do mức độ phổ biến và độ nguy hiểm của nó, XSS luôn được vinh dự được nằm trong top 10 lỗi bảo mật nghiêm trọng nhất trên OWASP (Open Web Application Security Project).

Để tóm tắt, xin trích dẫn vài câu của thánh bảo mật Juno_okyo, người vừa hack 3 triệu tài khoản của server X nào đó.

"Ờ thì nghe cũng có vẻ nguy hiểm đấy, nhưng sao tôi thấy ông hay viết về XSS thế? Rảnh quá hả!?"
À... một lỗi vừa phổ biến, nằm top 10 OWASP, lại vừa nguy hiểm, có thể kết hợp tốt với các lỗi khác. Nhưng dễ tìm, dễ fix, đã thế còn được tính bug bounty nữa.

Những dạng XSS

Trước đây, XSS thường nhắm vào code render HTML từ phía Server, ta gọi là Server XSS. Hai dạng Server XSS thường gặp là Persistent XSS và Reflected XSS.

Ở đây, mình sẽ lấy một thanh niên tên Khoa ra làm ví dụ. Khoa là một sinh viên ĐH FPT, là fan của blog tôi đi code dạo, thích lên thi*ndia để tìm địa điểm mát xa.

1. Persistent XSS
Trên forum thi*ndia, khi bạn post một comment vào topic, server sẽ lưu comment bạn post và hiển thị dưới dạng HTML. Khi Khoa post “Em muốn tìm JAV”, server sẽ lưu lại và hiển thị như sau:

<div class="comment">
<p>Em muốn tìm JAV</p>
</div>

Tuy nhiên, Khoa lại không hiền lành như thế. Do mới học về XSS, Khoa không nhập text mà nhập nguyên đoạn script alert(‘XXX’) vào khung comment. Lúc này, HTML của trang web sẽ trở thành:

<div class="comment">
<p><script>alert('XXX')</script></p>
</div>

Trình duyệt sẽ chạy đoạn script này, hiển thị cửa sổ alert lên. Khoa đã chèn được mã độc vào thi*ndia, thực hiện tấn công XSS thành công. (Lưu ý: Mình chỉ ví dụ thôi, thi*ndia không bị lỗi XSS đâu nhé, các bạn không nên thử).

Trong kiểu tấn công này, mã độc đựợc lưu trong database trên server, hiển thị ra với toàn bộ người dùng, do đó ta gọi nó là Persistance XSS. Bất kì ai thấy comment của Khoa đều bị dính mã độc này, do đó kiểu tấn công này có tầm ảnh hưởng lớn, khá nguy hiểm.

2. Reflected XSS
Với cách tấn công này, hacker chèn mã độc vào URL dưới dạng query string. Khi người dùng ngáo ngơ nhấp vào URL này, trang web sẽ đọc query string, render mã độc vào HTML và người dùng “dính bẫy”.

Quay lại với Khoa. Do xin địa chỉ mát xa hoài nhưng không được share, Khoa cay cứ, quyết định trả thù các đàn anh. Khoa bèn gửi đường một đường link giả JAV vào mail các đàn anh.

Nội dung đường link: http://thi*ndia.com?q=<script>deleteAccount();</script>.

Khi các đàn anh click link này, họ sẽ vào trang thiendia. Sau đó server sẽ render <script>deleteAccount(); </script>, gọi hàm deleteAccount trong JavaScript để xoá account của họ.

Tầm ảnh hưởng của ReflectedXSS không rộng bằng Persistance XSS, nhưng mức độ nguy hiểm là tương đương. Hacker thường gửi link có mã độc qua email, tin nhắn, ... và dụ dỗ người dùng click vào. Do đó các bạn đừng vì ham JAV mà click link bậy bạ nhé.

3. Client XSS
Gần đây, khi JavaScript dần được sử dụng nhiều hơn, các lỗi Client XSS cũng bị lợi dụng nhiều hơn. Do JavaScript được sử dụng để xử lý DOM, mã độc được chèn thẳng vào trong JavaScript.Các lỗ hỗng dạng này khó tìm và phát hiện hơn Server XSS nhiều (Xem ví dụ: http://kipalog.com/posts/To-da-hack-trang-SinhVienIT-net-nhu-the-nao).

Cách phòng tránh

1. Encoding
Không được tin tưởng bất kì thứ gì người dùng nhập vào!! Hãy sử dụng hàm encode có sẵn trong ngôn ngữ/framework để chuyển các kí tự < > thành < %gt;.

2. Validation/Sanitize
Một cách chống XSS khác là validation: loại bỏ hoàn toàn các kí tự khả nghi trong input của người dùng, hoặc thông báo lỗi nếu trong input có các kí tự này.

Ngoài ra, nếu muốn cho phép người dùng nhập vào HTML, hãy sử dụng các thư viện sanitize.

Các thư viện này sẽ lọc các thẻ HTML, CSS, JS nguy hiểm để chống XSS. Người dùng vẫn có thể sử dụng các thẻ <p>, <span>, <ul> để trình bày văn bản.

Làm ơn, xin nhắc lại, làm ơn dùng các thư viện sẵn có chứ đừng “hổ báo” viết lại để thể hiện trình độ. Đã có rất nhiều trường hợp dính lỗi XSS vì developer tự tin và tự viết code để loại bỏ kí tự đặc biệt và... để sót.

3. CSP (Content Security Policy)
Hiện tại, ta có thể dùng chuẩn CSP để chống XSS. Với CSP, trình duyệt chỉ chạy JavaScript từ những domain được chỉ định. Giả sử thiendia.com có sử dụng CSP, chỉ chạy JavaScript có nguồn gốc thiendia.com. Vì Khoa để mã độc trên khoatran.com nên đoạn JavaScipt sau sẽ không được thực thi.

<div class="comment">
<p><script src="//khoatran.com/madoc.js"></script></p>
</div>

Để sử dụng CSP, server chỉ cần thêm header Content-Security-Policy vào mỗi response. Nội dung header chứa những domain mà ta tin tưởng.

Lời kết

Nói hơi chủ quan tí (do mình ko ưa PHP), số lượng trang web xây dựng bằng PHP bị lỗi XSS là nhiều nhất. Lí do thứ nhất là do số lượng web viết bằng PHP cực nhiều. Lí do thứ hai là mặc định PHP không encode các kí tự lạ. Các CMS của PHP như WordPress, Joomla rất mạnh với vô số plug-in. Tuy nhiên nhiều plug-in viết ẩu là nguyên nhân dẫn đến lỗi bảo mật này.

Hiện tại, số lượng website bị lỗi XSS là khá nhiều, các bạn chỉ cần lang thang trên mạng là sẽ gặp. Như mình đã nói, XSS là một lỗi rất cơ bản, hầu như hacker nào cũng biết. Trang web bị lỗi này rất dễ thành mồi ngon cho hacker. Do vậy, các bạn developer nhớ cẩn thận, đừng để web của mình bị dính lỗi này.

Một số link tham khảo: