TỪ ĐIỂN BẢO MẬT: SSRF (SERVER-SIDE REQUEST FORGERY) LÀ GÌ VÀ SỨC TÀN PHÁ TỪ BÊN TRONG

Trong kiến trúc hệ thống hiện đại (đặc biệt là Microservices), các server thường xuyên phải giao tiếp với nhau hoặc gọi ra các API bên ngoài (Third-party API). Lợi dụng điểm này, kẻ tấn công (Attacker) sử dụng SSRF để "mượn tay" chính server của bạn làm bàn đạp tấn công vào các mục tiêu khác mà bình thường chúng không thể tự truy cập được.

1. Bản Chất Của Lỗ Hổng SSRF

Hãy tưởng tượng ứng dụng của bạn có một tính năng yêu cầu user nhập vào một URL hình ảnh, sau đó server sẽ tải hình ảnh đó về và xử lý (ví dụ: tạo thumbnail).

Code xử lý thông thường sẽ trông giống thế này (ví dụ với PHP/cURL hoặc Go HTTP Client): GET https://your-server.com/api/download-image?url=https://example.com/image.png

Chuyện gì xảy ra nếu user thay đổi tham số url?

• Kẻ tấn công không nhập URL hình ảnh nữa, mà nhập một địa chỉ Localhost hoặc địa chỉ IP nội bộ: GET https://your-server.com/api/download-image?url=http://127.0.0.1:6379 (Cổng của Redis)
• hoặc GET https://your-server.com/api/download-image?url=http://192.168.1.10:9200 (Cổng của Elasticsearch)

Lúc này, con Server của bạn ngoan ngoãn gửi request đến chính cục Redis/Elasticsearch nội bộ của nó. Bùm! Kẻ tấn công vừa bypass được toàn bộ tường lửa (Firewall) từ bên ngoài để chọc thẳng vào các dịch vụ nhạy cảm vốn không bao giờ public ra Internet.

2. Các Kịch Bản Tấn Công (Attack Vectors) Phổ Biến

Sức tàn phá của SSRF phụ thuộc vào những gì server của bạn có thể "nhìn thấy" trong mạng nội bộ.

• Quét mạng nội bộ (Internal Port Scanning): Attacker liên tục đổi port trong URL để xem service nào đang chạy (Database, Cache, Message Queue).
• Chiếm đoạt Cloud Metadata (Đặc biệt nguy hiểm): Nếu hệ thống chạy trên AWS, GCP hay Azure, mọi instance đều có một endpoint nội bộ (thường là http://169.254.169.254) chứa metadata. Kẻ tấn công có thể ép server gọi vào endpoint này để lấy cắp Access Token, Secret Keys của toàn bộ hạ tầng Cloud.
• Khai thác qua các Protocol khác (Schema Smuggling): Server không chỉ gửi request bằng http:// hay https://. Kẻ tấn công có thể dùng file:///etc/passwd để đọc file hệ thống, hoặc dùng gopher://, dict:// để gửi các packet nhị phân (binary data) nhằm thực thi mã từ xa (RCE) trên Redis hoặc Memcached.

3. Chiến Lược Phòng Chống SSRF Toàn Diện

Để chống lại SSRF, chúng ta phải triển khai nhiều lớp phòng ngự từ Application đến Network.

Chốt chặn ở tầng Application (Code)

• Sử dụng Allowlist (Danh sách trắng) thay vì Blocklist: Đừng cố gắng chặn các IP như 127.0.0.1 hay localhost, vì attacker có muôn vàn cách bypass (ví dụ: http://2130706433 tương đương 127.0.0.1, hoặc dùng DNS trỏ về Localhost). Thay vào đó, hãy định nghĩa chính xác những domain/IP nào server được phép gọi đến.
• Vô hiệu hóa các Schema không cần thiết: Khi cấu hình HTTP Client (dù là Guzzle trong PHP hay net/http trong Go), hãy thiết lập cứng để Client chỉ chấp nhận protocol http và https. Chặn đứng ngay từ vòng gửi xe các request dùng file://, gopher://, ftp://.
• Validate lại IP sau khi phân giải DNS (DNS Rebinding Protection): Kẻ tấn công có thể cung cấp một domain safe.com. Khi server kiểm tra, nó trỏ về IP an toàn. Nhưng ngay giây tiếp theo khi server thực sự gửi request, DNS được attacker đổi trỏ về 127.0.0.1. Do đó, cần phân giải DNS lấy IP, kiểm tra IP đó, và dùng chính IP đó để gửi request.

Chốt chặn ở tầng Network & Infrastructure

• Egress Filtering (Lọc kết nối chiều ra): Mặc định, các server Backend/Microservices không nên có quyền gọi ra ngoài Internet một cách tự do. Hãy cấu hình Firewall/VPC (Virtual Private Cloud) chỉ cho phép server kết nối đến các IP/Port của các dịch vụ bên ngoài thực sự cần thiết (như Payment Gateway).
• Network Isolation: Tách biệt các cluster Database (như MySQL, PostgreSQL), Cache (Redis) hay Search Engine (Elasticsearch) sang một mạng con (Subnet) khác với các policy truy cập cực kỳ nghiêm ngặt.
• Bảo vệ Cloud Metadata: Nếu dùng AWS, hãy nâng cấp lên IMDSv2 (Instance Metadata Service Version 2). Tính năng này yêu cầu phải có một Token đặc thù được tạo qua phương thức PUT trước khi có thể lấy metadata, khiến các cuộc tấn công SSRF cơ bản (chỉ gửi được GET) trở nên vô dụng.

💡 Lời Kết

SSRF là một minh chứng rõ ràng nhất cho việc: "Bức tường thành kiên cố nhất cũng có thể bị phá vỡ từ bên trong". Khi thiết kế các tính năng tương tác với bên ngoài (như Webhooks, Download File, Fetch URL), người kỹ sư phải luôn mang tâm thế "Zero Trust" – không tin tưởng bất kỳ input nào và luôn cô lập phạm vi hoạt động của từng request ở mức nhỏ nhất có thể.