Cross-Site Scripting (XSS) Là Gì? - Bizfly Cloud

• Techblog
• Security

XSS là gì? Tìm hiểu những thông tin chi tiết về XSSVinh Phạm172506-06-2018

Nhiều người nghĩ Cross-Site Scriptingkhông hề nguy hiểm, có lẽ vì họ nghĩ XSS đơn giản chỉ là sử dụng javascript tạo ra một hộp thoại thông báo. Cũng vì lý do đó mà nhiều Web-master thường chủ quan khi không lọc dữ liệu vào – ra (input – output). Trong bài này Bizfly Cloud sẽ tìm hiểu lỗ hổng XSS nó nguy hiểm như thế nào.

Cross-Site Scripting (XSS) là gì?

Cross-Site Scripting (còn được gọi là tấn công XSS) là một lỗ hổng bảo mật web cho phép kẻ tấn công xâm phạm các tương tác mà người dùng có với một ứng dụng dễ bị tấn công. Thay vì nhắm mục tiêu vào chính máy chủ của ứng dụng, các cuộc tấn công XSS thường nhắm mục tiêu trực tiếp vào người dùng của ứng dụng.

Kẻ tấn công thực thi các tập lệnh độc hại trong trình duyệt web của nạn nhân bằng cách đưa mã độc hại vào một trang web hoặc ứng dụng web hợp pháp. Cuộc tấn công thực sự xảy ra khi nạn nhân truy cập trang web hoặc ứng dụng web thực thi mã độc hại. Trang web hoặc ứng dụng web trở thành phương tiện cung cấp tập lệnh độc hại đến trình duyệt của người dùng. Cross-Site Scripting là một trong những kĩ thuật tấn công phổ biến nhất hiện nay, được liệt vào danh sách những kỹ thuật tấn công nguy hiểm nhất với ứng dụng web.

Các kiểu khai thác XSS

1. STORED-XSS

Stored XSS là dạng tấn công mà hacker chèn trực tiếp các mã độc vào website

Stored XSS là dạng tấn công mà hacker chèn trực tiếp các mã độc vào cơ sở dữ liệu của website. Dạng tấn công này xảy ra khi các dữ liệu được gửi lên server không được kiểm tra kỹ lưỡng mà lưu trực tiếp vào cơ sở dữ liệu. Khi người dùng truy cập vào trang web này thì những đoạn script độc hại sẽ được thực thi chung với quá trình load trang web.

Ví dụ như chức năng comment trong blog, website, message... Ví dụ dưới đây minh họa cho Stored-XSS. Để demo mình tạo trang comment dính lỗ hổng bảo mật XSS như sau:

Giờ ta thử thay nội dung comment bằng đoạn JavaScript cơ bản để Test XSS:

Một hộp thoại thông báo hiện lên, như vậy hệ thống đã dính XSS:

Ví dụ 1: Thay đổi toàn bộ liên kết trong một trang web, link sang 1 trang web khác.

<a href="http://vnexpress.net/">Xiaomi ra smartphone trông giống Galaxy Note 7 a><br>

Chèn mã javascript để thay đổi link:

Kết quả:

Ví dụ 2: Deface website với XSS

Thay đổi background

Kết quả sau khi thay đổi:

Mở rộng:

Trường hợp nếu một trang đăng nhập bị dính lỗi bảo mật XSS sẽ nguy hiểm như nào? Hacker/Attacker có thể thay đổi action sang một tệp PHP khác xử lý các giá trị nhận được bao gồm tài khoản, mật khẩu thậm chí là các thông tin nhạy cảm khác tùy vào nơi dính lỗ hổng XSS là khu vực đăng nhập, đăng ký, thanh toán,… Hacker/Attacker hoàn toàn có thể lưu lại (log) sau đó giả mạo việc đăng nhập bằng cách gửi trả (POST) dữ liệu tới tệp tin xử lý thật của Form ban đầu.

2. Reflected XSS

