Tên miền con quản trị không chặn CSRF: bốn kiểm tra trước khi ra mắt

Chuyển giao diện quản trị sang admin.example.com là cải thiện thật: nó giữ cookie quản trị tránh xa các trang công khai, cho hai ứng dụng bộ nhớ đệm riêng và cho phép bạn hướng chính sách mạng chặt hơn vào một tên máy chủ. Nhưng đó không phải kiểm soát CSRF, và nó không làm mã của trang công khai an toàn để mở trước một quản trị viên đã đăng nhập. Việc tách ra thay đổi điều trình duyệt coi là ranh giới, không phải điều máy chủ kiểm tra, vì vậy hãy làm bốn kiểm tra này trước khi nói đã xong.

Đọc nguồn gốc và trang như hai từ khác nhau

Nguồn gốc là lược đồ, máy chủ và cổng, nên https://www.example.com và https://admin.example.com là hai nguồn gốc khác nhau. Trang theo nghĩa SameSite là lược đồ cộng tên miền đăng ký được, nên hai tên máy chủ đó thường là cùng một trang. Chính khác biệt này là toàn bộ cái bẫy: thuộc tính SameSite sẽ không giúp bạn giữa các tên miền con anh em, vì trình duyệt hoàn toàn không coi yêu cầu là liên trang. Hướng giao diện quản trị sang một tên miền đăng ký được thực sự khác, chẳng hạn admin-example.net, và yêu cầu thực sự trở thành liên trang, và đó là nơi SameSite=Lax hoặc Strict bắt đầu làm công việc bạn có thể tin cậy.

Hãy thử trong trình duyệt thay vì suy luận về nó.

Tải trang công khai, mở công cụ dành cho nhà phát triển và xem trình duyệt gắn cookie nào vào yêu cầu hướng tới máy chủ quản trị. Nếu cookie không có thuộc tính Domain, nó chỉ dành cho máy chủ và ở lại trên tên của nó; nếu nó mang Domain=example.com, nó đi tới mọi anh em, và tên miền con mới không mang lại gì cho cookie đó.

Tách việc đọc phản hồi khỏi việc gửi yêu cầu

Chính sách cùng nguồn gốc hạn chế việc đọc phản hồi giữa các nguồn gốc. Nó không ngăn yêu cầu được gửi đi, và không ngăn biểu mẫu mang thông tin đăng nhập mà trình duyệt đã có. Một yêu cầu đơn giản, với kiểu nội dung biểu mẫu hoặc GET thường, được gửi đến mà không kiểm tra trước; sau đó CORS quyết định script gọi có được đọc phản hồi hay không. CSRF sống hoàn toàn ở phía gửi.

Vì vậy máy chủ cần kiểm tra rõ ràng cho các thao tác thay đổi trạng thái. Một token đồng bộ gắn với phiên, hoặc cookie gửi hai lần được so sánh trên máy chủ, bao phủ trường hợp đó; so sánh Origin hoặc Referer đáng để thêm làm cổng thứ hai nhưng không phải cổng duy nhất, vì không phải yêu cầu nào cũng mang tiêu đề đó và không phải proxy nào cũng giữ nó. Hướng dẫn của OWASP về phòng chống CSRF coi SameSite là một lớp trong nhiều lớp, chính vì lý do này.

Quyết định cổng mạng thực sự chứng minh điều gì

Danh sách cho phép các lối ra VPN trước máy chủ quản trị là kiểm soát tốt và một tuyên bố danh tính yếu. Nó chứng minh yêu cầu đến từ một địa chỉ mà VPN cấp, mà mọi người ở lối ra đó có thể chia sẻ, và không nói gì về người hay thiết bị đứng sau. Hãy coi đó là bộ lọc đầu vào, không phải xác thực.

Giữ nó độc lập với các kiểm tra ở mức yêu cầu. Nếu danh sách là thứ duy nhất giữa kẻ tấn công và một điểm cuối thay đổi trạng thái, một tuyến cấu hình sai, một máy khách split-tunnel hoặc một máy tính xách tay đi mượn sẽ loại bỏ hoàn toàn kiểm soát đó.

Ghi nhật ký cả các từ chối ngoài phạm vi mong đợi. Sự bùng nổ của chúng là tín hiệu hữu ích nhất cho thấy ai đó đang dò ranh giới bạn vừa dựng, và sự im lặng là tín hiệu cho thấy bộ lọc hoàn toàn không được chạm tới.

Giữ cookie, đăng nhập và quyền rõ ràng

Phạm vi cookie quyết định phần lớn kết quả. Cookie của miền cha được gửi tới máy chủ quản trị, nên việc chèn script trên trang công khai có thể hành động với phiên của quản trị viên; cookie chỉ dành cho máy chủ thì không thể. Ưu tiên dạng chỉ dành cho máy chủ, thêm thuộc tính Secure và dùng tiền tố __Host- ở nơi nền tảng hỗ trợ, vì tiền tố đó đòi hỏi Secure, Path=/ và không có thuộc tính Domain. Đọc tiêu đề phản hồi chứ không phải hũ cookie: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, không có thuộc tính Domain. Trình duyệt loại bỏ cookie __Host- có Domain, nên một cookie vẫn còn xuất hiện trên các máy chủ anh em là bằng chứng tiền tố chưa bao giờ được áp dụng.

Sau đó giữ quyền trên máy chủ, cho mỗi yêu cầu, tại mỗi điểm cuối quản trị, không chỉ khi đăng nhập. Yêu cầu từ mạng được phép vẫn phải được xác thực và cấp quyền cho thao tác nó yêu cầu; tên máy chủ không phải chủ thể. Nếu ứng dụng công khai và quản trị chia sẻ luồng đăng nhập hoặc kho phiên, hãy ghi lại mối quan hệ đó, vì đó là đường ngắn nhất từ lỗi trên trang công khai đến một hành động quản trị.

Kiểm tra lại ranh giới sau khi tách

Chạy các bài kiểm tra phủ định, không chỉ đường vui vẻ: biểu mẫu liên trang không có token phải bị từ chối, token từ phiên khác phải bị từ chối, và không GET nào được thay đổi trạng thái. Kiểm tra các thuộc tính cookie trong công cụ dành cho nhà phát triển, xác nhận kiểm tra Origin kích hoạt trên yêu cầu không khớp, và thử máy chủ quản trị từ ngoài phạm vi VPN để thấy bộ lọc hoạt động.

Không điều nào trong số này loại bỏ lỗi XSS bên trong chính ứng dụng quản trị. Một tên máy chủ riêng là ranh giới cô lập phía trình duyệt có giá trị thực, và nó không thay thế việc ngăn thực thi mã không an toàn hay bảo vệ yêu cầu phía máy chủ. Sau khi tách, danh sách ngắn hơn vẻ ngoài: nguồn gốc riêng, cookie chỉ dành cho máy chủ, token ở mỗi thay đổi, bộ lọc đầu vào mà bạn không tin làm danh tính, và quyền được quyết định cho từng yêu cầu.