Я вважаю, що буде важко отримати остаточну відповідь на це питання, чому маркер CSRF "потрібен" в додатку Magento до кошика GET. Я спробую інтерпретувати його призначення. Я аж ніяк не експерт із безпеки, і це моя інтерпретація CSRF у цьому конкретному контексті.
Контекст
З Owasp.org
Підробка міжміських запитів (CSRF) - це атака, яка змушує кінцевого користувача виконувати небажані дії над веб-додатком, в якому вони в даний час мають автентифікацію. Атаки CSRF конкретно націлені на запити на зміну стану, а не на крадіжку даних, оскільки зловмисник не може побачити відповідь на підроблений запит.
Одним із прикладів цієї атаки є вбудовування прихованого зображення в електронний лист або альтернативну веб-сторінку:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
Веб-сервер не розрізнятиме, звідки надходив запит, і сумлінно додавав би товар у кошик цього користувача.
Мета запобігання атакам CSRF - запобігання запитам, що змінюються державою . Додавання товару до кошика вважатиметься зміною стану. Загалом, я вважаю, що це нешкідлива зміна стану в порівнянні з поданням замовлення, перерахуванням коштів або оновленням електронної адреси.
Щодо змін стану та методів HTTP, RFC 2616 говорить наступне:
Зокрема, було встановлено, що методи GET і HEAD НЕ повинні мати значення для вжиття інших дій, ніж пошук. Ці методи слід вважати "безпечними".
Magento та CSRF
Magento реалізує механізм запобігання CSRF як для адміністратора, так і для областей, використовуючи маркер (ключ форми). Я б припустив, що мета Magento, як платформи, яка повинна будуватися іншими розробниками, - забезпечити всі запити, що змінюються державою. Причина полягає в тому, що вони не мають уявлення про те, що розробники-розробники або розширення сторонніх розробників можуть ненавмисно викрити. Безпечніше захищати всі запити, що змінюються державою, ніж піддавати щось сторонній модуль та бути поганим PR для платформи. Я насправді не знаю, чи захищені всі запити щодо зміни держави від атак CSRF.
Варто зазначити, що Magento не завжди використовує ключ форми для захисту запитів, що змінюються станом. Наприклад, запити Видалити з кошика ( /checkout/cart/delete/id/{ID}) та Видалити адресу клієнта ( /customer/address/delete/id/{ID}) - це запити GET, що передаються в ідентифікатор особи. Потім контролер (або моделі) обробляють, гарантуючи, що користувач має право видаляти ці записи сутностей (змінити стан). Це два випадки, коли Magento не дотримується RFC 2616 . Якщо бути справедливим, для деяких випадків використання це може бути не практичним або необхідним.
Схоже, перевірка ключа форми у Mage_Checkout_CartController::addActionметоді була додана у версії 1.8. З нотаток до випуску у нас є наступне:
Вирішені проблеми, які могли призвести до підробки між веб-сайтами (CSRF) у веб-магазині.
На жаль, мова нечітка, і "міг би" приводити мене до думки, що це було завдяки припущенню, яке я висловив раніше: безпечні запити на зміну стану. Можливо, існує можливість надсилання додаткових параметрів, які викликають певну ненавмисну поведінку:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
Ідея полягає в тому, що додаючи щось у кошик, є деякий біт коду (основний або третій), який, можливо, спрацьовує під час додавання в кошик, наприклад, через якусь розіслану подію.
Навряд чи така вразливість існує поза межами ящика, і якщо це станеться, можна сподіватися, що Magento зробить кращу роботу з розкриття деталей / ризиків. Один із ризиків, який я міг бачити, - це те, що Magento сліпо зберігає параметри запиту під час додавання до кошика в product_optionsстовпці таблиці товарів із замовленнями (див. info_buyRequest:). Теоретично хтось може підманути групу користувачів до додавання елементів у свою кошик із дивними параметрами запиту, які зберігатимуться в sales_flat_quote_item_optionтаблиці та зрештою sales_flat_order_itemтаблиці, якщо вони також зможуть змусити цих користувачів конвертувати. Мені це здається вкрай малоймовірним.
Додати до кошика Основні проблеми
Однією з найважливіших проблем, з якою люди стикаються з реалізацією FPC та маркерами CSRF, є те, що вони отримують кеш-пам'ять. Перший клієнт, який нагріває кеш, генерує маркер, коли другий клієнт отримує кеш-пам'ять HIT, їм тепер була надана сторінка з першим маркером користувачів. При надсиланні форми жетони не збігаються.
Magento Enterprise використовує заповнювачі для пошуку / заміни форм клавіш на кешованих сторінках. Реалізація лаку буде використовувати ESI там, де використовується ключ форми.
Мені було б цікаво дізнатись, чи закінчуються деякі більш популярні розширення "ajax cart", перевіряючи маркер CSRF під час їх додавання до запитів кошика.
Один запит на функцію, коли я закінчую вище маркер CSRF для дії "додати до кошика", дозволяє можливість створювати посилання на додавання до кошика для використання в електронних листах або інших веб-сайтах (соціальних мережах). Іноді маркетинг хоче, щоб користувачі безпосередньо додавали товар у кошик і негайно переадресовували в кошик або касу. Це неможливо зробити легко, якщо потрібен маркер CSRF. Я рекомендую це, лише якщо вам подобається рівень ризику та довіряєте власному та будь-якому сторонній код.