Khác với Stored-XSS, Reflected-XSS đoạn mã khai thác sẽ không được lưu trữ trên server. Một ví dụ điển hình của Reflected-XSS là kết quả trả về của module search:

Reflected XSS là dạng tấn công thường gặp nhất trong các loại hình XSS

Reflected XSS là dạng tấn công thường gặp nhất trong các loại hình XSS. Với Reflected XSS, hacker không gửi dữ liệu độc hại lên server nạn nhân, mà gửi trực tiếp link có chứa mã độc cho người dùng, khi người dùng click vào link này thì trang web sẽ được load chung với các đoạn script độc hại. Reflected XSS thường dùng để ăn cắp cookie, chiếm session,… của nạn nhân hoăc cài keylogger, trojan … vào máy tính nạn nhân.

Có nhiều hướng để khai thác thông qua lỗi Reflected XSS, một trong những cách được biết đến nhiều nhất là chiếm phiên làm việc (session) của người dùng, từ đó có thể truy cập được dữ liệu và chiếm được quyền của họ trên website.

Dạng tấn công bằng Reflected XSS được mô tả như sau:

Trước tiên, hacker sẽ gửi cho nạn nhân một đường link có chứa mã độc hại đi kèm, ví dụ:

http://victim.com/index.php?id=<script>alert(document.cookie) script>

Để cho người dùng khó phát hiện nên khi gửi đường link trên cho nạn nhân, hacker có thể sẽ mã hoá nó thành những ký tự lạ khó đọc, ví dụ:

Như vậy, nạn nhân sẽ không nghi ngờ đường link lạ, và click vào link.

Khi nạn nhân click vào đường link được hacker gửi, trình duyệt sẽ load trang web và thực thi các đoạn script kèm theo, sau đó gửi về cho hacker những thông tin của nạn nhân.

Từ phía site của mình, hacker sẽ bắt được nội dung request trên và coi như session của người dùng sẽ bị chiếm. Đến lúc này, hacker có thể giả mạo với tư cách nạn nhân và thực hiện mọi quyền trên website mà nạn nhân có.

>>> Xem thêm: Tấn công XSS và phòng thủ

3. DOM-based XSS

Một kiểu tấn công XSS khác là DOM-based XSS (còn được gọi là DOM XSS), nơi lỗ hổng bảo mật tồn tại trong các tập lệnh phía máy khách mà trang web/ứng dụng luôn cung cấp cho khách truy cập. Cuộc tấn công này khác với Reflected XSS và STORED-XSS ở chỗ trang web/ứng dụng không phân phối trực tiếp tập lệnh độc hại đến trình duyệt của mục tiêu. Trong một cuộc tấn công DOM-based XSS, trang web/ứng dụng có các tập lệnh phía máy khách dễ bị tấn công sẽ phân phối tập lệnh độc hại đến trình duyệt của mục tiêu. Tương tự như Reflected XSS, một cuộc tấn công DOM-based XSS không lưu trữ tập lệnh độc hại trên chính máy chủ dễ bị tấn công.

Xem ví dụ bên dưới về trang chào mừng trong ứng dụng web, trang này truy xuất tham số URL để điền tên người dùng.

<HTML>

<TITLE>Welcome!</TITLE>

Hi

<SCRIPT>

var pos=document.URL.indexOf("name=")+5;

document.write(document.URL.substring(pos,document.URL.length));

</SCRIPT>

<BR>

Welcome

…

</HTML>

Trang này sử dụng tham số URL để nhập tên người dùng, như sau:

http://www.vulnerable.site/welcome.html?name=Jill

Nhưng một người dùng độc hại có thể đưa mã JavaScript vào yêu cầu, như thế này:

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

Ngăn ngừa, lọc và vá các lỗ hổng XSS

Trong một số trường hợp, việc ngăn chặn XSS là việc đơn giản nhưng có thể khó hơn nhiều tùy thuộc vào độ phức tạp của ứng dụng và cách ứng dụng xử lý dữ liệu do người dùng kiểm soát.

