Testing sercurity

Kiểm tra lỗ hổng bảo mật DOM-Based Cross Site Scripting

Rate this post

DOM Based XSS là gì?

DOM Based XSS (hoặc “type-0 XSS”) là một cuộc tấn công XSS trong đó payload tấn công được thực thi do sửa đổi “môi trường” DOM trong trình duyệt của nạn nhân được phía client ban đầu sử dụng để side script phía client chạy một cách “không mong muốn”.

DOM-Based Cross Site Scripting là tên thực tế của các lỗi XSS là kết quả của nội dung phía trình duyệt đang hoạt động trên một trang, thường là JavaScript, lấy thông tin đầu vào của người dùng thông qua một nguồn và sử dụng nó trong một Sinks, dẫn đến việc thực thi của mã được tiêm. Tài liệu này chỉ thảo luận về các lỗi JavaScript dẫn đến XSS.

Các bài viết liên quan:

DOM, hoặc Mô hình Đối tượng Tài liệu, là định dạng cấu trúc được sử dụng để biểu diễn tài liệu trong trình duyệt. DOM cho phép các tập lệnh động như JavaScript tham chiếu đến các thành phần của tài liệu như trường biểu mẫu hoặc cookie phiên. DOM cũng được trình duyệt sử dụng để bảo mật – ví dụ: để hạn chế các tập lệnh trên các miền khác nhau lấy cookie phiên cho các miền khác. Lỗ hổng XSS dựa trên DOM có thể xảy ra khi nội dung đang hoạt động, chẳng hạn như hàm JavaScript, được sửa đổi bởi một yêu cầu được tạo thủ công đặc biệt để một phần tử DOM có thể bị kẻ tấn công kiểm soát.

Không phải tất cả các lỗi XSS đều yêu cầu kẻ tấn công kiểm soát nội dung trả về từ máy chủ, nhưng thay vào đó có thể lạm dụng các phương pháp mã hóa JavaScript kém để đạt được kết quả tương tự. Hậu quả giống như một lỗ hổng XSS điển hình, chỉ khác là phương tiện phân phối.

