Tôi tin rằng sẽ rất khó để có được câu trả lời dứt khoát cho câu hỏi này về lý do tại sao mã thông báo CSRF là "cần thiết" trong hành động thêm vào giỏ hàng của Magento. Tôi sẽ cố gắng diễn giải mục đích của nó. Tôi không có nghĩa là một chuyên gia bảo mật và đây là cách giải thích của tôi về CSRF trong bối cảnh cụ thể này.
Bối cảnh
Từ owasp.org
Giả mạo yêu cầu đa trang web (CSRF) là một cuộc tấn công buộc người dùng cuối phải thực hiện các hành động không mong muốn trên một ứng dụng web mà hiện tại họ đang xác thực. Các cuộc tấn công CSRF đặc biệt nhắm mục tiêu các yêu cầu thay đổi trạng thái, không đánh cắp dữ liệu, vì kẻ tấn công không có cách nào để xem phản hồi đối với yêu cầu giả mạo.
Một ví dụ về cuộc tấn công này là nhúng hình ảnh ẩn trong email hoặc trang web thay thế:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
Máy chủ web sẽ không phân biệt yêu cầu đến từ đâu và trung thành sẽ thêm mục vào giỏ hàng của người dùng đó.
Mục tiêu của việc ngăn chặn các cuộc tấn công CSRF là ngăn chặn các yêu cầu thay đổi trạng thái . Thêm một mục vào giỏ hàng sẽ được coi là thay đổi trạng thái. Nói chung, tôi sẽ coi đây là một thay đổi trạng thái vô hại so với việc gửi đơn đặt hàng, chuyển tiền hoặc cập nhật địa chỉ email.
Về thay đổi trạng thái và phương thức HTTP, RFC 2616 cho biết như sau:
Cụ thể, quy ước đã được thiết lập rằng các phương thức GET và HEAD KHÔNG NÊN có ý nghĩa của việc thực hiện một hành động nào khác ngoài truy xuất. Những phương pháp này nên được coi là "an toàn".
Magento và CSRF
Magento thực hiện cơ chế ngăn chặn CSRF cho cả khu vực quản trị và giao diện bằng cách sử dụng mã thông báo (khóa biểu mẫu). Tôi cho rằng mục tiêu của Magento, như một nền tảng được xây dựng bởi các nhà phát triển khác, là để bảo đảm tất cả các yêu cầu thay đổi trạng thái. Lý do là họ không biết những gì các nhà phát triển triển khai hoặc tiện ích mở rộng của bên thứ 3 có thể vô tình phơi bày. An toàn hơn để bảo mật tất cả các yêu cầu thay đổi trạng thái so với việc có mô-đun của bên thứ 3 tiếp xúc và làm PR xấu cho nền tảng. Tôi thực sự không biết liệu tất cả các yêu cầu thay đổi trạng thái có được bảo mật khỏi các cuộc tấn công CSRF hay không.
Một điều cần lưu ý là Magento không phải lúc nào cũng sử dụng khóa biểu mẫu để bảo vệ các yêu cầu thay đổi trạng thái. Chẳng hạn, các yêu cầu Xóa khỏi giỏ hàng ( /checkout/cart/delete/id/{ID}) và Xóa địa chỉ khách hàng ( /customer/address/delete/id/{ID}) đều là các yêu cầu GET chuyển qua ID thực thể. Bộ điều khiển (hoặc mô hình) sau đó xử lý đảm bảo rằng người dùng được ủy quyền để xóa các bản ghi thực thể đó (sửa đổi trạng thái). Đây là hai trường hợp Magento không tuân theo RFC 2616 . Để công bằng, đối với một số trường hợp sử dụng, nó có thể không thực tế hoặc cần thiết để làm như vậy.
Dường như kiểm tra khóa biểu mẫu trong Mage_Checkout_CartController::addActionphương thức đã được thêm vào trong phiên bản 1.8. Từ các ghi chú phát hành, chúng tôi có những điều sau đây:
Đã giải quyết các vấn đề có thể dẫn đến Giả mạo yêu cầu chéo trang web (CSRF) trong cửa hàng web.
Thật không may, ngôn ngữ là mơ hồ và "có thể có" khiến tôi tin rằng đó là do giả định tôi đã nêu trước đó: yêu cầu thay đổi trạng thái an toàn. Có thể có khả năng gửi các tham số bổ sung gây ra một số loại hành vi ngoài ý muốn:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
Ý tưởng là bằng cách thêm một cái gì đó vào giỏ hàng, có một chút mã (lõi hoặc bên thứ 3) sẽ được kích hoạt trong quá trình thêm vào giỏ hàng, ví dụ như thông qua một số sự kiện được gửi đi.
Dường như không có lỗ hổng như vậy tồn tại ngoài hộp và nếu có thì người ta sẽ hy vọng Magento sẽ làm tốt hơn trong việc tiết lộ các chi tiết / rủi ro. Một rủi ro tôi có thể thấy là Magento lưu trữ một cách mù quáng các tham số yêu cầu trong quá trình thêm vào giỏ hàng trong product_optionscột của bảng mục đơn hàng bán hàng (xem info_buyRequest:). Về lý thuyết, ai đó có thể lừa một nhóm người dùng thêm các mục vào giỏ hàng của họ bằng các tham số truy vấn lạ và điều đó sẽ được lưu vào sales_flat_quote_item_optionbảng và cuối cùng là sales_flat_order_itembảng nếu họ cũng có thể khiến những người dùng đó chuyển đổi. Điều này dường như rất khó xảy ra với tôi trong hầu hết các trường hợp.
Thêm vào giỏ hàng Các vấn đề chính
Một trong những vấn đề lớn mà mọi người gặp phải khi triển khai FPC và mã thông báo CSRF là cuối cùng họ bị lưu trữ. Máy khách đầu tiên làm ấm bộ đệm tạo mã thông báo, khi máy khách thứ hai nhận được bộ đệm HIT, giờ đây chúng đã được cung cấp một trang có mã thông báo người dùng đầu tiên. Khi gửi biểu mẫu, mã thông báo sẽ không khớp.
Magento Enterprise sử dụng trình giữ chỗ để tìm / thay thế các khóa biểu mẫu trong các trang được lưu trong bộ nhớ cache. Việc triển khai Varnish sẽ thích sử dụng ESI cho bất cứ nơi nào sử dụng khóa biểu mẫu.
Tôi sẽ tò mò muốn biết liệu một số tiện ích mở rộng "ajax cart" phổ biến hơn có kết thúc việc kiểm tra mã thông báo CSRF trong quá trình thêm vào yêu cầu giỏ hàng của chúng hay không.
Yêu cầu một tính năng mà cuối cùng tôi đã đưa ra mã thông báo CSRF cho hành động thêm vào giỏ hàng là cho phép khả năng tạo liên kết thêm vào giỏ hàng để sử dụng trong email hoặc các trang web khác (phương tiện truyền thông xã hội). Đôi khi tiếp thị muốn có người dùng trực tiếp thêm một mặt hàng vào giỏ hàng và chuyển hướng đến giỏ hàng hoặc thanh toán ngay lập tức. Điều này không thể dễ dàng được thực hiện nếu cần có mã thông báo CSRF. Tôi chỉ đề xuất điều này nếu bạn cảm thấy thoải mái với mức độ rủi ro và tin tưởng vào mã của bên thứ 3 và của chính bạn.