2013-04-17 40 views
14

Tôi đã đọc về cách sử dụng mẫu mã thông báo đồng bộ hóa để ngăn chặn CSRF (CSRF có nghĩa là giả mạo yêu cầu Cross-site.) Và tôi không hiểu nó thực sự an toàn như thế nào.Cách sử dụng Mẫu mã đồng bộ hóa để ngăn CSRF an toàn như thế nào?

Hãy nói rằng tôi có một trang web giả mạo ngân hàng fakebank.com với hai url:

  • fakebank.com/withdrawForm.html - một yêu cầu GET mà hiển thị dưới dạng tiền
  • fakebank.com/doWithdraw rút - POST để url này để thực hiện rút

Sự hiểu biết của tôi về lỗ hổng bảo mật là maliciousSite.com có thể giả mạo yêu cầu POST tới fakebank.com/doWithdraw và nếu bạn hiện đang đăng nhập vào fakebank, POST sẽ thành công.

Giả sử chúng tôi triển khai Mẫu mã thông báo đồng bộ hóa sẽ nhúng mã bí mật vào fakebank.com/withdrawForm.html. Không thể maliciousSite.com chỉ giả mạo yêu cầu GET cho biểu mẫu đó, phân tích cú pháp kết quả html, nhận mã thông báo và sau đó tạo yêu cầu POST bằng mã thông báo đó?

Giả sử fakebank.com không kiểm tra HTTP Referrer hoặc Origin hoặc maliciousSite.com là giả mạo thành công rằng liên kết giới thiệu/nguồn gốc là fakebank.com.

Trả lời

18

Lý do tại sao điều này là an toàn, và maliciousSite.com không thể chỉ đơn giản là làm một GET, ăn cắp được dấu hiệu, và sau đó làm một POST là yêu cầu được thực hiện bởi trình duyệt của người dùng, không phải do máy chủ tại maliciousSite.com. Tất cả dữ liệu được trả lại từ fakebank.com được trả về cho trình duyệt của người dùng, không cho máy chủ tại maliciousSite.com. Nếu maliciousSite.com thực hiện lệnh GET để truy xuất mã thông báo, mã sẽ là một mã thông báo khác với mã thông báo được cấp cho người dùng. maliciousSite.com không thể đặt cookie này vào trình duyệt của người dùng để được gửi đến fakebank.com do các giới hạn cùng tên miền.

Cuộc tấn công CSRF POST hoạt động bằng cách lừa trình duyệt của người dùng yêu cầu fakebank.com/withdrawForm.html trực tiếp bằng yêu cầu POST được thiết lập đúng cách. Máy chủ tại fakebank.com vui lòng thực hiện yêu cầu POST, do đó chuyển tiền bằng cách sử dụng các thông số được cung cấp trong cơ thể POST (bao gồm tài khoản đích thuộc về kẻ tấn công được đặt ở đó maliciousSite.com). Máy chủ tại maliciousSite.com không cần xem dữ liệu được trả về vì hành động đã được thực hiện (trừ khi fakebank.com sử dụng các mã thông báo CSRF này, mà maliciousSite.com không thể biết trừ khi nó bị tiết lộ theo một cách nào đó. cho nó). Nếu fakebank.com đang sử dụng mã thông báo CSRF, thì maliciousSite.com sẽ gửi yêu cầu POST thiếu mã thông báo, do đó cho biết đang xảy ra tấn công CSRF tiềm ẩn.

Lỗ hổng của phương pháp này bao gồm sử dụng mã thông báo CSRF không được giữ bí mật đầy đủ và được tiết lộ theo một cách nào đó. Ngoài ra, nếu mã thông báo CSRF không đủ ngẫu nhiên, thì maliciousSite.com có thể đoán được. Ngoài ra, nếu có sự yếu kém trong việc thực thi chính sách miền giống nhau của trình duyệt, điều này có thể bị khai thác. Nói chung, các trình duyệt hiện đại không dễ bị tổn thương đến điều này.

Vui lòng cho tôi biết nếu đây là giải thích không đầy đủ và tôi sẽ cố gắng nêu rõ hơn một chút cho bạn.

+2

Nếu bạn có thể đưa javascript vào trình duyệt của người dùng để bắt đầu cuộc tấn công, bạn sẽ chỉ cần nhúng một số jquery để thực hiện yêu cầu GET, phân tích cú pháp, sau đó thực hiện POST trong cùng một '

2

Và đó chính xác là vấn đề. Same Origin Policy trong trình duyệt không cho phép NHẬN yêu cầu đến các trang web khác. Vì vậy, không có trang nào có thể lấy mã thông báo CSRF từ mã khác chỉ bằng cách sử dụng Javascipt trong trình duyệt.