So với các loại lỗ hổng cross site scripting khác (được phản ánh và lưu trữ, trong đó một tham số chưa được làm sạch được máy chủ chuyển qua sau đó trả lại cho người dùng và được thực thi trong ngữ cảnh trình duyệt của người dùng, lỗ hổng XSS dựa trên DOM kiểm soát luồng của mã bằng cách sử dụng các phần tử của Mô hình đối tượng tài liệu (DOM) cùng với mã do kẻ tấn công tạo ra để thay đổi luồng.

Do bản chất của chúng, các lỗ hổng XSS dựa trên DOM có thể được thực thi trong nhiều trường hợp mà máy chủ không thể xác định những gì đang thực sự được thực thi. Điều này có thể làm cho nhiều kỹ thuật phát hiện và lọc XSS chung bất lực trước các cuộc tấn công như vậy.

Ví dụ giả định này sử dụng mã phía máy khách sau:

<script>
document.write("Site is at: " + document.location.href + ".");
</script>

Kẻ tấn công có thể thêm # <script> alert (‘xss’) </script> vào URL trang bị ảnh hưởng, khi được thực thi, sẽ hiển thị hộp cảnh báo. Trong trường hợp này, mã được nối thêm sẽ không được gửi đến máy chủ vì mọi thứ sau ký tự # không được trình duyệt coi là một phần của truy vấn mà là một đoạn. Trong ví dụ này, mã được thực thi ngay lập tức và cảnh báo về “xss” được hiển thị trên trang. Không giống như các loại cross site scripting phổ biến hơn (được phản ánh và lưu trữ trong đó mã được gửi đến máy chủ và sau đó quay lại trình duyệt, điều này được thực thi trực tiếp trong trình duyệt của người dùng mà không cần liên hệ với máy chủ.

Hậu quả của các lỗ hổng XSS dựa trên DOM cũng rộng như những lỗi được thấy trong các dạng XSS được biết đến nhiều hơn, bao gồm truy xuất cookie, thêm tập lệnh độc hại, v.v. và do đó cần được xử lý với mức độ nghiêm trọng như nhau.

Các bài viết khác:

Mục tiêu kiểm tra

Xác định phần chìm DOM.

Xây dựng tải trọng phù hợp với mọi loại bồn rửa.

Làm thế nào để kiểm tra

Các ứng dụng JavaScript khác biệt đáng kể so với các loại ứng dụng khác vì chúng thường được tạo động bởi máy chủ. Để hiểu mã nào đang được thực thi, trang web đang được kiểm tra cần được thu thập thông tin để xác định tất cả các trường hợp JavaScript đang được thực thi và nơi chấp nhận đầu vào của người dùng. Nhiều trang web dựa vào các thư viện chức năng lớn, thường trải dài hàng trăm nghìn dòng mã và chưa được phát triển nội bộ. Trong những trường hợp này, kiểm tra từ trên xuống thường trở thành lựa chọn khả thi duy nhất, vì nhiều chức năng cấp dưới không bao giờ được sử dụng và việc phân tích chúng để xác định đâu là phần chìm sẽ sử dụng nhiều thời gian hơn bình thường. Điều tương tự cũng có thể được nói đối với kiểm tra từ trên xuống nếu các đầu vào hoặc thiếu chúng không được xác định để bắt đầu.

Đầu vào của người dùng có hai dạng chính:

  • Đầu vào được máy chủ ghi vào trang theo cách không cho phép XSS trực tiếp và
  • Đầu vào thu được từ các đối tượng JavaScript phía máy khách.

Dưới đây là hai ví dụ về cách máy chủ có thể chèn dữ liệu vào JavaScript:

var data = `“<escaped data from the server>”`;
var result = someFunction(`“<escaped data from the server>”`);

Dưới đây là hai ví dụ về đầu vào từ các đối tượng JavaScript phía máy khách:

var data = window.location;`
var result = someFunction(window.referrer);

Mặc dù có một chút khác biệt với mã JavaScript về cách chúng được truy xuất, nhưng điều quan trọng cần lưu ý là khi nhận đầu vào thông qua máy chủ, máy chủ có thể áp dụng bất kỳ hoán vị nào cho dữ liệu mà nó mong muốn. Mặt khác, các hoán vị được thực hiện bởi các đối tượng JavaScript được hiểu và ghi lại khá rõ ràng. Nếu someFunction trong ví dụ trên là một dấu chìm, thì khả năng khai thác trong trường hợp trước sẽ phụ thuộc vào việc lọc được thực hiện bởi máy chủ, trong khi trong trường hợp sau, nó sẽ phụ thuộc vào mã hóa do trình duyệt thực hiện trên đối tượng window.referrer. Stefano Di Paulo đã viết một bài báo xuất sắc về những gì trình duyệt trả lại khi được yêu cầu cung cấp các phần tử khác nhau của URL bằng cách sử dụng thuộc tính tài liệu và vị trí.

Ngoài ra, JavaScript thường được thực thi bên ngoài các khối <script>, bằng chứng là nhiều vectơ đã dẫn đến việc bỏ qua bộ lọc XSS trong quá khứ. Khi thu thập thông tin ứng dụng, điều quan trọng cần lưu ý là sử dụng tập lệnh ở những nơi như trình xử lý sự kiện và khối CSS có thuộc tính biểu thức. Ngoài ra, hãy lưu ý rằng bất kỳ đối tượng CSS hoặc script nào bên ngoài trang web sẽ cần được đánh giá để xác định mã nào đang được thực thi.

Thử nghiệm tự động chỉ đạt được thành công rất hạn chế trong việc xác định và xác thực XSS dựa trên DOM vì nó thường xác định XSS bằng cách gửi một trọng tải cụ thể và cố gắng quan sát nó trong phản hồi của máy chủ. Điều này có thể hoạt động tốt đối với ví dụ đơn giản được cung cấp bên dưới, trong đó tham số thông báo được phản ánh trở lại người dùng:

<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>

Tuy nhiên, nó có thể không được phát hiện trong trường hợp giả định sau:

<script>
var navAgt = navigator.userAgent;

if (navAgt.indexOf("MSIE")!=-1) {
        document.write("You are using IE as a browser and visiting site: " + document.location.href + ".");
}
else
{
    document.write("You are using an unknown browser.");
}
</script>

Vì lý do này, kiểm tra tự động sẽ không phát hiện các khu vực có thể dễ bị ảnh hưởng bởi XSS dựa trên DOM trừ khi công cụ kiểm tra có thể thực hiện phân tích bổ sung mã phía máy khách.

Do đó, nên thực hiện kiểm tra thủ công và có thể được thực hiện bằng cách kiểm tra các khu vực trong mã nơi các tham số được đề cập đến có thể hữu ích cho kẻ tấn công. Ví dụ về các khu vực như vậy bao gồm những nơi mã được ghi động vào trang và những nơi khác nơi DOM được sửa đổi hoặc thậm chí nơi các tập lệnh được thực thi trực tiếp.

Biện pháp khắc phục hậu quả

Để biết các biện pháp ngăn chặn XSS dựa trên DOM, hãy xem Trang tính ngăn chặn XSS dựa trên DOM.

Xem thêm HTML DOM trong Dart

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now