Penetration Testing Step 3 – Lại tìm và diệt mục tiêu nhưng với Stored Cross-Site Scripting

Tiếp theo nội dung Penetration Testing Step 3 – Tìm và diệt mục tiêu với Reflected Cross-Site Scripting, kỳ này tôi sẽ mò mẫm sang đối tượng kế tiếp là Stored Cross-Site Scripting (XSS). Cũng như kỳ trước, với Stored XSS, tôi cũng sẽ demo minh họa với một ví dụ đơn giản để bạn có thể dễ hình dung ra vấn đề.

#1. Stored Cross-Site Scripting liệu có dễ ăn?

Như tôi đã giới thiệu trong nội dung Penetration Testing Step 3 – Cross-Site Scripting – XSS là cái vẹo gì?, Stored XSS hay Persistent/Second-oder XSS xuất phát từ việc đám dữ liệu độc hại được Stored (lưu lại) vào cơ sở dữ liệu của ứng dụng từ đó làm tăng đáng kể phạm vi sát thương.

Nhìn chung, các mục tiêu dễ ăn hành với Stored XSS là các ứng dụng cho phép người dùng chia sẻ các nội dung để sau đó hiển thị cho các người dùng khác.  Các ví dụ kinh điển bao gồm các blog cho phép người dùng comment, các trang social networking (mạng xã hội),…Với đặc tính của các mục tiêu này, một khi tồn tại lỗ hổng Stored XSS, việc người dùng dính đạn của attacker là điều khó tránh khỏi.

Tuy nhiên, cần lưu ý, bạn đừng thấy tôi chém gió thế mà cho rằng Stored XSS dễ ăn. Thực tế trừ các sản phẩm “nhà làm” để vọc vạch các kiểu, phần lớn các ứng dụng thương mại đều có khả năng sát khuẩn, xử lý các thông tin input mà người dùng gửi vào cũng như encode các thông tin đầu ra. Ngoài ra, các ứng dụng này cũng có thể sử dụng thêm các phương án ngăn chặn tăng cường như:

• Web Application Firewall – WAF sử dụng signature based filtering để xác định và block các request độc hại;
• Content Security Policy – CSP để phát hiện và dừng các mưu đồ tấn công;
• Sử dụng Vulnerability Scanner (ví dụ của Burp Suite) để rà soát đám lỗ hổng XSS;
• Sử dụng dạng whitelisting chỉ cho phép các ký tự hoặc pattern (khuôn mẫu) cụ thể của input thay vì tìm cách blacklisting quá nhiều kịch bản;
• Và thậm chí hơi tiêu cực như phương án tắt mịa JavaScript trên browser.

Nói đến đây có vẻ hình như tôi đang “bàn lùi” hơi nhiều rồi. Để thay đổi không khí tôi sẽ chuyển sang phần động chạm tay chân cho đỡ nhạt nhẽo. Và hiển nhiên, để minh họa việc chấm mút với Stored XSS, tôi sẽ lại phải trông cậy vào mấy bài Lab của ông Portswigger cho nhanh gọn.

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

#2.1 Nguyên lý để chấm mút với Stored XSS

Tương tự như Reflected XSS, như tôi nói trên, bạn cũng có thể dùng Burp Suite Web Vulnerability Scanner để dò tìm các lỗ hổng liên quan đến Stored XSS. Tuy nhiên, với Stored XSS, quá trình kiểm tra thủ công sẽ vất vả hơn do ngoài việc xử lý các entry points như Reflected XSS, bạn sẽ còn phải xử lý đám exit points tương ứng trong response của ứng dụng.

Các entry points cũng sẽ bao gồm:

• Các parameters/data trong URL query string và message body;
• URL file path;
• HTTP request header;
• Các kênh Out-of-band (đại khái là kênh kết nối riêng biệt, chủ yếu phục vụ quản lý, không công khai rộng rãi) cho phép chuyển data vào ứng dụng.

Và với exit points, bạn sẽ cần xem xét các HTTP response có thể có mà ứng dụng sẽ trả về cho người dùng. Về cơ bản, với Stored XSS, bạn sẽ phải xác định liên kết của đầu vào entry points với đầu ra exit points (nếu có). Và việc này cũng không dễ dàng gì vì:

• Dữ liệu đi vào các entry points có thể đi ra ở exit points bất kỳ;
• Dữ liệu đút vô ứng dụng có thể bị mông má chỉnh sửa trước khi nó phọt kết quả ra ở exit points.

Như vậy, với các ứng dụng nhỏ, bạn có thể chơi kiểu brute-force, đút dữ liệu vô rồi kiểm tra từng cặp entry point – exit point để xác định các liên kết có thể có. Với các ứng dụng lớn, phương án brute-force trên chỉ phù hợp nếu ngoài Pentest ra thì đời bạn không có việc gì khác để làm! Phương án thực dụng hơn là đút dữ liệu vào entry point rồi theo dõi thông tin phản hồi xem có chứa mấy thứ bạn đã đút vào hay không. Nếu có, bạn sẽ phân tích tiếp coi dữ liệu đút vào có được lưu lại trong các request khác không hay nó cũng chỉ phản hồi như kiểu Reflected XSS.

Ngoài ra, với từng liên kết đã xác định được giữa entry point và exit point, bạn cũng sẽ cần xem xét ngữ cảnh mà dữ liệu lưu trữ trong response để thử nghiệm các payload phù hợp tương tự như Reflected XSS.

#2.2 Trải nghiệm “tàu nhanh” với Stored XSS

Như nói ở trên, để dễ hình dung, tôi sẽ ví dụ minh họa với cái lab của ông Portswigger. Bài lab Stored XSS into HTML context with nothing encoded này đúng chuẩn “mì ăn liền” cố tình đơn giản hóa mọi thứ để bạn dễ nắm bắt vấn đề. Còn thực tế hiển nhiên sẽ hiếm khi dễ ăn như vậy được. Giao diện trang blog của bài lab như sau.

Bạn sẽ có thể nhanh chóng xác định một số entry points thú vị như Comment, Name, Email và Website. Với đám này, bạn sẽ cần thử nghiệm với từng entry points để xác định xem các input validation sẽ hoạt động thế nào (ví dụ email yêu cầu phải có định dạng abc@xyz chẳng hạn).

Sau khi có thể vượt ải input validation nói trên, bạn có thể kiểm tra phần exit points tương ứng. Đồng thời bạn cũng có thể xác nhận đám dữ liệu bạn đút vào có được Stored và bị mông má gì không. Kết quả với input thử nghiệm ở trên sẽ kiểu như sau.

Lưu ý: Với các lab demo đơn giản thì bạn sẽ dễ dàng hình dung ra việc kiểm tra kết quả gửi comment đến blog giống như trên. Với ứng dụng thực tế, đánh giá exit point sẽ vất vả hơn nhiều.

Ở đây bạn có thể hốt cái request từ HTTP history của Burp Suite Proxy và đẩy qua Repeater để triển khai nhanh các phương án thử nghiệm.

Và cũng như với Reflected XSS, 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.

Lúc này bạn có thể kiểm tra kết quả trên Browser để coi có ăn hên được nhát nào kiểu như sau hay không.

Và như tôi giới thiệu ở Mục 1, với từng liên kết đã xác định được giữa entry point và exit point, bạn sẽ cần tiếp tục xem xét ngữ cảnh mà dữ liệu lưu trữ trong response để thử nghiệm thêm các payload phù hợp chứ không phải ăn hên được một cái rồi nghỉ đâu nhé.