1. SSRF là gì?
SSRF (Server-Side Request Forgery) là lỗ hổng bảo mật cho phép kẻ tấn công lợi dụng máy chủ ứng dụng web để gửi request đến các tài nguyên nội bộ mà bình thường không thể truy cập từ bên ngoài. Nói cách khác, kẻ tấn công biến server thành "proxy" phục vụ cho mục đích tấn công.
Thay vì tấn công trực tiếp vào hệ thống nội bộ, kẻ tấn công gửi một request được thiết kế đặc biệt đến ứng dụng web, yêu cầu ứng dụng đó thực hiện một request khác đến địa chỉ do kẻ tấn công chỉ định. Vì request xuất phát từ chính máy chủ, hệ thống nội bộ thường tin tưởng và cho phép truy cập mà không kiểm tra kỹ.
Trong danh sách OWASP Top 10 phiên bản 2021, SSRF được xếp vào hạng mục A10:2021 - Server-Side Request Forgery, một mục mới được bổ sung dựa trên mức độ nghiêm trọng ngày càng tăng của loại lỗ hổng này trong môi trường điện toán đám mây và kiến trúc microservices.
SSRF khác biệt hoàn toàn so với các lỗ hổng phía client như XSS hay CSRF ở chỗ toàn bộ quá trình tấn công diễn ra phía server, không cần sự tương tác của người dùng cuối và không bị chặn bởi các cơ chế bảo vệ phía trình duyệt.
2. Tại sao SSRF là lỗ hổng nguy hiểm?
SSRF nguy hiểm không chỉ vì hậu quả nghiêm trọng mà còn vì bản chất của lỗ hổng này khiến việc phát hiện và ngăn chặn trở nên phức tạp hơn nhiều so với các lỗ hổng web thông thường.
2.1. Khai thác từ bên trong vòng tin cậy của hệ thống
Request do SSRF tạo ra xuất phát từ chính máy chủ ứng dụng, không phải từ IP bên ngoài. Điều này khiến hệ thống nội bộ, các dịch vụ backend, database và API gateway coi đây là lưu lượng hợp lệ và cho phép truy cập. Tường lửa truyền thống vốn chặn kết nối từ ngoài vào trong gần như vô hiệu trong tình huống này vì request đã vượt qua lớp bảo vệ đó ngay từ đầu.
2.2. Khó phát hiện vì request trông hợp lệ về mặt kỹ thuật
Request do kẻ tấn công dẫn dắt qua SSRF có cấu trúc HTTP hoàn toàn hợp lệ, không chứa payload độc hại rõ ràng. Hệ thống giám sát thông thường dễ bỏ qua nếu không có rule phân tích URL đích một cách chuyên sâu. Điều này đặc biệt đúng với Blind SSRF, khi không có response trả về và kẻ tấn công vẫn thu thập được thông tin qua kênh phụ.
2.3. Đặc biệt nguy hiểm trong kiến trúc microservices và môi trường cloud
Trong kiến trúc microservices, các service thường giao tiếp nội bộ qua HTTP mà không yêu cầu xác thực mạnh vì chúng tin tưởng nhau trong cùng mạng nội bộ. SSRF cho phép kẻ tấn công tiếp cận toàn bộ hệ sinh thái đó chỉ thông qua một điểm ứng dụng bị tổn thương. Trên nền tảng cloud, điều này còn nguy hiểm hơn khi endpoint metadata (ví dụ như địa chỉ nội bộ của cloud) thường chứa thông tin xác thực có thể bị đánh cắp qua SSRF.
2.4. Blind SSRF không trả về response, càng khó phát hiện
Không phải mọi SSRF đều trả về kết quả trực tiếp cho kẻ tấn công. Với Blind SSRF, kẻ tấn công không nhìn thấy response nhưng vẫn có thể xác nhận sự tồn tại của dịch vụ nội bộ, thu thập thông tin cấu trúc mạng hoặc kích hoạt các hành động có tác dụng phụ qua kênh phụ như DNS lookup hay thay đổi trạng thái hệ thống. Điều này khiến Blind SSRF rất khó phát hiện sớm, đặc biệt khi thiếu hệ thống giám sát tầng ứng dụng.
3. Cách thức hoạt động của tấn công SSRF
SSRF được khai thác khi ứng dụng web thực hiện request đến một địa chỉ do người dùng kiểm soát mà không kiểm tra kỹ đích đến. Luồng tấn công diễn ra hoàn toàn phía server, khiến hệ thống nội bộ tin tưởng và xử lý request như lưu lượng hợp lệ.
Để hình dung rõ cơ chế, lấy ví dụ một ứng dụng web có tính năng tải ảnh từ URL bên ngoài, đây là điểm dễ bị khai thác SSRF nhất:
- Kẻ tấn công thay URL ảnh hợp lệ bằng địa chỉ nội bộ nhắm tới, ví dụ địa chỉ metadata cloud hoặc IP của database server.
- Ứng dụng web nhận tham số, thực hiện HTTP request đến địa chỉ đó mà không kiểm tra tính hợp lệ của đích đến.
- Máy chủ nội bộ nhận request từ server ứng dụng, vốn được tin tưởng trong mạng nội bộ, và trả về dữ liệu.
- Response chứa thông tin nhạy cảm như token xác thực, cấu hình hệ thống hoặc danh sách dịch vụ nội bộ được trả về cho kẻ tấn công thông qua ứng dụng web.
Điểm then chốt trong cơ chế này là ứng dụng web đóng vai trò proxy không chủ ý. Toàn bộ quá trình diễn ra ở phía server, không cần bất kỳ sự tương tác nào từ người dùng cuối và không bị chặn bởi các cơ chế bảo vệ phía trình duyệt.
Để tìm hiểu sâu hơn về các kỹ thuật khai thác SSRF trong thực tế, tài liệu kỹ thuật của PortSwigger Web Security là nguồn tham khảo được cộng đồng bảo mật đánh giá cao hiện nay.
4. Phân loại SSRF
SSRF không phải một kiểu tấn công đồng nhất. Hai biến thể chính có cơ chế hoạt động và mức độ khó phát hiện khác nhau, đòi hỏi chiến lược phát hiện và phòng chống riêng biệt.
4.1. Basic SSRF
Với Basic SSRF, kẻ tấn công nhận được response trực tiếp từ ứng dụng web sau khi server thực hiện request đến địa chỉ nội bộ. Đây là dạng tấn công trực quan nhất: kẻ tấn công đọc nội dung trả về, từ đó thu thập thông tin xác thực, nội dung file cấu hình hoặc dữ liệu từ API nội bộ ngay trong cùng phiên request.
Basic SSRF tương đối dễ phát hiện hơn qua log vì có thể thấy rõ response bất thường. Tuy nhiên, nếu không có hệ thống giám sát tầng ứng dụng, log thông thường vẫn có thể bỏ sót vì request trông hoàn toàn hợp lệ về mặt kỹ thuật.
4.2. Blind SSRF
Blind SSRF nguy hiểm hơn vì không có output rõ ràng trả về cho kẻ tấn công. Thay vào đó, kẻ tấn công suy luận thông tin qua các kênh phụ: độ trễ phản hồi cho thấy port có đang mở hay không, DNS lookup ra ngoài xác nhận server đã thực sự kết nối đến địa chỉ chỉ định, hoặc thay đổi trạng thái hệ thống gián tiếp tiết lộ kết quả tấn công.
Blind SSRF đặc biệt khó phát hiện bằng các phương pháp giám sát thông thường. Kẻ tấn công có thể dùng Blind SSRF để lập bản đồ toàn bộ cấu trúc mạng nội bộ, xác định dịch vụ nào đang chạy ở đâu, trước khi tiến hành tấn công sâu hơn mà đội ngũ bảo mật không hay biết.
So sánh chi tiết hai biến thể SSRF:
| Tiêu chí | Basic SSRF | Blind SSRF |
| Response trả về | Có, kẻ tấn công thấy kết quả trực tiếp | Không, không có output rõ ràng |
| Cách thu thập thông tin | Đọc trực tiếp từ response ứng dụng | Qua kênh phụ: DNS, độ trễ, thay đổi trạng thái |
| Mức độ khó phát hiện | Tương đối dễ phát hiện hơn qua log | Rất khó, đặc biệt khi thiếu WAF chuyên sâu |
| Mức độ nguy hiểm | Cao | Rất cao do ẩn hoàn toàn |
| Ví dụ tình huống | Đọc nội dung file nội bộ qua URL tham số | Quét port nội bộ, trigger DNS lookup ra ngoài |
| Công cụ phát hiện phù hợp | Log phân tích, WAF rule cơ bản | Out-of-band detector, WAF hành vi, Burp Collaborator |
5. Các giao thức bị lợi dụng trong tấn công SSRF
Kẻ tấn công không chỉ dùng HTTP/HTTPS để khai thác SSRF. Tùy theo cách ứng dụng xử lý URL đầu vào, nhiều giao thức khác có thể bị lợi dụng, mỗi giao thức mở ra một hướng tấn công khác nhau với mức độ thiệt hại khác nhau.
5.1. HTTP và HTTPS
Đây là giao thức được dùng phổ biến nhất trong khai thác SSRF. Kẻ tấn công dùng HTTP/HTTPS để truy cập API nội bộ không có xác thực, đọc thông tin từ endpoint metadata của cloud, hoặc quét dịch vụ web đang chạy trong mạng nội bộ. Vì đây là giao thức hoàn toàn bình thường, request dạng này ít bị hệ thống giám sát cảnh báo nếu không có rule phân tích URL đích chuyên sâu.
5.2. file://
Giao thức file:// cho phép đọc file cục bộ trực tiếp trên server mà không cần đi qua mạng. Kẻ tấn công dùng giao thức này để đọc các file nhạy cảm như file cấu hình ứng dụng, file chứa biến môi trường, hoặc các file hệ thống chứa thông tin tài khoản. Đây là giao thức nguy hiểm và không có lý do hợp lệ nào để một ứng dụng web chấp nhận URL dạng file:// từ đầu vào người dùng.
5.3. dict://
Giao thức dict:// ban đầu được thiết kế để truy vấn từ điển qua mạng, nhưng trong bối cảnh SSRF có thể bị dùng để gửi chuỗi ký tự tùy ý đến một cổng dịch vụ nội bộ. Kẻ tấn công lợi dụng dict:// để thăm dò dịch vụ nội bộ, thu thập thông tin phiên bản phần mềm hoặc xác nhận sự tồn tại của dịch vụ tại một địa chỉ và port nhất định.
5.4. gopher://
Gopher:// là giao thức nguy hiểm nhất trong danh sách này vì tính linh hoạt cao. Giao thức này cho phép kẻ tấn công xây dựng và gửi dữ liệu tùy ý đến bất kỳ cổng nào, bao gồm các dịch vụ như Redis, Memcached, SMTP hoặc FastCGI thường không có xác thực trong mạng nội bộ. Khi kết hợp với SSRF, gopher:// có thể dẫn thẳng đến Remote Code Execution (RCE) mà không cần khai thác thêm lỗ hổng nào khác.
Tóm tắt mức độ nguy hiểm theo giao thức:
| Giao thức | Mục đích khai thác | Dịch vụ mục tiêu phổ biến | Mức độ nguy hiểm |
| HTTP/HTTPS | Truy cập API nội bộ, metadata cloud, quét dịch vụ | REST API, cloud metadata | Cao |
| file:// | Đọc file cục bộ trên server | File hệ thống, config, .env | Cao |
| dict:// | Thăm dò dịch vụ, thu thập thông tin phiên bản | Dịch vụ TCP tùy ý | Trung bình |
| gopher:// | Gửi dữ liệu tùy ý đến dịch vụ nội bộ, dẫn đến RCE | Redis, Memcached, SMTP, FastCGI | Rất cao |
6. Các ví dụ tấn công SSRF thực tế
Hiểu SSRF qua các kịch bản cụ thể giúp đội ngũ kỹ thuật nhận diện rủi ro trong hệ thống thực tế và ưu tiên vá lỗ hổng đúng chỗ.
6.1. Tấn công vào metadata cloud
Đây là kịch bản nguy hiểm nhất và phổ biến nhất trong môi trường cloud. Các nhà cung cấp cloud đều cung cấp một endpoint metadata nội bộ (thường ở một địa chỉ IP đặc biệt dạng link-local) để các instance tự truy vấn thông tin cấu hình và thông tin xác thực tạm thời.
Nếu ứng dụng web chạy trên cloud có lỗ hổng SSRF, kẻ tấn công có thể yêu cầu ứng dụng gửi request đến endpoint metadata đó và nhận về access token, secret key hoặc IAM role credentials. Với thông tin xác thực này, kẻ tấn công có thể leo thang đặc quyền để kiểm soát toàn bộ tài khoản cloud, truy cập storage, xem hoặc xóa dữ liệu, thậm chí khởi tạo thêm instance phục vụ mục đích tấn công khác.
6.2. Quét mạng nội bộ qua SSRF
Kẻ tấn công có thể biến SSRF thành công cụ quét port và dịch vụ nội bộ mà không cần truy cập trực tiếp vào mạng. Bằng cách thay đổi địa chỉ IP và số port trong request, kẻ tấn công dựa vào sự khác biệt thời gian phản hồi hoặc mã lỗi để xác định dịch vụ nào đang chạy ở đâu. Từ bản đồ mạng nội bộ thu thập được, kẻ tấn công lên kế hoạch tấn công tiếp theo nhắm vào dịch vụ yếu nhất.
6.2. SSRF trong môi trường microservices
Trong kiến trúc microservices, các service thường giao tiếp nội bộ qua API REST mà không có lớp xác thực mạnh vì giả định đây là lưu lượng tin cậy từ trong mạng. Khi một service bị khai thác SSRF, kẻ tấn công có thể gọi API của các service khác mà không cần thông tin đăng nhập, truy cập dữ liệu người dùng, thay đổi cấu hình hoặc đọc thông tin xác thực được lưu trong biến môi trường của các container.
Mức độ thiệt hại trong môi trường microservices thường lớn hơn ứng dụng monolith vì một điểm bị khai thác có thể dẫn đến truy cập ngang (lateral movement) toàn bộ hệ sinh thái dịch vụ.
7. Hậu quả của lỗ hổng SSRF
Khi lỗ hổng SSRF bị khai thác thành công, thiệt hại không chỉ dừng ở việc lộ một vài thông tin, mà thường dẫn đến chuỗi hậu quả nghiêm trọng, tác động đến cả kỹ thuật lẫn pháp lý và uy tín doanh nghiệp.
7.1. Lộ dữ liệu nội bộ và thông tin xác thực
Hậu quả trực tiếp đầu tiên là kẻ tấn công tiếp cận được các tài nguyên nội bộ vốn không bao giờ được phép truy cập từ ngoài: file cấu hình, biến môi trường chứa password database, private key, token xác thực dịch vụ bên thứ ba và thông tin người dùng nhạy cảm. Thông tin này trở thành bàn đạp để tiến hành các bước tấn công tiếp theo nguy hiểm hơn. Đây cũng là dạng data breach có thể kéo theo trách nhiệm pháp lý nghiêm trọng với doanh nghiệp.
7.2. Leo thang đặc quyền qua metadata cloud
Trong môi trường cloud, hậu quả nghiêm trọng nhất của SSRF là khả năng đánh cắp thông tin xác thực từ endpoint metadata để leo thang đặc quyền. Từ một lỗ hổng SSRF đơn giản, kẻ tấn công có thể giành quyền kiểm soát toàn bộ tài khoản cloud, bao gồm quyền truy cập vào bucket lưu trữ, cơ sở dữ liệu, và các dịch vụ nội bộ khác trong cùng hạ tầng.
7.3. SSRF làm bàn đạp tấn công tiếp theo
SSRF hiếm khi là điểm cuối của một cuộc tấn công. Kẻ tấn công thường dùng SSRF như bước đầu để thực hiện Remote Code Execution (RCE), đặc biệt khi kết hợp với các giao thức như gopher:// nhắm vào dịch vụ như Redis hay Memcached không có xác thực. Ngoài ra, SSRF còn được dùng để thực hiện lateral movement, tức là di chuyển ngang qua các dịch vụ nội bộ, mở rộng phạm vi kiểm soát mà không cần khai thác lỗ hổng mới. Trong trường hợp nghiêm trọng, chuỗi SSRF kết hợp với lỗ hổng liên quan đến broken access control có thể dẫn đến xâm phạm toàn bộ hệ thống.
7.4. Ảnh hưởng đến tuân thủ bảo mật
Theo CWE-918 của MITRE, SSRF được phân loại là lỗ hổng nghiêm trọng ở tầng ứng dụng vì khả năng vượt qua kiểm soát truy cập mạng, đặt ra rủi ro tuân thủ trực tiếp với các tiêu chuẩn như PCI-DSS (đối với fintech và thanh toán điện tử) và ISO 27001.
Tại Việt Nam, doanh nghiệp còn phải đối mặt với yêu cầu tuân thủ Luật An ninh mạng. Đặc biệt, kể từ khi Luật Bảo vệ dữ liệu cá nhân có hiệu lực, các tổ chức xử lý dữ liệu người dùng có nghĩa vụ pháp lý rõ ràng hơn trong việc bảo vệ thông tin cá nhân khỏi các hành vi xâm phạm, bao gồm cả tấn công qua lỗ hổng bảo mật như SSRF. Hậu quả pháp lý khi vi phạm bao gồm phạt tiền, yêu cầu kiểm toán bắt buộc và trong một số trường hợp phải thông báo công khai về sự cố bảo mật.
8. Cách phòng chống SSRF hiệu quả
Phòng chống SSRF đòi hỏi kết hợp nhiều lớp bảo vệ ở cả tầng ứng dụng, tầng mạng lẫn tầng vận hành. Không có biện pháp đơn lẻ nào đủ hiệu quả nếu thiếu các lớp còn lại.
8.1. Validate và whitelist URL phía server
Biện pháp căn bản nhất là kiểm tra kỹ tất cả URL hoặc địa chỉ IP được cung cấp từ người dùng trước khi thực hiện bất kỳ request nào. Thay vì dùng blacklist (chặn các địa chỉ đã biết là nguy hiểm), nên áp dụng whitelist, chỉ cho phép request đến các domain, IP và port đã được phê duyệt rõ ràng. Mọi URL không nằm trong danh sách whitelist đều bị từ chối mà không có thông báo chi tiết trả về cho người dùng.
8.2. Phân tách mạng
Áp dụng network segmentation để ứng dụng web không thể tự do truy cập các dịch vụ nội bộ nhạy cảm. Thiết lập firewall và access control list ở tầng mạng để giới hạn dịch vụ nào có thể giao tiếp với nhau. Ngay cả khi SSRF được khai thác, kẻ tấn công cũng chỉ tiếp cận được phân vùng mạng bị giới hạn thay vì toàn bộ hạ tầng.
8.3. Tắt hoặc kiểm soát chuyển hướng
HTTP redirect có thể bị lợi dụng để bypass whitelist URL. Kẻ tấn công trỏ request đến một domain được cho phép, nhưng domain đó lại redirect đến địa chỉ nội bộ. Để phòng tránh, cần tắt follow redirect tự động trong HTTP client phía server, hoặc kiểm tra lại URL đích sau mỗi lần redirect.
8.4. Kiểm tra và vá lỗ hổng định kỳ
Pentest và security review định kỳ giúp phát hiện các điểm có thể nhận URL từ người dùng mà chưa được bảo vệ đúng cách. Các endpoint như tính năng tải ảnh từ URL, webhook, preview trang web hoặc tích hợp dịch vụ bên thứ ba thường là nơi SSRF ẩn náu nhiều nhất.
Checklist phòng chống SSRF cần kiểm tra định kỳ:
- Tất cả URL đầu vào từ người dùng được validate và whitelist trước khi server thực hiện request
- Không follow redirect tự động trong HTTP client phía server, hoặc kiểm tra lại URL sau redirect
- Ứng dụng web không có quyền truy cập trực tiếp vào subnet chứa database, internal API và dịch vụ nhạy cảm
- Endpoint metadata của cloud được chặn hoặc được bảo vệ bằng IMDSv2
- Các dịch vụ nội bộ yêu cầu xác thực kể cả với request từ ứng dụng cùng mạng
- WAF được cấu hình với rule phát hiện SSRF và cập nhật thường xuyên
- Log tất cả outbound request từ server để phát hiện hành vi bất thường
9. VNIS giúp doanh nghiệp phòng chống SSRF như thế nào?
Phòng chống SSRF hiệu quả đòi hỏi chiến lược phòng thủ nhiều lớp, từ validate URL phía ứng dụng, phân tách mạng, đến một lớp WAF chuyên sâu có khả năng phân tích lưu lượng HTTP/HTTPS tại tầng ứng dụng. Đây là điểm mà VNIS (VNETWORK Internet Security) đóng vai trò như lớp bảo vệ đầu tiên và quan trọng nhất trước các lỗ hổng OWASP Top 10, bao gồm SSRF.
WAF trong VNIS hoạt động như lớp kiểm soát trung gian giữa internet và máy chủ ứng dụng, phân tích toàn bộ request HTTP/HTTPS theo thời gian thực trước khi chúng chạm đến server. Với bộ rule bảo mật liên tục được cập nhật, VNIS có khả năng phát hiện và chặn các request mang dấu hiệu SSRF ngay tại điểm đầu vào, bao gồm request chứa địa chỉ IP nội bộ, địa chỉ loopback, schema giao thức bất thường hoặc URL trỏ đến endpoint metadata cloud. Lưu ý rằng để bảo vệ toàn diện, VNIS cần được kết hợp với các biện pháp phía ứng dụng như whitelist URL và network segmentation.
Ngoài khả năng phát hiện SSRF tại tầng ứng dụng, VNIS còn cung cấp:
- WAAP tích hợp AI với bộ quy tắc bảo mật liên tục cập nhật, bảo vệ trực tiếp logic xử lý của web/app/API tại tầng ứng dụng, nơi SSRF thường bị khai thác sâu và khó phát hiện nhất
- Đội ngũ SOC giám sát 24/7 với khả năng phát hiện và cảnh báo hành vi bất thường theo thời gian thực, giúp đội ngũ kỹ thuật phản ứng kịp thời trước khi thiệt hại xảy ra
- AI Smart Load Balancing kết hợp Multi-CDN toàn cầu giúp duy trì tốc độ và độ ổn định của ứng dụng ngay cả khi đang chịu tấn công, không cần nâng cấp hạ tầng
- Bảo vệ đồng thời website, ứng dụng và API trên một nền tảng thống nhất, phù hợp với kiến trúc microservices vì đây là môi trường SSRF dễ bị khai thác nhất
10. Kết luận
SSRF là lỗ hổng bảo mật nguy hiểm không chỉ vì hậu quả nghiêm trọng mà còn vì bản chất khó phát hiện của nó. Khi request xuất phát từ chính máy chủ ứng dụng, các lớp bảo vệ truyền thống dễ bị qua mặt. Với sự phổ biến của kiến trúc microservices và môi trường cloud, bề mặt tấn công liên quan đến SSRF ngày càng mở rộng và đòi hỏi cách tiếp cận phòng thủ nhiều lớp. Phòng chống hiệu quả cần kết hợp validate URL nghiêm ngặt, phân tách mạng theo nguyên tắc Zero Trust, kiểm tra bảo mật định kỳ và một lớp WAF chuyên sâu.
Liên hệ đội ngũ VNETWORK ngay hôm nay để được tư vấn miễn phí:
- Hotline: 028 7306 8789
- Email: contact@vnetwork.vn
FAQ - Câu hỏi thường gặp về SSRF
1. SSRF thuộc nhóm nào trong OWASP Top 10?
SSRF được xếp vào hạng mục A10:2021 trong danh sách lỗ hổng bảo mật OWASP Top 10 phiên bản 2021. Đây là mục được bổ sung mới dựa trên dữ liệu từ cộng đồng bảo mật toàn cầu, phản ánh mức độ nghiêm trọng ngày càng tăng của lỗ hổng này trong môi trường cloud và microservices hiện đại.
2. Blind SSRF khác gì Basic SSRF?
Basic SSRF trả về kết quả trực tiếp cho kẻ tấn công thông qua response của ứng dụng, trong khi Blind SSRF không có output rõ ràng. Với Blind SSRF, kẻ tấn công phải suy luận qua kênh phụ như độ trễ phản hồi, DNS lookup ra ngoài hoặc thay đổi trạng thái hệ thống. Blind SSRF nguy hiểm hơn vì khó phát hiện hơn nhiều ngay cả với hệ thống giám sát thông thường.
3. SSRF có thể dẫn đến RCE không?
Có. SSRF có thể dẫn đến Remote Code Execution (RCE) trong các tình huống nhất định, đặc biệt khi kẻ tấn công dùng giao thức gopher:// để gửi lệnh đến các dịch vụ nội bộ không có xác thực như Redis, Memcached hoặc FastCGI. Đây là lý do SSRF không nên bị đánh giá thấp chỉ vì bề ngoài trông như một lỗ hổng đọc thông tin đơn giản.
4. WAF có chặn được SSRF không?
WAF thế hệ mới có khả năng phát hiện và chặn nhiều biến thể SSRF bằng cách phân tích nội dung request, kiểm tra URL đích và nhận diện schema giao thức bất thường. Tuy nhiên, WAF không thay thế hoàn toàn được việc validate URL ở tầng ứng dụng và phân tách mạng. Hiệu quả bảo vệ tốt nhất đạt được khi WAF là một lớp trong chiến lược phòng thủ nhiều lớp, không phải giải pháp duy nhất.
5. Làm thế nào để kiểm tra ứng dụng có lỗ hổng SSRF không?
Có một số cách để kiểm tra: thực hiện pentest thủ công bằng cách tìm các tham số nhận URL rồi thay bằng địa chỉ nội bộ hoặc địa chỉ DNS của bộ công cụ test ngoài (như Burp Collaborator); dùng công cụ tự động quét SSRF trong pipeline CI/CD; và kiểm tra log outbound request của server để phát hiện các kết nối bất thường đến địa chỉ nội bộ. Nên kết hợp cả ba phương pháp và thực hiện định kỳ, không chỉ một lần khi ra mắt sản phẩm.