要するに、はい。CE 1.7は、パッチを含むセキュリティリリースが発行されていないため、これらの特定の攻撃に対して依然として脆弱です。
後者のセッション固定攻撃の場合、この変更は、Magentoが現在のセキュリティのベストプラクティスに準拠するために使用していたセキュリティプラクティスのアップグレードです。CSRF修正を含むパッチを発行する場合、CE 1.7に発行される可能性のあるものはありません。
本当の問題は、修正されたこれらのCSRFの脆弱性は正確に何でしたか？リリースノートに詳細が含まれていないため、以前のすべてのリリースがさらに危険にさらされていることは間違いありませんが、古い実装にパッチを適用するために知っておくとよいでしょう。
更新＃1：
Magentoに連絡して、上記の脆弱性に対するパッチをいつ発行するかを確認すると、次の返信が届きました。
これについてさらに調査する時間があります。これらの2つのアイテムに利用可能なパッチがあるかどうかはわかりません。それらはシステムのバグとしてではなく、製品の拡張としてリストされているからです。詳細がわかり次第、更新します。
詳細を入手したらここに投稿しますが、現在パッチが存在しないようであるため、パッチを発行するために最善を尽くします。
更新＃2：サポートチームとやり取りした後、Magento EE 1.12.0.2の適切なパッチを入手できました。Magento CE 1.7.0.2のパッチは発行されていません。内部で調べた技術者が知る限り、CE 1.7.xの公式パッチをリリースする予定はありませんが、代わりに今後のCE 1.8でのみ問題を解決します。安定したリリース。
EE固有のパッチファイルに関しては、Magentoと私自身および私が勤務している会社との間でNDAに違反していることは間違いないので、ここ（またはパッチ適用ツール）に直接投稿することはできません。関連するパッチの名前は次のとおりです。「PATCH_SUPEE-1513_EE_1.12.0.2_v1.sh」— Enterprise Editionまたはそれを使用しているクライアントがある場合は、Magentoサポートチームにこのパッチをリクエストすることができます。修正することになっているCSRFの脆弱性。
CE 1.7.0.2ユーザーの場合、Magento CE 1.7.0.2コアコードファイルを変更する大量のコードのみを含むパッチファイル（Magentoが提供するパッチに基づく）を自由に生成しました。通常の方法では、関連するコードの変更に加えて、追加されたコメントと調整されたフォーマットの無関係な部分が含まれます。これを作成するには、提供されたパッチ適用ツールを使用して元のパッチを手動で変更して適用し、次にgitを使用して適用された変更に基づいてパッチを生成する必要がありました。
私が作成したパッチファイルは、この要点からダウンロードできます：https : //gist.github.com/davidalger/5938568
パッチを適用するには、まずMagentoインストールのルートにcdし、次のコマンドを実行します： patch -p1 -i ./Magento_CE_1.7.0.2_v1-CSRF_Patch.diff
EE固有のパッチには、エンタープライズ固有のコントローラーに対するフォームキー検証チェック、修正済みのコントローラーアクションに使用されるフォームにフォームキーを含めるためのエンタープライズ/デフォルトおよびエンタープライズ/ iPhoneテンプレートファイルの変更、追加のフルページキャッシュ機能が含まれます。キャッシュされたページでフォームキーをやり取りします。
免責事項： Magentoが提供するEEパッチも、リンクした要点にアップロードしたパッチもテストしていません。参照した要点で提供されているパッチは無保証で提供されており、CE 1.8リリースノートで参照されている脆弱性を完全に解決する場合としない場合があります。テストされていないパッチとして、全体または一部で機能するという保証もありません。つまり、自己の責任において使用し、本番環境に展開する前にテストにデューデリジェンスを取ります。パッチに問題が見つかった場合はお知らせください。更新します。