Làm cách nào để thực hiện xác thực không trạng thái (ít phiên) và không có cookie?

Bob sử dụng một ứng dụng web để đạt được điều gì đó. Và:

• Trình duyệt của anh ấy đang ở chế độ ăn kiêng, do đó nó không hỗ trợ cookie .
• Ứng dụng web là một ứng dụng phổ biến, nó giao dịch với rất nhiều người dùng tại một thời điểm nhất định - nó phải mở rộng quy mô tốt. Miễn là việc duy trì phiên sẽ áp đặt giới hạn số lượng kết nối đồng thời và tất nhiên, sẽ mang lại hình phạt hiệu suất , chúng tôi có thể muốn có một hệ thống ít phiên :)

Một số lưu ý quan trọng:

• chúng tôi có an ninh vận tải ( HTTPS và những người bạn tốt nhất của nó);
• đằng sau bức màn, ứng dụng web ủy quyền rất nhiều hoạt động cho các dịch vụ bên ngoài , thay mặt cho người dùng hiện tại (những hệ thống đó công nhận Bob là một trong những người dùng của họ) - điều này có nghĩa là chúng tôi phải chuyển tiếp cho họ thông tin đăng nhập của Bob .

Bây giờ, làm cách nào để chúng tôi xác thực Bob (theo từng yêu cầu)? Đó sẽ là một cách hợp lý để thực hiện một điều như vậy?

• chơi quần vợt với các thông tin xác thực thông qua các trường ẩn dạng HTML ... bóng chứa thông tin xác thực ( tên người dùng & mật khẩu ) và hai vợt tương ứng là trình duyệt và ứng dụng web. Nói cách khác, chúng tôi có thể vận chuyển dữ liệu qua lại qua các trường biểu mẫu thay vì qua cookie. Ở mỗi yêu cầu web, trình duyệt sẽ đăng thông tin đăng nhập. Mặc dù, trong trường hợp ứng dụng một trang , điều này có thể giống như chơi bóng quần trên tường cao su, thay vì chơi quần vợt , vì biểu mẫu web chứa thông tin đăng nhập có thể được duy trì trong suốt thời gian tồn tại của trang web (và máy chủ sẽ được định cấu hình để không cung cấp lại thông tin xác thực).
• lưu trữ tên người dùng và mật khẩu trong ngữ cảnh của trang - các biến JavaScript, v.v. Yêu cầu trang đơn ở đây, IMHO.
• xác thực dựa trên mã thông báo được mã hóa. Trong trường hợp này, hành động đăng nhập sẽ dẫn đến việc tạo mã thông báo bảo mật được mã hóa (tên người dùng + mật khẩu + thứ gì đó khác). Mã thông báo này sẽ được phục vụ trở lại khách hàng và các yêu cầu sắp tới sẽ được đi kèm với mã thông báo. Điều này có nghĩa không? Chúng tôi đã có HTTPS ...
• khác...
• phương sách cuối cùng: không làm điều này, lưu trữ thông tin đăng nhập trong phiên! Phiên là tốt. Có hoặc không có cookie.

Bạn có lo lắng về web / bảo mật nào liên quan đến bất kỳ ý tưởng nào được mô tả trước đây không? Ví dụ,

• time-outing - chúng tôi có thể giữ một dấu thời gian , cùng với thông tin đăng nhập (time-mark = thời gian Bob nhập thông tin đăng nhập của mình). Vd: khi nào NOW - dấu thời gian> ngưỡng , chúng tôi có thể từ chối yêu cầu.
• Bảo vệ tập lệnh trên nhiều trang web - không nên khác biệt theo bất kỳ cách nào, phải không?

Cảm ơn bạn rất nhiều vì đã dành thời gian để đọc này :)

Ah, tôi thích những câu hỏi này - duy trì một phiên mà không có một phiên.

Tôi đã thấy nhiều cách để thực hiện việc này trong thời gian làm việc của mình trong quá trình đánh giá ứng dụng. Một trong những cách phổ biến là chơi quần vợt mà bạn đã đề cập - gửi tên người dùng và mật khẩu trong mọi yêu cầu để xác thực người dùng. Điều này, theo ý kiến ​​của tôi, là không an toàn, đặc biệt nếu ứng dụng không phải là một trang. Nó cũng không thể mở rộng, đặc biệt nếu bạn muốn thêm ủy quyền cho ứng dụng của mình ngoài xác thực trong tương lai (mặc dù tôi đoán bạn cũng có thể xây dựng thứ gì đó dựa trên thông tin đăng nhập)

