回答:
Magentoのカートに追加するGETアクションでCSRFトークンが「必要」な理由に関するこの質問に対する明確な回答を得るのは難しいと思います。その目的の解釈を試みます。私は決してセキュリティの専門家ではありません。これは、この特定の状況におけるCSRFの解釈です。
クロスサイトリクエストフォージェリ（CSRF）は、エンドユーザーに、現在認証されているWebアプリケーションで不要なアクションを実行させる攻撃です。CSRF攻撃は、攻撃者が偽造された要求に対する応答を確認する方法がないため、データの盗難ではなく、状態が変化する要求を特に対象としています。
この攻撃の一例は、電子メールまたは別のWebページに隠された画像を埋め込むことです。
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">Webサーバーは、リクエストの送信元を区別せず、アイテムをユーザーのカートに忠実に追加します。
CSRF攻撃を防ぐ目的は、状態が変化する要求を防ぐことです。カートにアイテムを追加すると、状態の変化と見なされます。一般に、これは注文の送信、送金、または電子メールアドレスの更新と比較して、無害な状態の変化であると考えます。
状態の変更とHTTPメソッドに関して、RFC 2616は次のように述べています。
特に、GETメソッドとHEADメソッドには、取得以外のアクションを実行する重要性がないという慣習が確立されています。これらの方法は「安全」と見なされるべきです。
Magentoは、トークン（フォームキー）を使用して、管理領域とフロントエンド領域の両方にCSRF防止メカニズムを実装しています。他の開発者が構築することを意図したプラットフォームとしてのMagentoの目標は、すべての状態変化リクエストを保護することだと思います。その理由は、実装している開発者またはサードパーティの拡張機能が意図せずに公開する可能性があることを知らないからです。サードパーティのモジュールによって何かが公開されてプラットフォームのPRが悪くなるよりも、すべての状態変更リクエストを保護する方が安全です。すべての状態変更要求がCSRF攻撃から保護されているかどうかは実際にはわかりません。
注意すべきことの1つは、Magentoが状態変更要求を保護するために常にフォームキーを使用するとは限らないことです。たとえば、カートから削除（/checkout/cart/delete/id/{ID}）および顧客の住所を削除（/customer/address/delete/id/{ID}）リクエストは、どちらもエンティティIDを渡すGETリクエストです。次に、コントローラー（またはモデル）は、ユーザーがそれらのエンティティレコードを削除する（状態を変更する）ことを許可されていることを確認する処理を行います。これらは、MagentoがRFC 2616に従っていない2つのインスタンスです。公平を期すために、一部のユースケースでは、そうすることが実用的または必要ではない場合があります。
Mage_Checkout_CartController::addActionメソッドのフォームキーチェックはバージョン1.8で追加されたようです。リリースノートから、次のことを行っています。
Webストアでクロスサイトリクエストフォージェリ（CSRF）が発生する可能性があった問題を解決しました。
あいにく、この言語はあいまいであり、「持つことができた」ということは、先ほど述べた安全な状態変更要求という仮定によるものだと信じさせてくれます。何らかの意図しない動作を引き起こす追加のパラメーターを送信する可能性があります。/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
アイデアは、カートに何かを追加することにより、カートへの追加中に、たとえばディスパッチされたイベントを介してトリガーされるコード（コアまたはサードパーティ）が少しあるということです。
そのような脆弱性がすぐに存在する可能性は低いようで、もしそうなれば、Magentoが詳細/リスクを開示するより良い仕事をすることを望むでしょう。私が見る可能性のあるリスクの1つは、Magentoがカートへの追加中に、product_options注文項目テーブルの列にリクエストパラメータを盲目的に保存することです（参照：）info_buyRequest。理論的に誰かが奇妙なクエリパラメータで自分のカートにアイテムを追加するにユーザーのグループをだますことができ、それはに格納なるだろうsales_flat_quote_item_optionテーブル、最終的にsales_flat_order_item彼らがしている場合、テーブルも変換するために、それらのユーザーを取得することができ。ほとんどの場合、これは私には非常にありそうもない。
FPC実装とCSRFトークンで遭遇する大きな問題の1つは、最終的にキャッシュされることです。キャッシュをウォームアップする最初のクライアントはトークンを生成します。2番目のクライアントがキャッシュHITを取得すると、最初のユーザートークンのページが与えられます。フォームを送信すると、トークンは一致しません。
Magento Enterpriseは、プレースホルダーを使用して、キャッシュされたページのフォームキーを検索/置換します。ニスの実装では、likleyはESIを使用してフォームキーを使用します。
人気のある「ajax cart」拡張機能が、カートへの追加要求時にCSRFトークンをチェックすることになるかどうかを知りたいと思います。
カートに追加アクションのCSRFトークンの前にある機能要求の1つは、電子メールまたは他のWebサイト（ソーシャルメディア）で使用するカートに追加リンクを作成できるようにすることです。マーケティングでは、ユーザーがアイテムをカートに直接追加して、すぐにカートまたはチェックアウトにリダイレクトするようにしたい場合があります。CSRFトークンが必要な場合、これは簡単に行えません。リスクのレベルに自信があり、自分のコードやサードパーティのコードを信頼している場合にのみ、これをお勧めします。
Web開発の原則では、あらゆる形式のクロスサイトリクエストフォージェリ（CSRF）またはクロスサイトスクリプティング（XSS）は望ましくないため、常に回避する必要があるとされています。
どういう意味ですか？CSRFの場合、ステートフルデータ自体を変更するURLは使用できません。そうでない場合、攻撃者は、クリックしてURLにアクセスするだけで（リダイレクトなど）、人のカートの内容を操作したり、ウィッシュリストや比較からアイテムを追加/削除したりできます。
フォームキーは、それを回避する方法です。Magentoは、セッション固有のハッシュを生成し、すべてのデータ変更リクエストとともに送信する必要があります。
カートアイテムの追加/削除は深刻な攻撃ベクトルですか？ほとんどのサイトではそうではないでしょう。しかし、それでもCSRFであり、CSRFは悪いです。そのため、form_key現在値があります（CE 1.8時点）。