Tần suất cập nhật mã thông báo trong bảo mật CSRF thường xuyên như thế nào?


9

Để bắt đầu với nền, bài đăng này là những gì Jeff Atwood nói về mã thông báo CSRF. Trong chính trang này, anh tiếp tục nói:

Một phương pháp phòng ngừa thậm chí còn mạnh mẽ hơn, phức tạp hơn là tận dụng trạng thái máy chủ - để tạo (và theo dõi, hết thời gian) một khóa ngẫu nhiên duy nhất cho mỗi MẪU HTML duy nhất bạn gửi xuống máy khách. Chúng tôi sử dụng một biến thể của phương pháp này trên Stack Overflow rất thành công.

Nhưng trong bài đăng này, Jeff không bao giờ nhận xét về thời điểm và cách thức các mã thông báo nên được cập nhật.

Tôi đã sử dụng một kỹ thuật tương tự trong một ứng dụng web mà tôi đang làm việc. Nó hoạt động như thế này:

  1. Bất cứ khi nào người dùng sẽ POSTdữ liệu đến máy chủ của tôi, mã thông báo csrf sẽ được gửi cùng.
  2. Mã thông báo CSRF này được lưu trữ trong cookie mạnh về mật mã trong phiên của người dùng.
  3. Nếu mã thông báo hợp lệ, yêu cầu của người dùng được xử lý và ngược lại.
  4. Nếu yêu cầu hợp lệ, hãy loại bỏ mã thông báo cũ ở phía máy chủ và tạo mã thông báo mới. Phản hồi từ máy chủ chứa mã thông báo csrf mới sẽ được sử dụng trong yêu cầu tiếp theo. Mã thông báo cũ trên tất cả các biểu mẫu trên một trang được cập nhật với biểu mẫu mới để yêu cầu tiếp theo được xử lý đúng cách.

Có phải là khôn ngoan để cập nhật mã thông báo sau khi POSTyêu cầu hoặc chỉ nên thực hiện cập nhật bất cứ khi nào người dùng đưa ra GETyêu cầu và giữ cùng mã thông báo cho đến khi yêu cầu GET tiếp theo được thực hiện?


prolly này thuộc về security.stackexchange.com
tylerl 17/03/2016

Câu trả lời:


10

Điểm chính của mã thông báo CSRF là nó không thể được gửi từ một trang web khác. Do đó, kẻ tấn công không thể dự đoán hoặc phát hiện ra (a) và (b) không được tự động đính kèm theo yêu cầu theo cách của cookie.

Vì vậy, về mặt lý thuyết nếu mã thông báo CSRF không bao giờ được tiết lộ cho bên thứ ba, một lần nữa về mặt lý thuyết, bạn hoàn toàn không phải hết hạn sử dụng chúng. Nhưng sau đó, bạn có nguy cơ mã thông báo của bạn bị "rò rỉ" bằng cách nào đó. Vì vậy, thời hạn sử dụng của bạn thực sự nên đủ ngắn để chống lại viễn cảnh mã thông báo thoát ra và được sử dụng để chống lại người dùng của bạn.

Thực sự không có bất kỳ hướng dẫn nào, nhưng một kỹ thuật vững chắc tốt là tự động tạo mã thông báo mới theo MỌI yêu cầu nhúng mã thời gian đã ký và sau đó chấp nhận mã thông báo đến một độ tuổi nhất định.

Một hàm mẫu có thể là:

concat(current_time,salt,sha256_sum(concat(salt,userid,current_time,secret_string)))

Mã thông báo chứa thông tin về thời gian và muối, nhưng cũng chứa chữ ký không thể giả mạo và được gắn với userid.

Sau đó, bạn có thể xác định khoảng thời gian hết hạn của riêng mình - một giờ, một ngày, 2 giờ. Bất cứ điều gì. Khoảng thời gian trong trường hợp này không được gắn với mã thông báo, vì vậy bạn có thể đặt các quy tắc hết hạn theo cách bạn muốn.

Tuy nhiên, ít nhất, các mã thông báo CSRF sẽ hết hạn khi phiên đăng nhập hết hạn hoặc khi người dùng đăng xuất. Người dùng không mong đợi rằng một biểu mẫu mà bạn đã đưa ra TRƯỚC KHI bạn đã đăng xuất sẽ tiếp tục hoạt động SAU khi bạn đăng nhập lại.


"Vì vậy, về mặt lý thuyết nếu mã thông báo CSRF không bao giờ được tiết lộ cho bên thứ ba". Nhưng không phải là mã thông báo trong mã html của biểu mẫu? Tôi bị bối rối.
c0da

1
Tôi là bên thứ nhất, bạn, người tôi đang nói chuyện, là bên thứ hai. Có người nghe lén từ bên ngoài là bên thứ ba. Đây là lý do tại sao việc chia sẻ cùng một mã thông báo giữa những người dùng khác nhau là thảm họa.
tylerl 17/03/2016
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.