Một cơ chế phổ biến, mặc dù không phải hoàn toàn không trạng thái (giả sử bạn có thực thi JavaScript) là nhúng cookie phiên vào JavaScript. Nhân viên an ninh trong tôi đang la hét về điều này, nhưng nó thực sự có thể hoạt động - mọi yêu cầu đều cóX-Authentication-Tokentiêu đề hoặc thứ gì đó tương tự, và bạn ánh xạ nó tới cơ sở dữ liệu, tệp lưu trữ trong bộ nhớ, v.v. trên phần phụ trợ để xác thực người dùng. Mã thông báo này có thể có thời gian chờ bất cứ lúc nào bạn chỉ định và nếu hết thời gian, người dùng phải đăng nhập lại. Nó khá dễ mở rộng - nếu bạn lưu trữ nó trong một cơ sở dữ liệu, một câu lệnh SQL của nó được thực thi và với các chỉ mục chính xác, sẽ mất rất ít thời gian để thực thi, ngay cả với nhiều người dùng đồng thời. Kiểm tra tải ở đây chắc chắn sẽ hữu ích. Nếu tôi đọc đúng câu hỏi, đây sẽ là cơ chế mã thông báo được mã hóa của bạn - mặc dù vậy, tôi thực sự khuyên bạn nên sử dụng mã thông báo ngẫu nhiên mật mã gồm 32 ký tự, thay vì sử dụng kết hợp tên người dùng + mật khẩu + bất kỳ thứ gì khác - theo cách này, nó vẫn không thể đoán trước, nhưng bạn vẫn có thể liên kết nó với ID người dùng hoặc một số thứ tương tự.

Cho dù bạn kết thúc bằng cách sử dụng nào, hãy đảm bảo nó được gửi đến bạn một cách an toàn. HTTPS bảo vệ bạn trên toàn tuyến, nhưng nó không bảo vệ bạn nếu bạn làm rò rỉ mã thông báo phiên qua URL (hoặc tệ hơn là thông tin xác thực qua URL). Tôi khuyên bạn nên sử dụng tiêu đề hoặc nếu điều đó không khả thi, hãy gửi mã thông báo qua yêu cầu POST mỗi lần (điều này có nghĩa là trường biểu mẫu ẩn trên trình duyệt của người dùng.) Cách tiếp cận sau khi sử dụng yêu cầu POST nên sử dụng biện pháp bảo vệ CSRF, chỉ trong trường hợp, mặc dù tôi nghi ngờ việc sử dụng mã thông báo có thể là một loại biện pháp bảo vệ CSRF.

Cuối cùng, nhưng không kém phần quan trọng, hãy đảm bảo rằng bạn có một số cơ chế trong phần phụ trợ để thanh lọc các mã thông báo đã hết hạn. Đây là điểm hạn chế của nhiều ứng dụng trong quá khứ - một cơ sở dữ liệu mã thông báo xác thực đang phát triển nhanh chóng dường như không bao giờ biến mất. Nếu bạn cần hỗ trợ nhiều thông tin đăng nhập của người dùng, hãy đảm bảo rằng bạn giới hạn số lượng hoặc giới hạn thời gian ngắn hơn cho mỗi mã thông báo. Như tôi đã nói trước đây, thử nghiệm tải có thể là câu trả lời cho điều này.

Có một số lo ngại về bảo mật khác mà tôi có thể nghĩ đến, nhưng chúng quá rộng để giải quyết ở giai đoạn này - nếu bạn lưu ý đến tất cả các trường hợp sử dụng (và lạm dụng), có lẽ bạn sẽ có thể triển khai khá tốt hệ thống này.

Về tùy chọn đăng nhập - Tôi nghĩ rằng thông thường bạn cũng muốn hỗ trợ các phiên cho khách.

Vì vậy, nếu bạn muốn thực thi đăng nhập, tùy chọn mã thông báo được mã hóa có thể tốt. Nó cũng có thể tốt cho phiên khách bằng cách nào đó. Theo một hướng khác, tôi sẽ kết hợp giữa việc gắn mã thông báo vào URL và tùy chọn quần vợt.

Lưu ý rằng chỉ gửi thông tin xác thực trong URL có thể nguy hiểm. Ví dụ: bạn có thể làm rò rỉ mã thông báo qua tiêu đề giới thiệu HTTP hoặc thậm chí bởi ai đó chỉ kiểm tra lưu lượng truy cập hoặc xem máy tính của bạn.

Một điều khác, ngay cả khi bạn có thể sử dụng cookie, tôi khuyên bạn nên thêm mã thông báo ngẫu nhiên hoặc người xác minh ngẫu nhiên, để bảo vệ bạn khỏi các cuộc tấn công Truy vấn Yêu cầu Trang web chéo (CSRF).