Penetration Testing Step 3 – Cross-Site Scripting – XSS là cái vẹo gì?

Kết thúc nội dung Penetration Testing Step 3 – Dò tìm password của phpMyAdmin với Pitchfork attack của Burp Suite Intruder, kỳ này tôi sẽ đổi gió với một chủ đề mới trong Bước 3 của công cuộc Penetration Testing là Cross-Site Scripting – XSS.

#1. Thế Cross-site scripting – XSS là cái gì?

Cross-site scripting – XSS là dạng lỗ hổng bảo mật của web cho phép attacker “xâm hại” quá trình tương tác của người dùng với ứng dụng. Cụ thể, Với XSS, attacker sẽ có thể nguy trang làm nạn nhân để thực hiện các hành vi độc hại nên sẽ cực kỳ nguy hiểm nếu nạn nhân có thuộc dạng chức sắc có nhiều đặc quyền trên ứng dụng.

Bàn kỹ hơn về nguyên lý, XSS hoạt động dựa trên việc lợi dụng lỗ hổng ứng dụng để trả về các mã JavaScript độc hại đến nạn nhân. Khi được thực thi trong browser của nạn nhân, đám mã này có thể thao túng toàn bộ quá trình tương tác của nạn nhân với ứng dụng.

Nguồn: portswigger.net

#2. Kính thưa các thể loại XSS

Hiện có thể phân XSS thành 3 loại chính như sau.

#2.1 Reflected XSS

Với Reflected XSS, mã độc hại xuất phát từ HTTP request hiện tại chứ không lưu trên website database. Do vậy, đây là là kiểu bắt lẻ phản damage (reflected), chỉ ông nào dại dột bấm URL vớ vẩn thì vỡ mồm. Các ông khác không truy cập URL độc hại thì vẫn vô sự.

Về nguyên lý, đây là dạng đơn giản nhất, phát sinh từ việc ứng dụng nhận dữ liệu của HTTP request sau đó gửi trả lại response có kèm dữ liệu này mà không kiểm tra sát khuẩn gì sất. Nguyên lý này được tóm lược sơ bộ như sau.

Nguồn: stacktrac3.co

Để dễ hình dung, bạn có thể xem ví dụ đơn giản với website có tính năng search nhận thông tin tìm kiếm của user kiểu:

https://your-ridiculous-website.com/search?term=money

<p>You searched for: money</p>

Lúc này nếu ứng dụng méo thực thi kiểm tra xử lý cái vẹo gì cả thì attacker có thể mông má xây dựng một cái URL để tấn công kiểu như sau:

https://your-ridiculous-website.com/search?term= <script>/*+Bad+stuff+here...+*/</script>

Và cái URL sẽ trả về response tương ứng là:

<p>You searched for: <script>/* Bad stuff here... */</script></p>

Lúc này, bất kỳ nạn nhân xấu số nào truy cập vào URL đã được mông má trên thì đám mã độc hại (<script>/* Bad stuff here… */</script>) sẽ được thực thi trong browser của nạn nhân. Với ngữ cảnh session tương tác hiện hành của nạn nhân với ứng dụng, lúc này attacker, thông qua cái mã độc hại có thể tùy ý thực thi các thao tác trên danh nghĩa của nạn nhân.

#2.2 Stored XSS

Stored XSS còn có tên gọi khác là Persistent/Second-oder XSS. Với Stored XSS, mã độc hại xuất phát từ website database nên kiểu này thì nguyên đám truy cập website đều có khả năng chết chùm. Về nguyên lý, Stored XSS xuất hiện khi ứng dụng nhận dữ liệu từ các nguồn không tin cậy và sau đó dại dột kẹp đám dữ liệu này vào các HTTP response tiếp theo mà không kiểm tra xử lý. Đám dữ liệu này có thể chuyển đến ứng dụng thông qua HTTP request như khi gửi comments vào blog post hoặc cũng có thể đến từ các nguồn vớ vẩn kiểu như ứng dụng network monitoring hiển thị packet data từ network traffic.

