Liên kết danh sách IP được phép tạm thời: điều mà sự cho phép thực sự chấp nhận

Biến một cú nhấp thành một quy tắc tường lửa tạm thời thì tiện lợi, và nó cũng dựng nên một hệ thống ủy quyền quyết định ai được tiếp cận một dịch vụ. Thứ nó cấp là một địa chỉ chứ không phải một người, và khác biệt đó có ý nghĩa ngay từ lúc hai người dùng chung một NAT. Hãy giới hạn phạm vi của sự cho phép, xác nhận nó một cách có chủ đích và làm cho việc hết hạn có ý nghĩa trước khi liên kết được tạo. Quyết định trước mắt là đặt ranh giới ở đâu, chứ không phải có nên tồn tại một ranh giới hay không.

Quyết định sự cho phép trả lời câu hỏi nào

Hãy bắt đầu từ yêu cầu. Nếu một người được nêu tên phải tiếp cận dịch vụ và ứng dụng đã xác thực người đó, một cổng đã xác thực giữ danh tính tại điểm thực thi và hoàn toàn không cần chấp nhận địa chỉ. Nếu mục tiêu là một tác nhân build, một cổng nhảy quản trị hoặc một thiết bị không thể tham gia đăng nhập người dùng, một sự cho phép địa chỉ có phạm vi hẹp có thể là biện pháp kiểm soát thực tế duy nhất.

Chọn chấp nhận theo địa chỉ cho một ứng dụng hướng tới người dùng sẽ chuyển vấn đề ủy quyền thực sự sang nơi khác, và sau đó cổng thông tin thừa hưởng lỗi về một lỗ hổng mà nó chưa bao giờ đóng lại.

Giới hạn yêu cầu trên máy chủ

Trình duyệt không được chọn đích, cổng hay tiền tố. Cổng thông tin phân giải dịch vụ từ hồ sơ của chính nó và kiểm tra quyền bằng một phép thử phía máy chủ, đó là nguyên tắc mà hướng dẫn ủy quyền của OWASP áp dụng cho mọi yêu cầu. Việc suy ra địa chỉ cũng thuộc về ranh giới được bảo vệ: khi proxy ngược báo địa chỉ của máy khách, chỉ chấp nhận chuỗi proxy đã cấu hình và cách xử lý tiêu đề đã được ghi lại. Tiêu đề chuyển tiếp do khách cung cấp là một khẳng định về nguồn gốc, không phải bằng chứng về nó.

Sau đó kiểm tra xem cổng thông tin và dịch vụ có thấy cùng một nguồn hay không. Đường hầm tách rời, một bước nhảy proxy và IPv4 so với IPv6 có thể cho hai đích hai địa chỉ khác nhau, vì vậy một sự cho phép được kích hoạt qua một đường có thể không bao phủ yêu cầu tiếp theo.

Hiển thị sự cho phép trước khi cài đặt

Mở một liên kết nên hiển thị dịch vụ được đề xuất, nguồn quan sát được và thời hạn, và chưa thay đổi gì. Bước duy nhất đó biến liên kết từ email từ một hành động thành một đề xuất, và nó ngăn bot xem trước hoặc trình quét thư cấp quyền truy cập chỉ bằng cách tải liên kết.

Xác nhận nên là một yêu cầu thay đổi trạng thái với các biện pháp phòng vệ chéo trang và nguồn gốc thông thường. Mã thông báo nên dùng một lần và được tiêu thụ nguyên tử ngay tại thời điểm quy tắc được cài đặt, và bản ghi nên ghi lại chủ sở hữu, dịch vụ, địa chỉ, định danh sự cho phép và thời hạn mà không bao giờ ghi nhật ký mã thông báo thô.

Việc gửi mã thông báo xứng đáng được chăm sóc như chính quy tắc. Một liên kết đã hết hạn hoặc đã dùng nhưng vẫn tạo ra quy tắc là cánh cửa thứ hai gắn cùng một chìa khóa.

Địa chỉ được chia sẻ ngay cả khi sự cho phép còn sống

Một NAT văn phòng, một NAT nhà mạng và một lối ra VPN dùng chung đều đặt nhiều người sau một địa chỉ. Chấp nhận địa chỉ đó là chấp nhận tất cả người phía sau nó — xét về ranh giới tiếp theo của dịch vụ —, trong khi không chứng minh được gì về việc ai đang giữ tài khoản mà dịch vụ mong đợi.

Bỏ quy tắc cũng không phải là một sự ngắt kết nối phổ quát. Các kết nối đã thiết lập, mã thông báo ứng dụng trong bộ nhớ đệm và các phiên dài hạn có thể sống lâu hơn quy tắc vài phút hoặc lâu hơn nhiều, vì vậy thời gian sống bạn chọn nên phản ánh điều dịch vụ làm sau khi chấp nhận chứ không chỉ việc quy tắc tồn tại bao lâu.

Kiểm thử bốn trường hợp và cả hai họ địa chỉ

Một sự cho phép chỉ tốt bằng bốn trường hợp mà nó vượt qua: một yêu cầu mới được phép, một người yêu cầu chưa được phê duyệt, một lần phát lại cùng liên kết và cùng yêu cầu đó sau khi hết hạn.

Sau đó kiểm thử từng họ riêng biệt, vì địa chỉ nguồn mà dịch vụ quan sát có thể khác nhau giữa chúng.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

Kết quả hữu ích là một quyết định chấp nhận tạm thời, có thể kiểm toán, nằm dưới sự ủy quyền người dùng bình thường, thay vì một lỗ mở vĩnh viễn mang tên người nhấp trước.