Trang này được dịch bởi Cloud Translation API.

Thông tin xác thực phiên được liên kết với thiết bị (DBSC)
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Thông tin xác thực phiên được liên kết với thiết bị (DBSC) tăng cường xác thực bằng cách thêm tính năng bảo mật phiên được hỗ trợ bằng phần cứng.

Daniel Rubery

José Luis Zapata

Giới thiệu

Nhiều trang web dựa vào cookie tồn tại lâu để xác thực người dùng, nhưng các cookie này dễ bị xâm nhập phiên. Thông tin xác thực phiên được liên kết với thiết bị (DBSC) thêm một lớp bảo mật dựa trên phần cứng để giảm thiểu rủi ro này, đảm bảo các phiên được liên kết với các thiết bị cụ thể.

Hướng dẫn này dành cho các nhà phát triển duy trì quy trình xác thực trong ứng dụng web. Tài liệu này giải thích cách hoạt động của DBSC và cách tích hợp DBSC vào trang web của bạn.

Cách hoạt động của DBSC

Ở cấp độ cao, DBSC giới thiệu một cặp khoá mã hoá liên kết với thiết bị của người dùng. Chrome tạo cặp khoá này trong quá trình đăng nhập và lưu trữ khoá riêng tư trong phần cứng bảo mật, chẳng hạn như Mô-đun nền tảng đáng tin cậy (TPM) (nếu có). Phiên sử dụng cookie ngắn hạn. Khi một trong các cookie này hết hạn, Chrome sẽ chứng minh quyền sở hữu khoá riêng tư trước khi làm mới các cookie đó. Quá trình này liên kết tính năng liên tục phiên với thiết bị ban đầu.

Nếu thiết bị của người dùng không hỗ trợ tính năng lưu trữ khoá an toàn, thì DBSC sẽ quay lại hành vi tiêu chuẩn một cách linh hoạt mà không làm gián đoạn luồng xác thực.

Tổng quan về cách triển khai

Để tích hợp DBSC vào ứng dụng, bạn cần thực hiện các thay đổi sau:

Sửa đổi quy trình đăng nhập để thêm tiêu đề Sec-Session-Registration.
Thêm một điểm cuối đăng ký phiên có:
- Liên kết khoá công khai với phiên của người dùng.
- Phân phát cấu hình phiên.
- Chuyển sang cookie có thời gian tồn tại ngắn.
Thêm điểm cuối làm mới để xử lý việc gia hạn cookie và xác thực quyền sở hữu khoá.

Hầu hết các điểm cuối hiện có của bạn không yêu cầu thay đổi nào. DBSC được thiết kế để bổ sung và không gây gián đoạn.

Khi một cookie ngắn hạn bắt buộc bị thiếu hoặc hết hạn, Chrome sẽ tạm dừng yêu cầu và cố gắng làm mới cookie. Điều này cho phép ứng dụng của bạn tiếp tục sử dụng các bước kiểm tra cookie phiên thông thường để xác nhận người dùng đã đăng nhập. Vì khớp với quy trình xác thực thông thường, nên DBSC hoạt động với ít thay đổi đối với logic đăng nhập.

Các bước triển khai

Phần này trình bày các thay đổi cần thiết đối với hệ thống xác thực, bao gồm cả cách sửa đổi quy trình đăng nhập, xử lý việc đăng ký phiên và quản lý việc làm mới cookie ngắn hạn. Mỗi bước được thiết kế để tích hợp liền mạch với cơ sở hạ tầng hiện có của bạn.

Các bước triển khai tuân theo quy trình chung mà người dùng đã đăng nhập sẽ trải nghiệm khi DBSC đang hoạt động: đăng ký khi đăng nhập, sau đó là làm mới cookie ngắn hạn thường xuyên. Bạn có thể kiểm thử và triển khai từng bước một cách độc lập, tuỳ thuộc vào mức độ nhạy cảm của phiên trong ứng dụng.

Sơ đồ minh hoạ quy trình DBSC

1. Sửa đổi quy trình đăng nhập

Sau khi người dùng đăng nhập, hãy phản hồi bằng một cookie có thời gian tồn tại lâu và tiêu đề Sec-Session-Registration. Ví dụ:

Tiêu đề phản hồi HTTP sau đây được trả về sau khi đăng ký phiên thành công:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Nếu thiết bị hỗ trợ tính năng lưu trữ khoá an toàn, Chrome sẽ liên hệ với điểm cuối /StartSession bằng khoá công khai trong mã thông báo web JSON (JWT).

