Penetration Testing Step 3 – Tìm và diệt mục tiêu với Reflected Cross-Site Scripting

Tiếp theo nội dung Penetration Testing Step 3 – Cross-Site Scripting – XSS là cái vẹo gì?, như đã hứa hẹn trước đó, tôi sẽ demo thử nghiệm để minh họa các dạng XSS. Cụ thể, trong nội dung kỳ này, tôi sẽ tập trung vào Reflected Cross-Site Scripting.

#1. Điều kiện cần và đủ của Reflected Cross-Site Scripting

Như đã đề cập kỳ trước, Reflected Cross-Site Scripting 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 gì cả. Do vậy, điều kiện cần là ứng dụng phải có lỗ hổng trong quá trình xử lý dữ liệu.

Tiếp theo là điều kiện đủ. Để có một mùa vụ Reflected Cross-Site Scripting bội thu, attacker phải bảo đảm nạn nhân truy cập vào URL đã được mông má lại. Có nhiều cách để attacker mồi chài cho nạn nhân thực hiện cái request mà y kiểm soát, ví dụ như chèn link trên website của attacker hoặc gửi link qua email. Vấn đề này thuộc một diễn biến khác (liên quan nhiều đến Social Engineering attack – nhóm các giải pháp tấn công dựa vào tâm sinh lý của mục tiêu con người) nên tôi sẽ không đề cập ở đây.

Về cơ bản, Reflected Cross-Site Scripting sẽ có số lượng nạn nhân ít hơn đáng kể so với Stored Cross-Site Scripting do vẫn cần động tác “ăn mồi” từ nạn nhân. Tuy nhiên, nếu attacker “ăn” được nạn nhân có giá trị cao, nhiều đặc quyền thì hậu quả sẽ rất tàn khốc.

Lưu ý: Bạn cũng có thể thấy kiểu phân loại là Server XSS và Client XSS do thực tế sẽ có vùng chồng lấn của 3 loại Reflected/Stored/DOM based XSS. Việc phân chia này dựa trên nguyên lý là lỗi xuất hiện ở phía Server hay Client. Khi đó cả Reflected/Stored XSS đều có thể xuất hiện ở Server/Client XSS và DOM based XSS sẽ là một dạng con của Client XSS. Việc phân loại được tóm lược như sau.

Nguồn: owasp.org

#2. Rồi vậy giờ tìm và diệt với Reflected XSS như nào?

Thực tế, giải pháp chuẩn cmn mực là bạn dùng Web Vulnerability Scanner của Burp Suite để quét và dò tìm các lỗ hổng XSS của ứng dụng trước.

Nguồn: portswigger.net

Sau đó, tùy thuộc vào kết quả nhận được (và tình hình thực tế của ứng dụng), bạn có thể thực hiện rà soát thủ công với các bước sau.

Lưu ý: Vì thời gian có hạn nên tôi không dàn cảnh demo bài bản từ A đến Z mà chỉ bay vào xắn minh họa một số nội dung với lab dựng sẵn của ông Portswigger cho nhanh.

#2.1 Kiểm tra tất cả các điểm nhập liệu entry point

Ở bước này, bạn cần kiểm tra từng entry point trong HTTP request của ứng dụng bao gồm các parameters/data trong URL query string, message body, URL file path và thậm chí cả HTTP header.

#2.2 Gửi các ký tự dạng alphanumeric (bao gồm số và chữ) ngẫu nhiên

Với từng entry point, bạn sẽ cần gửi thử các giá trị ngẫu nhiên duy nhất và xác định xem các giá trị này có bị phản damage, reflected trong response hay không. Để thoát phần lớn các ải kiểm soát của input validation, các giá trị này nên ngắn và chỉ thuộc đám alphanumeric (lý tưởng thì đám giá trị nên dài cỡ 8 ký tự để tránh việc ngắn quá trùng với các thứ khác trong response). Tôi ví dụ với phần search như sau.

Ngoài ra, với Burp Suite, bạn có thể dùng Number Payload để tạo ngẫu nhiên các giá trị phù hợp theo các phạm vi và định dạng quy định trước (ví dụ quy định khoảng giá trị, bước nhảy, dạng integer, fraction). Đồng thời, bạn cũng có thể dùng grep payload options của Burp Suite Intruder để tự động định vị các responses chứa giá trị đã gửi đi. Cụ thể, với grep payload options, bạn cũng sẽ có thêm một cột kết quả chứa checkbox cho biết giá trị payload đang xem xét có nằm trong response hay không. Nếu chưa hình dung được, bạn có thể xem kỹ hơn trong nội dung Penetration Testing Step 3 – Xoay chuyển thế trận với Intruder attack options của Burp Suite.

#2.3 Xác định bối cảnh của sự vụ – reflection context

Với mỗi vị trí trong response có chứa giá trị ngẫu nhiên đã gửi, bạn sẽ cần xác định ngữ cảnh tương ứng (ví dụ là text trong HTML tag, tag attribute hay JavaScript string) để có phương án xử lý phù hợp trong bước tiếp theo.

#2.4 Kiểm tra với payload tiềm năng

Kế đến, dựa vào ngữ cảnh đã xác định ở bước trên, bạn cần kiểm tra thử với một XSS payload tiềm năng có thể “kéo cò” việc thực thi mã JavaScript và xem nó có reflected trong response mà không bị chỉnh sửa hay không.

Ở bước này, cách kiểm tra payload dễ nhất là sử dụng Burp Suite Repeater. Với Repeater, bạn chỉ cần gửi hàng qua, sau đó chỉnh sửa request để chèn vào payload cần kiểm tra, chạy request và kiểm tra kết quả trả về coi có chấm mút được gì không.

Lưu ý: Nếu chưa rõ về Burp Suite Repeater, bạn có thể xem lại các phần liên quan trong nội dung Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeaterv.

Để việc kiểm tra hiệu quả, bạn có thể giữ lại giá trị ngẫu nhiên gốc thiết lập ở trên và đặt các XSS payload tiềm năng vào trước và sau giá trị ngẫu nhiên này. Kế tiếp, bạn thiết lập giá trị ngẫu nhiên trong search term của Burp Suite respone. Khi đó Burp Suite sẽ highlight các vị trí tìm kiếm được và nhờ đó bạn nhanh chóng xác định các nội dung liên quan đến kết quả kiểm tra reflection theo kiểu như sau.

Với nhu cầu thử nghiệm, cách thông dụng, đơn giản nhất là bạn chèn <script>alert(document.domain)</script> vào để kiểm tra kiểu như sau.

#2.5 Kiểm tra với các payload thay thế

Trường hợp XSS payload thử nghiệm ở trên bị ứng dụng chỉnh sửa hoặc chặn, bạn sẽ cần kiểm tra tiếp với các payload thay thế cũng như điểu chỉnh các phương thức có thể có để có một sự vụ XSS thành công. Quá trình này sẽ cần dựa trên ngữ cảnh cụ thể và loại input validation đang được sử dụng.

#2.6 Kiểm tra quá trình tấn công từ browser

Cuối cùng, khi đã tìm được payload chạy ngon trên Burp Suite Repeater, bạn cần chuyển kết quả nghiên cứu này qua browser (ví dụ chuột phải vô request chỉnh sửa trên chọn Copy URL rồi dán qua Browser) sau đó kiểm tra xem các code JavaScript có được thực thi hay không. Nếu ngon lành, nó hiện pop up lên cho biết cuộc tấn công đã thành công mỹ mãn.