Bạn có thể ngăn chặn hiệu quả các lỗ hổng XSS có thể bao gồm sự kết hợp của các biện pháp sau:

• Lọc input. Không tin tưởng bất kỳ input của người dùng, coi tất cả input là không đáng tin cậy. Bất kỳ input nào của người dùng được sử dụng như một phần của output HTML đều dẫn đến rủi ro về XSS. Tại thời điểm nhận được thông tin input của người dùng, hãy lọc càng chặt chẽ càng tốt dựa trên những gì được mong đợi hoặc input hợp lệ.
• Mã hóa dữ liệu output. Tại điểm mà dữ liệu do người dùng kiểm soát được xuất ra trong các phản hồi HTTP, hãy mã hóa output để ngăn nó được hiểu là active content. Tùy thuộc vào ngữ cảnh output, có thể yêu cầu áp dụng kết hợp mã hóa HTML, URL, JavaScript và CSS.
• Sử dụng HTTPOnly cookie flag. Rất khó để ngăn chặn tất cả các lỗi XSS trong ứng dụng của bạn. Để giảm tác động của các lỗ hổng XSS, hãy sử dụng HTTPOnly cookie flag — nếu trình duyệt hỗ trợ, nó đảm bảo rằng các tập lệnh phía máy khách không thể truy cập cookie, ngăn chặn các cuộc tấn công XSS một cách hiệu quả.
• Sử dụng tiêu đề phản hồi thích hợp. Để ngăn XSS trong phản hồi HTTP không có ý định chứa bất kỳ HTML hoặc JavaScript nào, bạn có thể sử dụng tiêu đề Content-Type và X-Content-Type-Options để đảm bảo rằng các trình duyệt diễn giải phản hồi theo cách bạn mong muốn.
• Chính sách Bảo mật Nội dung. Là tuyến phòng thủ cuối cùng, bạn có thể sử dụng Chính sách bảo mật nội dung (CSP - Content Security Policy) để giảm mức độ nghiêm trọng của bất kỳ lỗ hổng XSS nào vẫn xảy ra.

Xu hướng tấn công XSS

Các lỗ hổng XSS hiện được xếp hạng trong số 10 lỗ hổng bảo mật quan trọng ảnh hưởng đến doanh nghiệp. Tỷ lệ cao nhất của các cuộc tấn công XSS được báo cáo là vào năm 2013. Xu hướng tấn công XSS đã giảm đáng kể khi các công ty tăng cường phòng thủ hơn.

Theo IBM, 17% trong số 900 lần quét ứng dụng Web động cho thấy có lỗ hổng XSS. Tuy nhiên, dữ liệu này đến từ các tổ chức có thực tiễn bảo mật mạnh mẽ và trưởng thành nhất. Một nghiên cứu của White Hat Security cho thấy gần một nửa số trang web (47,9%) dễ bị tấn công XSS.

Một báo cáo của HackerOne năm 2020 cho thấy lỗ hổng XSS chiếm 18% tổng số các vấn đề an ninh mạng. Trên thực tế, số tiền mà các công ty trả cho những lỗi này đã tăng 26% so với năm 2019.

Nghiên cứu cũng chỉ ra rằng các cuộc tấn công XSS có xu hướng nhắm vào ngành Giải trí, trong đó có Fortnite - một trò chơi điện tử trực tuyến phổ biến. Thông qua một trang web không hoạt động, những kẻ tấn công có thể truy cập dữ liệu cá nhân của 200 triệu người chơi Fortnite mà không cần bất kỳ thông tin đăng nhập nào.

Các ngành Tài chính, Giáo dục, CNTT, Chính phủ và Giao thông cũng là những mục tiêu phổ biến. Một báo cáo năm 2019 của Akamai cho thấy 75% các cuộc tấn công vào các dịch vụ tài chính nhắm mục tiêu trực tiếp đến các API. Tổng cộng có 50,7 triệu cuộc tấn công nhắm vào các dịch vụ tài chính có liên quan đến XSS.

TAGS: XSSSHAREFacebookTwitter