Penetration Testing Step 3 – Các đường chấm mút với DOM based Cross-Site Scripting (Part 2)

Tiếp theo nội dung Penetration Testing Step 3 – Các đường chấm mút với DOM based Cross-Site Scripting (Part 1), kỳ này tôi sẽ tiếp tục câu chuyện demo chấm mút với DOM based Cross-Site Scripting. Cũng tương tự như các kỳ trước, tôi cũng sẽ nhờ cậy vào ông PortSwigger để demo làm rõ mà không phải hì hục dàn cảnh.

Trong nội dung kỳ này, tôi sẽ bàn về DOM based XSS trong mối quan hệ chồng chéo với third-party librabies/frameworks (ví dụ như jQuery) hỗ trợ xây dựng các chức năng cho ứng dụng.

#1. Hốt hàng DOM XSS với jQuery

#1.1 Dạng đầu vào location.search và đầu ra jQuery href attribute

jQuery là JavaScript library có khả năng làm thay thế các DOM element trên các trang (ví dụ thông qua attr() function). Lúc này, nếu dữ liệu được đọc từ nguồn mà người dùng có thể kiểm soát ví dụ như URL sau đó đẩy vô attr() function thì attacker sẽ có cơ hội để thao túng các giá trị gửi đi nhằm thực hiện mưu đồ XSS.

Ví dụ về việc JavaScript thay đổi href attribute khi sử dụng dữ liệu từ URL như sau:

$(function() {
$('#backLink').attr("href",(new URLSearchParams(window.location.search)).get('returnUrl'));
});

Với trường hợp này, bạn có thể chỉnh sửa URL để đẩy JavaScript URL độc hại vô location.search. Khi đám này được đút vô back link href thì nạn nhân sẽ ăn đạn. Ví dụ bạn đút vào cái:

?returnUrl=javascript:alert(document.domain)

Rồi, giờ xét ví dụ demo từ lab DOM XSS in jQuery anchor href attribute sink using location.search source sau cho rõ.

Trong lab này bạn sẽ khai thác DOM based XSS trong phần Submit feedback bên dưới.  Thông qua jQuery library selector function ($), bạn sẽ tìm và thay thế href attribute bằng dữ liệu từ location.search. Cụ thể, bạn click vào Submit feedback bên dưới để bắt đầu.

Tại đây bạn thử thay đổi query parameter chỗ returnPath với alphanumeric string tào lao kiểu như sau rồi chạy request. Sau đó, bạn thử inspect page source và search lại cái alphanumeric string đã đút vào xem nó có được đẩy vô href attribute như sau không.

Nếu xác nhận có hàng đẩy vô rồi thì bạn có thể thử thay đổi thành kiểu độc hại như javascript:alert(document.domain) để cập nhật lại href attribute sau đó click vào Back button để kiểm tra độ “độc”.

Nếu bạn thấy được popup như sau thì âm mưu tấn công đã thành công như mong đợi.

#1.2 Dạng đầu ra jQuery selector sử dụng hashchange event

Một vị trí khác có khả năng đẩy hàng độc vô DOM mà bạn cần kiểm tra là jQuery selector function ($). Con hàng selector này khi kết hợp với dạng đầu vào location.hash (ví dụ dùng cho animation/auto-scrolling đến element cụ thể của trang) có thể tạo ra lỗ hổng DOM XSS kinh điển. Dạng thường gặp của thể loại này là kiểu hashchange event hanler như sau:

$(window).on('hashchange', function() {
var element = $(location.hash);
element[0].scrollIntoView();
});

Vì người dùng có thể kiểm soát hash nên attacker có thể tận dụng để đẩy XSS vector vào  selector $().

Lưu ý:

• Các phiên bản cập nhật của jQuery đã vá lỗ hổng này để ngăn chặn hành động mờ ám là inject HTML vô selector với input bắt đầu bằng hash character (#);
• Các phiên bản mới của jQuery vẫn có thể ăn hành thông qua các lỗ hổng với selector $ khi đầu vào không yêu cầu # prefix.

Về nguyên tắc, để “ăn” DOM based XSS dạng này, bạn cần xác định phương thức để kích hoạt hashchange event mà không cần có tương tác của người dùng. Cách đơn giản nhất là sử dụng iframe kiểu như sau.

<iframe src="https://vulnerable-website.com#" onload="this.src+='<img src=1 onerror=alert(1)>'">

Trong ví dụ này, src attribute hướng đến trang có lỗ hổng với hash value rỗng. Khi iframe được load, XSS vector sẽ được gắn vào hash và kéo cò cho hashchange event khai hỏa.

Rồi giờ tôi đi vào phần demo chi tiết để dễ hình dung. Việc đầu tiên khi mò vào đây là bạn có thể inspect để kiểm tra page source và tìm kiếm thông tin liên quan đến phần hashchange. Kết quả tìm được có thể như sau.

Sau khi xác định được cái script có hashchange như trên, bạn chọn Go to exploit server để bắt đầu sự nghiệp chọc ngoáy. Tại exploit server, bạn di chuyển xuống phần body và đút vào thử cái iframe kiểu như sau (lưu ý nhớ cập nhật cái lab id, phần nằm giữ https và  web-security-academy, tương ứng.

Lưu ý: Như đã nói trong phần nguyên tắc ở trên, khi iframe được load, src được gán giá trị vớ vẩn để làm phát sinh lỗi dẫn đến onerror event từ đó kích hoạt print() function.  

Sau đó bạn chọn Store để ghi lại dữ liệu và sau đó chọn View exploit để xem thử coi trò đút iframe ở trên có hiệu quả hay không. Nếu bạn có thể kích hoạt print() function như bên dưới thì coi như thành công mỹ mãn (nếu bạn quan tâm đến việc hoàn thành bài lab thì nhớ chọn Deliver exploit to victim).

#2. DOM XSS với Angular JS

AngularJS là một trong những thư viện phổ biến của JavaScript có thể rà quét nội dung HTML chứa ng-app attribute (còn được gọi là AngularJS directive). Khi có directive được bổ sung vào HTML code, attacker sẽ có thể thực thi JavaScript code trong double curly braces ({{}}).

Rồi, giờ tôi lại đi vào phần demo để làm rõ. Tại giao diện ứng dụng blog, bạn thử nghiệm chọc ngoáy bằng cách đưa một alphanumeric string vào ô tìm kiếm và bấm Search.

Cũng như trước đó, bạn inspect để khám nghiệm page source và tìm cái alphanumeric string đã đưa vào xem nó có nằm trong ng-app directive kiểu như sau không.

Nếu có, bạn có thể tấn công thử nghiệm bằng cách nhập liệu vào nội dung search AnglarJS expression như sau:

Khi đó, nếu click vào Search có thể kích hoạt popup sau là bạn đã triển khai thành công mưu đồ tấn công.

Đến đây hy họng bạn đã hình dung sơ bộ con đường chấm mút DOM based XSS với đám third-party dependencies như jQuery hay AngularJS. Kỳ tới tôi sẽ bàn tiếp về vấn đề giao lưu phối hợp của DOM based XSS với đám relected/stored data trước khi kết thúc câu chuyện về nhân vật XSS.