Hỏi & Đáp#
1. Lỗ hổng Server-Side Request Forgery (SSRF) là gì, và nó khác biệt như thế nào so với các loại lỗ hổng ứng dụng web khác?#
Server-Side Request Forgery (SSRF) là một lỗ hổng bảo mật web cho phép kẻ tấn công lạm dụng một ứng dụng phía máy chủ (server-side application) và ép nó gửi các HTTP request đến một đích đến không mong muốn. Thay vì kẻ tấn công kết nối trực tiếp đến tài nguyên mục tiêu, máy chủ web có lỗ hổng sẽ trở thành thành phần thực hiện request. Điều này rất nguy hiểm vì máy chủ có thể có quyền truy cập mạng, các mối quan hệ tin cậy (trust relationships) hoặc thông tin xác thực (credentials) mà kẻ tấn công không có.
SSRF khác với nhiều lỗ hổng web phổ biến vì hướng tấn công chính không phải là thao túng trực tiếp giao diện trình duyệt hay kết quả truy vấn cơ sở dữ liệu. Ví dụ, Cross-Site Scripting (XSS) chủ yếu lạm dụng trình duyệt của người dùng nạn nhân, trong khi SQL Injection nhắm vào các truy vấn cơ sở dữ liệu của ứng dụng. SSRF lạm dụng khả năng tạo request ra bên ngoài (outbound requests) của máy chủ. Kết quả là, kẻ tấn công có thể tiếp cận các dịch vụ nội bộ, các endpoint metadata của cloud, bảng điều khiển quản trị, hoặc các tài nguyên được bảo vệ khác vốn không thể truy cập từ Internet công cộng.
Trong kịch bản blind SSRF (SSRF mù), ứng dụng không trả về phản hồi phía máy chủ cho kẻ tấn công. Do đó, kẻ tấn công không thể trực tiếp nhìn thấy kết quả của request. Thay vào đó, kẻ tấn công xác nhận lỗ hổng bằng cách sử dụng một máy chủ tương tác ngoài băng tần (out-of-band interaction server), chẳng hạn như Burp Collaborator. Nếu máy chủ có lỗ hổng gửi một request DNS hoặc HTTP đến domain của Collaborator, điều này chứng minh rằng máy chủ đã thực hiện outbound request.
2. Mô tả phương pháp luận để khai thác lỗ hổng SSRF trong một ứng dụng web. Các bước và kỹ thuật chính liên quan đến việc tạo và gửi các request độc hại để khai thác lỗ hổng SSRF là gì?#
Một phương pháp luận thực tế để kiểm thử SSRF bắt đầu bằng việc xác định các đầu vào (inputs) có thể khiến ứng dụng fetch (tải) một URL hoặc tương tác với một tài nguyên bên ngoài. Các đầu vào này có thể bao gồm các tham số URL, tính năng import file, webhooks, trình lấy hình ảnh (image fetchers), trình chuyển đổi tài liệu, tích hợp API hoặc các HTTP header như Referer.
Sau đó, người kiểm thử (tester) chặn (intercept) request bằng Burp Suite và sửa đổi input đang bị nghi ngờ để chứa một URL do mình kiểm soát. Nếu ứng dụng trả về nội dung được fetch, SSRF có thể hiển thị trực tiếp trong phản hồi. Nếu ứng dụng là dạng blind, người kiểm thử nên sử dụng một payload out-of-band, chẳng hạn như một domain Burp Collaborator, và theo dõi xem có nhận được các tương tác DNS hoặc HTTP hay không.
Sau khi xác nhận hành vi SSRF, người kiểm thử có thể đánh giá mức độ ảnh hưởng (impact) một cách có kiểm soát và được ủy quyền. Các bài kiểm tra điển hình bao gồm xem liệu máy chủ có thể tiếp cận các dải IP nội bộ, dịch vụ localhost, endpoint metadata hay các tài nguyên mạng bị hạn chế hay không. Một phương pháp kiểm thử an toàn nên tránh các hành động phá hoại và nên tập trung vào việc chứng minh khả năng tiếp cận (reachability) và mức độ ảnh hưởng bằng số lượng request ít nhất.
Các kỹ thuật kiểm thử SSRF phổ biến bao gồm thay thế các giá trị URL bằng một payload Collaborator, kiểm thử các URL scheme khác nhau, kiểm tra chuyển hướng (redirects), thử các địa chỉ loopback và mạng riêng (private network), đồng thời xem xét cách ứng dụng xác thực (validate) hostname và địa chỉ IP. Cần có cơ chế xác thực mạnh vì các allowlist (danh sách cho phép) yếu kém đôi khi có thể bị bypass bằng URL encoding, redirects, các định dạng IP thay thế, thủ thuật DNS, hoặc các URL dị dạng (malformed URLs).
Khai thác Blind SSRF với tính năng phát hiện out-of-band#
Mục tiêu Lab#
Mục tiêu của lab này là xác định và khai thác một lỗ hổng blind Server-Side Request Forgery. Ứng dụng có lỗ hổng xử lý header Referer khi trang sản phẩm được load. Bằng cách thay thế giá trị Referer bằng một payload của Burp Collaborator, người kiểm thử có thể khiến ứng dụng phía máy chủ tạo một request out-of-band (ngoài băng tần) đến máy chủ Collaborator.
Bước 1: Mở ứng dụng lab#
Đầu tiên, tôi mở lab PortSwigger Web Security Academy có tên Blind SSRF with out-of-band detection. Ứng dụng hiển thị một trang web mua sắm trực tuyến với một số thẻ sản phẩm.
Trang này cung cấp một điểm vào (entry point) bình thường để duyệt xem thông tin chi tiết sản phẩm. Vì lab này về blind SSRF, tôi dự đoán rằng hành vi có lỗ hổng sẽ không nhất thiết hiển thị trong phản hồi (response) của trang.
Bước 2: Duyệt xem một sản phẩm và bắt request trong Burp Suite#
Tiếp theo, tôi mở một trang chi tiết sản phẩm và bắt (capture) lưu lượng HTTP thông qua Burp Suite Proxy. Trong phần HTTP history, tôi chọn request dành cho trang sản phẩm:
| |
Quan sát quan trọng là request chứa một header Referer. Trong lab này, ứng dụng sử dụng header này trong một chức năng tracking hoặc phân tích phía máy chủ (server-side analytics). Vì header Referer có thể do người dùng kiểm soát, nó là một điểm chèn (injection point) thích hợp để kiểm thử blind SSRF.
Bước 3: Tạo một payload Burp Collaborator#
Tôi mở tab Collaborator trong Burp Suite Professional và tạo một payload. Burp Collaborator cung cấp một domain duy nhất có thể ghi lại các tương tác DNS và HTTP. Điều này rất hữu ích cho blind SSRF vì ứng dụng không hiển thị kết quả của request phía máy chủ trong HTTP response thông thường.
Payload được tạo ra có định dạng như sau:
| |
Payload này sau đó được copy vào clipboard và chuẩn bị để chèn vào request có lỗ hổng.
Bước 4: Gửi request sản phẩm sang Repeater#
Tôi gửi request sản phẩm đã chọn từ Proxy HTTP history sang Repeater. Repeater cho phép tôi chỉnh sửa request theo cách thủ công và gửi lại nhiều lần mà không cần tải lại trình duyệt.
Trong request, tôi thay thế header Referer ban đầu bằng URL của Burp Collaborator:
| |
Sau khi gửi request, ứng dụng vẫn trả về phản hồi trang sản phẩm bình thường. Điều này hoàn toàn dễ hiểu vì đây là lỗ hổng dạng blind (mù). Việc máy chủ gửi request thành công sẽ được xác nhận thông qua tương tác trên Collaborator thay vì thông qua phần body của HTTP response thông thường.
Bước 5: Kiểm tra (Poll) Burp Collaborator để xem các tương tác#
Sau khi gửi request đã chỉnh sửa, tôi quay lại tab Collaborator và poll (bấm nút kiểm tra) để tìm các tương tác. Máy chủ Collaborator đã nhận được một tương tác out-of-band từ máy chủ của lab. Điều này xác nhận rằng ứng dụng đã xử lý giá trị Referer do kẻ tấn công kiểm soát và khiến máy chủ tạo một request đến payload Collaborator.
Hành vi này chứng minh sự tồn tại của blind SSRF vì outbound request được khởi tạo bởi ứng dụng phía máy chủ, chứ không phải bởi trình duyệt của tôi.
Bước 6: Xác nhận hoàn thành lab#
Sau khi nhận được tương tác out-of-band, trạng thái lab chuyển thành Solved. Điều này xác nhận rằng payload đã kích hoạt thành công hành vi blind SSRF như dự kiến.
Phân tích lỗ hổng (Vulnerability explanation)#
Nguyên nhân cốt lõi của lỗ hổng này là ứng dụng tin tưởng một HTTP header do người dùng kiểm soát và sử dụng nó trong một request phía máy chủ. Kẻ tấn công có thể sửa đổi header Referer, do đó nó không nên được coi là một URL đáng tin cậy. Khi ứng dụng gửi request đến URL được cung cấp trong header này, kẻ tấn công có thể chuyển hướng (redirect) request phía máy chủ đến một đích tùy ý.
Trong lab này, tác động được chứng minh bằng một request out-of-band đến Burp Collaborator. Trong môi trường thực tế, điểm yếu tương tự có thể cho phép kẻ tấn công thăm dò các dịch vụ mạng nội bộ (internal network services), tương tác với các ứng dụng chỉ dành cho localhost, truy cập các endpoint cloud metadata, bypass các cơ chế kiểm soát truy cập cấp độ mạng (network-level access controls), hoặc kích hoạt các request ngoài ý muốn từ một máy chủ đáng tin cậy.
Tác động bảo mật (Security impact)#
Lỗ hổng được xác nhận là blind SSRF. Mặc dù ứng dụng không trả về trực tiếp nội dung được fetch, tương tác out-of-band chứng minh rằng máy chủ đã thực hiện một request do kẻ tấn công kiểm soát. Điều này vẫn có thể rất nghiêm trọng vì máy chủ có thể nằm bên trong một vùng mạng đáng tin cậy (trusted network zone) và có thể có quyền truy cập vào các hệ thống mà người dùng bên ngoài không thể tiếp cận được.
Các tác động tiềm ẩn bao gồm:
- Thăm dò (Reconnaissance) mạng nội bộ từ góc nhìn của máy chủ.
- Truy cập vào các dịch vụ HTTP nội bộ không được public ra Internet công cộng.
- Tương tác với các cloud metadata services nếu ứng dụng được lưu trữ trên môi trường cloud.
- Bypass các quy tắc tường lửa (firewall rules) vốn tin tưởng các request xuất phát từ máy chủ đang bị lỗi.
- Sử dụng máy chủ bị lỗi như một proxy để thực hiện các request giới hạn trong nội bộ.
Khuyến nghị khắc phục (Remediation recommendations)#
Để ngăn chặn SSRF, ứng dụng nên tránh tạo các request phía máy chủ dựa trên input không đáng tin cậy từ người dùng. Nếu tính năng này là bắt buộc, ứng dụng phải triển khai allowlist (danh sách cho phép) nghiêm ngặt gồm các đích đến đã được phê duyệt. Allowlist này phải dựa trên các hostname hoặc địa chỉ IP đã được chuẩn hóa và phân giải (normalized and resolved), chứ không phải dựa trên việc so khớp chuỗi (string matching) đơn giản.
Các biện pháp phòng thủ được khuyến nghị bao gồm:
- Không sử dụng các header do người dùng kiểm soát như
Refererlàm đích đến fetch dữ liệu phía máy chủ. - Sử dụng một allowlist nghiêm ngặt chứa các hostname đáng tin cậy và chặn tất cả các đích đến khác theo mặc định.
- Chặn các request đến dải IP private, loopback, link-local, multicast, và reserved.
- Phân giải DNS phía máy chủ và xác thực địa chỉ IP đã phân giải cuối cùng trước khi kết nối.
- Vô hiệu hóa hoặc kiểm soát chặt chẽ các redirect (chuyển hướng) khi thực hiện request phía máy chủ.
- Hạn chế quyền truy cập mạng ra bên ngoài (outbound network access) từ máy chủ ứng dụng bằng cách sử dụng các quy tắc tường lửa egress.
- Tách biệt ứng dụng khỏi các dịch vụ nội bộ nhạy cảm thông qua phân khúc mạng (network segmentation).
- Ghi log và giám sát các outbound request bất thường từ các máy chủ ứng dụng.
Kết luận#
Bài lab này đã minh chứng một lỗ hổng blind SSRF được kích hoạt thông qua header Referer. Bằng cách thay thế giá trị Referer ban đầu bằng payload của Burp Collaborator và gửi request đã sửa đổi thông qua Burp Repeater, tôi đã khiến ứng dụng phía máy chủ tạo một request out-of-band đến máy chủ Collaborator. Tương tác nhận được đã xác nhận rằng máy chủ đã xử lý URL do kẻ tấn công kiểm soát, và bài lab đã được giải quyết thành công.