Tên miền con dùng chung, hai lối vào: ai thấy hồ sơ nào?

Phòng khám A và Phòng khám B dùng chung một cơ sở mã, hai tên miền con và một hỗn hợp khách truy cập từ văn phòng và qua VPN. Các nhóm mạng thường cấu hình hai lối vào riêng rẽ, và điều đó ổn, miễn là ứng dụng không làm vậy. Các kiểm tra dưới đây thuộc về ứng dụng và phải hành xử giống hệt nhau bất kể yêu cầu đi qua cửa nào.

Thứ nhất: tên máy chủ chỉ đặt tên cho một người thuê

Phân giải tên máy chủ được yêu cầu theo một ánh xạ mà quản trị viên duy trì, và từ chối mọi thứ không xác định. Dùng giá trị máy chủ đã được khung xác thực thay vì tiêu đề thô, để một Host giả mạo không thể chèn khóa tra cứu. Một kết quả khớp thành công cho mã biết cấu hình người thuê và thương hiệu nào cần tải. Nó không nói gì về việc bên gọi có được xem dữ liệu của người thuê đó hay không. Giữ câu hỏi thứ hai đó trong một hàm riêng với đầu vào riêng.

Một hàm trợ giúp dùng chung trả về cả ngữ cảnh và quyền từ một lần tra cứu tên máy chủ là khởi đầu của lỗi.

Thứ hai: tư cách thành viên đến từ phiên

Tra cứu các tư cách thành viên đang hoạt động của người dùng đã xác thực và so sánh với người thuê từ bước kiểm tra đầu tiên. Người dùng thuộc cả hai phòng khám có thể chuyển đổi, nhưng việc chuyển đổi phải là một hành động rõ ràng được ghi vào ngữ cảnh yêu cầu, không phải suy luận từ URL. Người dùng thuộc một phòng khám mà yêu cầu phòng khám kia sẽ bị từ chối, kể cả tải xuống và gọi API.

Kiểm tra trường hợp phủ định bằng cách sửa một định danh hồ sơ và một tham số người thuê. Nếu một trong hai thay đổi trả về dữ liệu, phạm vi đang được đọc từ yêu cầu chứ không phải từ tư cách thành viên đã xác minh.

Phạm vi cookie và đăng nhập một lần quyết định nơi một tài khoản có thể được trình bày. Chúng không quyết định tài khoản đó được đọc gì.

Thứ ba: mạng không chứng minh được gì về con người

Một cổng VPN xác thực đường hầm, và một danh sách cho phép công khai xác thực một dải địa chỉ. Không cái nào nhận diện một con người. NAT gom nhiều người dùng vào một địa chỉ nguồn, và một dải văn phòng làm điều tương tự cho mọi người trong tòa nhà. Hãy coi cả hai là sự kiện vận chuyển và giữ việc cấp quyền trong ứng dụng, hoặc trong một tích hợp khẳng định danh tính một cách rõ ràng và được xem xét đúng như vậy.

DNS là sự kiện vận chuyển thứ ba. Một câu trả lời riêng cần một tuyến riêng, và một giao diện công khai cần một đường dẫn gốc được hỗ trợ. Không cái nào mang theo quyền.

Một câu để treo lên tường: mạng quyết định yêu cầu đến như thế nào, và ứng dụng quyết định nó được đọc gì.

Thứ tư: chạy ma trận trên cả hai lối vào

Dùng các tài khoản có kiểm soát để thử A tại A, B tại B, A tại B, một tên máy chủ không xác định và một tài khoản đã xác thực không có tư cách thành viên. Mục thứ tư và thứ năm phải thất bại theo hướng đóng và không bao giờ rơi về một người thuê mặc định. Chạy cùng ma trận đó qua lối vào VPN nữa, với một lọ phiên cho mỗi tài khoản:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Sau đó thay đổi một mục trong danh sách cho phép và chạy lại. Một kết quả dịch chuyển nghĩa là một kiểm soát mạng đang đưa ra quyết định cấp quyền.

Lặp lại ma trận sau mọi thay đổi ở giao diện, vì một đường mã thứ hai bỏ qua bước kiểm tra là cách phổ biến nhất khiến ranh giới này xói mòn. Kết quả mong đợi thật nhàm chán: mọi lối vào đều cho cùng câu trả lời.