Có thể sử dụng cookie phiên (mã hóa mạnh) làm mã thông báo CSRF không?

Question

Đọc OWASP CSRF prevention cheat sheet, một trong những phương pháp được đề xuất để ngăn chặn các loại tấn công này là mẫu mã thông báo đồng bộ hóa.

Nếu mã thông báo phiên mạnh mã hóa, nó có thể tăng gấp đôi mã thông báo csrf như được mô tả trong mã giả sau không?

Chủ đầu tư:

<script> 
dom.replace(placeholder, getCookie("session-cookie")) 
</script> 

<form> 
<input type="hidden" name="csrf-cookie" value="placeholder-value"/> 
<input type="text" /> 
</form> 

Server:

if(request.getParameter("csrf-cookie") != user.getSessionCookie()) 
    print "get out you evil hacker" 

Cookie được thiết lập với javascript trên tải trang để ngăn chặn người dùng vô tình bị rò rỉ cookie phiên làm việc nếu họ ví dụ gửi một bản sao của trang cho một người bạn.

Answer 1

Bất kỳ nội dung nào không thể được truy xuất bởi trang bên ngoài đều có thể được sử dụng làm mã thông báo CSRF. Vì vậy, nội dung của cookie phiên là tốt cho việc này.

Answer 2

Không, bạn không nên sử dụng lại mã thông báo phiên làm mã thông báo CSRF của mình. Các OWASP CSRF phòng chống cheat sheet cho lý do tại sao bằng cách sử dụng định danh phiên như một CSRF token là không mong muốn:

Trong khi phương pháp này là hiệu quả trong việc giảm thiểu nguy cơ cross-site yêu cầu giả mạo, bao gồm định danh phiên chứng thực trong các thông số HTTP có thể tăng nguy cơ tổng thể của việc chiếm đoạt phiên. Kiến trúc sư và nhà phát triển phải đảm bảo rằng không có thiết bị mạng hoặc mã ứng dụng tùy chỉnh hoặc mô-đun đăng nhập rõ ràng hoặc tiết lộ thông số POST HTTP.

và

Bao gồm các định danh session trong mã HTML cũng có thể được thừa hưởng bởi các cuộc tấn công cross-site scripting để vượt qua sự bảo vệ HttpOnly. Hầu hết các trình duyệt hiện đại đều ngăn chặn tập lệnh phía máy khách truy cập vào cookie HTTPOnly. Tuy nhiên, bảo vệ này sẽ bị mất nếu các định danh phiên HTTPOnly được đặt trong HTML dưới dạng tập lệnh phía máy khách có thể dễ dàng duyệt và trích xuất từ ​​định danh DOM. Các nhà phát triển vẫn được khuyến khích triển khai mẫu mã thông báo đồng bộ hóa như được mô tả trong bài viết này.

Here là một số suy nghĩ khác về lý do tại sao nên sử dụng id phiên làm mã thông báo CSRF. This article đề cập đến gói sniffing trên các kết nối http đơn giản và khả năng thực hiện các cuộc tấn công man-in-the-middle vào chúng như những rủi ro tiềm ẩn.

Do đó, điều quan trọng là mã thông báo CSRF là mã thông báo khác, nếu không mã thông báo CSRF sẽ không thể đoán được nếu chúng tôi cho rằng kẻ tấn công đã biết số nhận dạng phiên! Đặt phòng thủ nhiều hơn: Có thể không phải là một ý tưởng hay khi chơi với lửa: không cần phải sử dụng lại id phiên làm mã thông báo CSRF, bằng cách làm như vậy bạn chỉ mở một bề mặt tấn công khác có khả năng bị khai thác. Không sử dụng lại, không phải lo lắng về điều đó. Do đó, mặc dù mã thông báo phiên được bảo mật về mặt mã hóa, nhưng nó cũng phải độc lập (cũng theo nghĩa xác suất) từ mã thông báo CSRF cho toàn bộ công việc hoạt động theo các giả định trên. Đó cũng là lý do tại sao bất kỳ ví dụ triển khai nào cũng luôn tạo mã thông báo của họ từ đầu.

Bạn có thể sử dụng trình tạo số ngẫu nhiên bảo mật mã hóa để tạo chuỗi các byte, mã hóa hex hoặc Base64 để lấy chuỗi được nhúng vào trang. OWASP đề xuất độ dài 128 bit, trong đó chúng giả định 64 bit entropy (ví dụ: 8 byte ngẫu nhiên được chuyển thành chuỗi hex 16 byte). Độ dài của chuỗi đó xác định mức độ bảo mật: đoán số ngẫu nhiên an toàn 10 byte (có 80 bit entropy) thành công với xác suất 2^(- 80), đủ cho hầu hết các ứng dụng. Vì vậy, mã thông báo cuối cùng của bạn phải có độ dài 20 byte, một số ngẫu nhiên 10 byte được chuyển thành mã hóa hex.