Bỏ qua điều hướng
Blog

Webhook outbound: kiểm soát đích gửi để tránh truy cập mạng nội bộ

Webhook outbound cần kiểm soát URL, DNS, đích kết nối và redirect. Khung rà soát SSRF để chặn truy cập mạng nội bộ trong phạm vi được cấp quyền.

Chia sẻFacebookLinkedInZalo
webhook outbound: minh họa ranh giới url đăng ký, dns và địa chỉ thật lúc kết nối
Nội dung bài viết

Cho khách đăng ký URL nhận thông báo là một tính năng tiện lợi, nhưng cũng trao cho hệ thống quyền gửi request tới một đích do người khác chọn. Webhook outbound cần bảo vệ mạng và tài nguyên của bên gửi, bên cạnh việc ký thông báo cho bên nhận.

Chữ ký thông báo không quyết định đích có an toàn

Chữ ký giúp bên nhận xác minh nguồn và nội dung theo giao thức. Nó không chứng minh URL mà khách nhập là một nơi công khai được phép gọi. Một dịch vụ ký đầy đủ vẫn có thể bị yêu cầu truy cập một địa chỉ nội bộ nếu không kiểm soát đích. Hai phía của webhook có ranh giới tin cậy khác nhau, nên không gom mọi kiểm tra vào một ô “đã bảo mật”.

Trong hướng dẫn phòng SSRF của OWASP, custom webhook là một trường hợp URL do người dùng kiểm soát dẫn đến request từ máy chủ. Nội dung dưới đây bàn thiết kế phòng vệ và nghiệm thu trong môi trường được cấp quyền; không phải hướng dẫn dò mạng của bên khác.

Kiểm URL lúc đăng ký mới chỉ là lớp đầu

Bộ phân tích URL cần xác định scheme, hostname và cổng theo chính sách. Với hệ thống chỉ cần HTTPS, không mở thêm giao thức khác chỉ vì thư viện HTTP hỗ trợ. Nếu đối tác và đích đã biết, danh sách đích được phép có thể hẹp hơn việc cho nhập bất kỳ URL nào. Chuẩn hóa phải dùng parser đáng tin, không dùng một regex sơ sài thay toàn bộ quy tắc địa chỉ.

Không ghi dữ liệu xác thực trong query rồi lưu nguyên URL vào log. Quy trình đăng ký cần quyền sửa callback, lịch sử thay đổi và cách xác nhận đối tác sở hữu đích theo yêu cầu. Tuy nhiên, một lần xác nhận đích không thay việc kiểm đường kết nối về sau. Đích và DNS có thể thay đổi sau lúc đăng ký.

Địa chỉ thật lúc kết nối mới là ranh giới quan trọng

Hostname công khai có thể phân giải tới nhiều địa chỉ. Cần kiểm IPv4 và IPv6, các dải không công khai và tài nguyên đặc biệt theo chính sách mạng. Bước kiểm và bước kết nối phải dùng cùng kết quả được kiểm chứng; nếu thư viện tự phân giải lại sang địa chỉ khác, một lần kiểm trước đó chưa bảo vệ cuộc gọi thực tế.

Redirect cũng tạo request mới. Có thể tắt tự theo redirect nếu tính năng không cần; nếu cần, mỗi chặng phải chịu cùng chính sách đích. Đừng chỉ kiểm URL đầu rồi tin mọi nơi mà phản hồi chuyển hướng tới. Một cấu hình mạng hạn chế outbound tạo thêm lớp bảo vệ, nhưng phải xét đúng egress proxy, DNS và đường đi thực tế.

URL đăng ký khác DNS đã phân giải và IP thật lúc kết nối
URL đăng ký khác DNS đã phân giải và IP thật lúc kết nối. Sơ đồ biên tập; số liệu hoặc tình huống trong hình là giả định, không phải log hay kết quả khách hàng.

Ba tình huống đủ để thấy các lớp kiểm khác nhau

Ví dụ giả định, một callback HTTPS của đối tác đã được xác nhận và IP thật thuộc nhóm được phép: có thể gửi theo hợp đồng. Một hostname trả về địa chỉ nội bộ: chặn và ghi lý do tối thiểu. Một đích ban đầu hợp lệ chuyển hướng sang nơi chưa xác minh: không tiếp tục chỉ để báo gửi thành công.

Tình huống mô phỏng Quyết định phòng vệ
Đích công khai đúng chính sách Gửi có giới hạn thời gian và dung lượng
Địa chỉ thật không công khai Chặn trước kết nối
Redirect sang đích ngoài chính sách Dừng hoặc kiểm lại từng chặng

Không công bố chi tiết mạng nội bộ trong lỗi trả khách. Người vận hành cần mã lý do và mã đăng ký để điều tra, còn khách cần biết callback bị từ chối và phải sửa gì. Danh sách dải địa chỉ và hành vi parser phải được duy trì theo thư viện, nền tảng và chính sách hiện tại; bảng ba dòng không phải bộ lọc đầy đủ.

Mô phỏng đích công khai, nội bộ và đích chưa xác minh
Mô phỏng đích công khai, nội bộ và đích chưa xác minh. Sơ đồ biên tập; số liệu hoặc tình huống trong hình là giả định, không phải log hay kết quả khách hàng.

Giới hạn quyền và dữ liệu của bộ gửi

Worker gửi callback không nên mang theo thông tin xác thực dùng cho dịch vụ nội bộ không liên quan. Tách dữ liệu mỗi đối tác và chỉ gửi sự kiện họ được nhận. Đặt giới hạn thời gian chờ, lượng byte phản hồi và mức song song; một đích hợp lệ nhưng trả dữ liệu rất lớn vẫn có thể làm cạn tài nguyên.

Log nên phục vụ điều tra mà không chứa secret ký, Authorization header hoặc toàn bộ dữ liệu khách hàng. Các lỗi bị chặn không nên tự kích hoạt một đường fallback bỏ kiểm tra. Nếu chính sách thay đổi, cần biết đăng ký cũ nào chịu ảnh hưởng và cách thông báo người có quyền, không âm thầm mở ngoại lệ rộng.

Nghiệm thu đường đi, không chỉ tên hàm kiểm

Đội kỹ thuật nên chuẩn bị các đích giả lập do mình sở hữu để kiểm URL không đúng scheme, IPv6, phân giải nhiều địa chỉ, redirect và thay đổi DNS có kiểm soát. Kiểm cả HTTP client, proxy và lớp mạng: một hàm validation đúng chưa chứng minh request đi qua đúng hàm đó ở mọi nhánh. Không chạy các ca này vào hạ tầng không được phép.

Bước xác minh chữ ký webhook ở phía nhận là chủ đề khác cần giữ nguyên owner. Khi phụ thuộc chậm, cơ chế ngắt gọi có kiểm soát giúp bảo vệ khả dụng nhưng không thay chính sách đích. Có thể khảo sát phần tích hợp với Onter từ sơ đồ trust boundary đã che dữ liệu; không gửi secret hoặc URL nội bộ nhạy cảm qua form công khai.

Tài khoản Onter

Đăng nhập rồi tiếp tục việc đang làm.

Mở trang đăng nhập riêng nếu trình duyệt chưa hiển thị biểu mẫu.

Contact Me on Zalo