auth_cookie trong ví dụ này đại diện cho mã thông báo phiên. Bạn có thể đặt tên cho cookie này theo ý muốn, miễn là tên đó khớp với trường name trong cấu hình phiên và được sử dụng nhất quán trong toàn bộ ứng dụng.

2. Triển khai điểm cuối đăng ký phiên

Tại /StartSession, máy chủ của bạn phải:

Liên kết khoá công khai đã nhận được với phiên của người dùng.
Phản hồi bằng cấu hình phiên.
Thay thế cookie tồn tại lâu bằng cookie tồn tại ngắn.

Trong ví dụ sau, cookie ngắn hạn được định cấu hình để hết hạn sau 10 phút:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Triển khai điểm cuối làm mới

Khi cookie ngắn hạn hết hạn, Chrome sẽ bắt đầu một luồng làm mới để chứng minh việc sở hữu khoá riêng tư. Quá trình này bao gồm các hành động phối hợp của cả Chrome và máy chủ của bạn:

Chrome trì hoãn yêu cầu của người dùng đối với ứng dụng và gửi yêu cầu làm mới đến /RefreshEndpoint:
```
POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id
```

Máy chủ của bạn phản hồi bằng một thách thức:

HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "challenge_value"

Chrome ký thử thách bằng khoá riêng tư đã lưu trữ và thử lại yêu cầu:

POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id
Sec-Session-Response: <JWT proof>

Máy chủ của bạn xác thực bằng chứng đã ký và phát hành một cookie ngắn hạn đã làm mới:

HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

Chrome nhận được cookie đã làm mới và tiếp tục yêu cầu bị trì hoãn ban đầu.

Mẫu tích hợp thay thế

Để cải thiện khả năng phục hồi, các trang web có thể thêm một cookie thứ hai không phải DBSC cùng với cookie có thời gian tồn tại ngắn. Cookie tồn tại lâu này chỉ được dùng để phát hành mã thông báo mới có thời gian tồn tại ngắn và giúp phân biệt giữa các yêu cầu thực sự chưa được xác thực và các lỗi DBSC tạm thời.

Cookie có thời gian tồn tại lâu vẫn tồn tại ngay cả khi DBSC không thành công.
Cookie ngắn hạn được làm mới bằng DBSC và cần thiết cho các thao tác nhạy cảm.

Mẫu này giúp các trang web có nhiều quyền kiểm soát hơn đối với cách xử lý các trường hợp đặc biệt.

Lưu ý và hành vi dự phòng

Chrome có thể bỏ qua các hoạt động DBSC và gửi yêu cầu mà không cần cookie ngắn hạn do DBSC quản lý trong các trường hợp sau:

Không thể truy cập vào điểm cuối làm mới do lỗi mạng hoặc lỗi máy chủ.
TPM đang bận hoặc gặp lỗi ký. Vì TPM được chia sẻ giữa các quy trình hệ thống, nên việc làm mới quá mức có thể vượt quá giới hạn tốc độ của TPM.
Cookie ngắn hạn do DBSC quản lý là cookie của bên thứ ba và người dùng đã chặn cookie của bên thứ ba trong chế độ cài đặt trình duyệt.

Trong những trường hợp này, Chrome sẽ quay lại sử dụng cookie có thời gian lưu trữ dài nếu vẫn còn cookie như vậy. Phương án dự phòng này chỉ hoạt động nếu cách triển khai của bạn bao gồm cả cookie tồn tại trong thời gian dài và cookie tồn tại trong thời gian ngắn. Nếu không, Chrome sẽ gửi yêu cầu mà không có cookie.

Tóm tắt

Thông tin xác thực phiên được liên kết với thiết bị giúp cải thiện tính bảo mật của phiên với ít thay đổi nhất cho ứng dụng. Các phiên bản này cung cấp khả năng bảo vệ mạnh mẽ hơn trước hành vi xâm nhập phiên bằng cách liên kết các phiên với các thiết bị cụ thể. Hầu hết người dùng đều được hưởng lợi mà không gặp phải gián đoạn nào, đồng thời DBSC sẽ chuyển sang sử dụng phần cứng không được hỗ trợ một cách linh hoạt.

Để biết thêm thông tin, hãy tham khảo quy cách DBSC.