Series bảo mật nhập môn – lỗ hỏng bảo mật xss nguy hiểm đến mức nào?

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 toidicodedao, thích lên thiendia để tìm địa điểm mátxa.

1. Persistent XSS

Trên forum thiendia, 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:

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:

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 thiendia, thực hiện tấn công XSS thành công. (Lưu ý: Mình chỉ ví dụ thôi, thiendia 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ớ, 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://thiendia.com?q=<scrit>deleteAccount();</scrit> .

Khi các đàn anh click link này, họ sẽ vào trang thiendia. Sau đó server sẽ render <scrit>deleteAccount();</scrit>, 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é,

(Vì wordpress tự động lọc tag script nên mình phải để thành scrit. Các bạn đọc về “Chống XSS” ở phần dưới).

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

Tôn chỉ của series “Bảo mật nhập môn” là : Hack để học, chứ đừng học để hack. Mục tiêu của mình không phải là hướng dẫn các bạn đi hack và quậy phá các site khác, mà là dạy bạn biết và phòng chống những đòn tấn công này.

Vì XSS là một dạng tấn công hay gặp, dễ gây hậu quả cao nên hầu như các Web Framework nổi tiếng (Spring, Django, ASP.NET MVC) đều tích hợp sẵn cách phòng chống. Dù bạn là dân ngoại đạo, không biết gì về XSS, chỉ cần sử dụng framework bản mới nhất là đã đề phòng được kha khá lỗi rồi.

Lỗi XSS này cũng khá dễ fix, quan trọng là lỗi này thường gặp ở nhiều trang, dễ sót, do đó sau khi fix ta phải verify cần thận. Có 3 phương pháp thường dùng fix lỗi này:

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 &lt; %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.

Để 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. Vì lý do đạo đức, mong các bạn noi gương anh juno_okyo, khi phát hiện thì thông báo cho admin để người ta sửa chứ đừng chơi trò hack “trẻ trâu” như mình nhé.

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.

Ai code xong rồi thì về check xem mình có dính không, ai đang code thì vừa code vừa check lại. Nhớ like và share bài viết này với nhiều developer để mọi người cùng phòng tránh nhé.

Một số link tham khảo:

• http://excess-xss.com/
• https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
• http://kipalog.com/posts/Lo-hong-bao-mat-Cross-Site-Scripting–XSS–co-gi-nguy-hiem

Techtalk via toidicodedao