Я полагаю, что будет трудно найти окончательный ответ на этот вопрос о том, почему токен 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, как платформы, на которую должны опираться другие разработчики, состоит в том, чтобы защитить все запросы на изменение состояния. Причина в том, что они понятия не имеют, что могут непреднамеренно раскрыть разработчики или сторонние расширения. Безопаснее защищать все запросы на изменение состояния, чем показывать что-либо сторонним модулем и быть плохим пиаром для платформы. На самом деле я не знаю, все ли запросы на изменение состояния защищены от CSRF-атак.
Следует отметить, что Magento не всегда использует ключ формы для защиты запросов на изменение состояния. Например, запросы Delete From Cart ( /checkout/cart/delete/id/{ID}) и Delete Customer Address ( /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 использует заполнители для поиска / замены ключей формы на кэшированных страницах. Реализации Varnish также будут использовать ESI везде, где используется ключ формы.
Мне было бы любопытно узнать, заканчивают ли некоторые наиболее популярные расширения «ajax cart» проверкой токена CSRF во время запросов на добавление в корзину.
Единственный запрос на добавление функции «Добавить в корзину», где я в конечном итоге отказываюсь от токена CSRF, позволяет создавать ссылки для добавления в корзину для использования в электронных письмах или других веб-сайтах (социальных сетях). Иногда маркетинг хочет, чтобы пользователи непосредственно добавили товар в корзину и сразу же перенаправили его в корзину или оформить заказ. Это не может быть легко сделано, если требуется токен CSRF. Я бы порекомендовал это, только если вы довольны уровнем риска и доверяете своему и любому стороннему коду.