Như vậy có thể thấy chữ Stored ở đây hàm ý đám mã độc hại được lưu trữ vào database của ứng dụng và attacker có thể ngồi đó thông thả chấm mút nhiều nạn nhân khác nhau.

Nguồn: geeksforgeeks.org

Để dễ hình dung, bạn có thể xem ví dụ với kiểu ứng dụng nhắn tin cho phép người dùng gửi tin nhắn đến, sau đó hiển thị cho các người dùng khác theo kiểu sau đây.

<p>Hello, this is my message!</p>

Lúc này, cũng giống như Reflected XSS, nếu ứng dụng không thực thi bất kỳ giải pháp xịt khuẩn, sát trùng nào trên đám dữ liệu thì attacker có thể mông má lại dữ liệu thành kiểu độc hại như sau:

<p><script>/* Bad stuff here... */</script></p>

Và cũng giống như trên, các user khác khi truy cập vào ứng dụng nhận hàng sẽ lãnh trọn cái đám độc hại <script>/* Bad stuff here… */</script> và trở thành món mồi ngon cho attacker.

#2.3 DOM-based XSS

DOM-based XSS hay DOM XSS là dạng lỗ hổng tồn tại trong client-side code chứ không phải server side như 2 trường hợp nói trên. Đây là dạng lỗ hổng phát sinh khi ứng dụng chứa một số client-side JavaScript xử lý ẩu dữ liệu từ các nguồn tào lao. Đám dữ liệu này sau đó lại được ghi vào DOM.

Lưu ý: Document Object Model – DOM là programming interface (giao diện lập trình) cho các web documents (tài liệu dạng web). Nói dễ hình dung thì DOM thể hiện trang web theo dạng tập hợp các đối tượng để cho phép các ngôn ngữ lập trình có thể tương tác thay đổi cấu trúc/nội dung/định dạng của thành phần tương ứng một cách dễ dàng.

Bạn có thể xem tóm lược về nguyên lý của DOM-based XSS như sau.

Nguồn: neuralegion.com

Và cũng để dễ hình dung, bạn có thể xem ví dụ ứng dụng có đoạn JavaScript đọc giá trị từ input field và sau đó ghi giá trị vào một thành phần của HTML như sau:

var search = document.getElementById('search').value;

var results = document.getElementById('results');

results.innerHTML = 'You searched for: ' + search;

Lúc này, nếu attacker có thể kiểm soát giá trị từ input field, y sẽ dựng lên giá trị độc hại kiểu như sau để chèn mã độc vào:

You searched for: <img src=1 onerror=’/* Bad stuff here… */’>

Thông thường, input field sẽ được lấy từ các phần của HTTP request ví dụ như URL query string parameter do vậy attacker có thể tấn công bằng URL độc hại theo cùng phương thức với Reflected XSS.

#3. Vậy làm sao để ngăn chặn XSS attack?

Tùy thuộc vào độ phức tạp của ứng dụng, giải pháp ngăn chặn XSS attack sẽ có nhiều mức độ từ dễ đến khó. Tuy nhiên, các giải pháp phổ biến bao gồm:

• Lọc dữ liệu đầu vào;
• Mã hóa dữ liệu đầu ra;
• Sử dụng các response header phù hợp;
• Sử dụng Content Security Policy.

Nói thì rất ngắn gọn nhưng triển khai chuẩn cmn mực các nội dung nói trên cũng không phải đơn giản. Ngoài việc phân tích chi tiết ứng dụng bạn còn phải nằm lòng các thủ thuật mà attacker có thể sử dụng để ra đối sách hợp lý.

Và như bạn thấy, từ đầu đến giờ tôi toàn chém gió suông nên các nội dung thật sự hơi khó “đi vào lòng người”. Do vậy, trong các kỳ tới tôi sẽ demo thử các nội dung liên quan cho sinh động và dễ “thấm”.