セキュリティパッチSUPEE-9767-考えられる問題?


108

16のAPPSECの問題に対処する新しいセキュリティパッチがMagento 1用に公開されています:https ://magento.com/security/patches/supee-9767

CVSSv3 Severityの脆弱性のうち7つは8.0以上であり、実際に悪用されているため、これは重要なパッチです。サイトはSUPEE-9767を適用するか、新しいリリースCE 1.9.3.3 / EE 1.14.3.3に更新できます。

SUPEE-9767を適用する際に注意すべき一般的な問題や落とし穴は何ですか?


更新2017-07-12:

MagentoはSUPEE-9767 V2およびCE 1.9.3.4をリリースして、初期パッチの問題の多くに対処しました。V1を適用した場合、元に戻してからV2を適用する必要があります。まだパッチを適用していない場合は、V2を適用するだけで、ここで取り上げた問題のほとんどは関係ありません。


「CVSSv3重大度の7つ以上の脆弱性スコアは8.0以上であり、実際に悪用されているため、これは重要なパッチです。」確認したいのですが、「攻撃者」はこれらのエクスプロイトを行うために管理者になる必要がありますか?
PaddyD

3
はい、悪用するには管理者アクセス権が必要です...
MagenX

パッチは一般的なブルートフォースエンドポイント(つまり、/ rss / order / new)を停止しないようです。
リッキーオーディンマシューズ

1
.htaccessのRSS @RickyOdinMatthewsでこれを使用しています RewriteRule ^/?(index.phprss|index.php/rss/catalog|index.php/rss/order|rss/catalog|rss/order).*$ /no-route [R=301,L,NC]
リチャードフェラーロ

@RichardFeraro nginxを使用していますが、すでに同様のソリューションを使用しています。ボットは通常これらのエンドポイントをスキャンし、ブルートフォースに気づいています。
リッキーオーディンマシューズ

回答:


107

パッチを掘り下げた後のパッチの概要は次のとおりです

タイムセーバー:Experiusには、カスタムテーマ、カスタムモジュール、または手動パッチを適用する必要があるローカル上書きのファイルを見つけるのに役立つパッチヘルパーがあります。https//github.com/experius/Magento- 1-Experius-Patch-Helper#magento

チェックアウトフォームキー

別の投稿で述べたように、このパッチは次のフォームにフォームキーを追加します。

配送カートフォーム:

app/design/frontend/<package>/<theme>/template/checkout/cart/shipping.phtml

マルチシッピング請求チェックアウトフォーム:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/billing.phtml

複数配送の配送チェックアウトフォーム:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/shipping.phtml

複数配送先住所のチェックアウトフォーム:

app/design/frontend/<package>/<theme>/template/checkout/multishipping/addresses.phtml

課金チェックアウトフォーム:

app/design/frontend/<package>/<theme>/template/checkout/onepage/billing.phtml

配送チェックアウトフォーム:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping.phtml

支払精算フォーム:

app/design/frontend/<package>/<theme>/template/checkout/onepage/payment.phtml

配送方法のチェックアウトフォーム:

app/design/frontend/<package>/<theme>/template/checkout/onepage/shipping_method.phtml

永続請求チェックアウトフォーム:

app/design/frontend/<package>/<theme>/template/persistent/checkout/onepage/billing.phtml

さらに、次のJSファイルが更新され、その変更と互換性があります。

  • js/varien/payment.js
  • skin/frontend/base/default/js/opcheckout.js

何をすべきか:

これらのテンプレートのカスタムバージョンを使用している場合は、次のコードをテンプレートに追加して更新する必要があります。

<?php echo $this->getBlockHtml('formkey') ?>

サードパーティのチェックアウトモジュールを使用している場合は、モジュールの更新バージョンを提供できるように、サードパーティのチェックアウトモジュールに連絡する必要があります。

また、以前にリストされたJSファイルのカスタムバージョンがある場合は、それらも更新する必要があります。

時間を節約

Fabian Schmenglerは、これらすべてを更新するための素敵な小さなスクリプトを作成しました。ここで見つけることができます。

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

重要な注意:チェックアウトフォームキーの検証はシステム>設定>管理者>セキュリティ>チェックアウト時のフォームキー検証を有効にするの下にある新しい設定フィールドを介してバックエンドで変更できます。これはデフォルトでは有効になっていないため、このセキュリティ機能を利用するには有効にする必要があります!!! 有効になっていない場合は、バックエンドで通知を受け取ることに注意してください。

画像アップロードコールバック

検証コールバックを追加するために、イメージギャラリーコントローラーが更新されました。

何をすべきか

次のようなコードで画像をアップロードするカスタムモジュールを使用している場合:

        $uploader = new Mage_Core_Model_File_Uploader('image');
        $uploader->setAllowedExtensions(array('jpg','jpeg','gif','png'));
        $uploader->addValidateCallback('catalog_product_image',
            Mage::helper('catalog/image'), 'validateUploadFile');
        $uploader->setAllowRenameFiles(true);
        $uploader->setFilesDispersion(true);

次の部分を追加して、そのコードを更新することを強くお勧めします。

        $uploader->addValidateCallback(
            Mage_Core_Model_File_Validator_Image::NAME,
            Mage::getModel('core/file_validator_image'),
            'validate'
        );

シンボリックリンク

このパッチは、バックエンドでテンプレートのシンボリックリンクを許可するシステム設定フィールドを削除します。以前は、[システム]> [構成]> [開発者]> [テンプレート]> [シンボリックリンクを許可]にありました。。これで、テンプレートセクション全体が削除されました。

その上、そのフィールドはデフォルトで無効になりました app/etc/config.xml

ここで面白いのは、パッチの前にその設定フィールドを有効にしているが、フィールドがなくなったため無効にできない場合、バックエンドで通知を受け取ることです。

それを行う唯一の方法は、次のSQLクエリを実行することです

UPDATE core_config_data SET value = 0 WHERE path = "dev/template/allow_symlink";

明確化

最初に、Symlinkの変更の目的を理解するのに役立つ2つの投稿を確認することを強くお勧めします。

この変更は、実際にはテンプレートディレクティブを介してアップロード可能なコンテンツ(画像など)を呼び出すことです。

シンボリックリンクに関連する問題は、管理者アクセスでのみ悪用可能であり、Magentoは画像のアップロードにもいくつかの保護を追加しました。

これらは、設定自体に加えて、悪用される既知の方法に対する保護であることに注意してください。

何をすることは:私のように、テンプレートのシンボリックリンクとmodmanや作曲を使用している場合、あなたはいくつかの問題つもり顔です。SQLクエリの処理とは別に、ここで行うのに最適なことを見つけようとしています。

この問題に関する主な投稿:SUPEE-9767、modmanおよびsymlinks

考えられる問題のリスト

V2は、元の投稿以降にリリースされました。アップグレードすることを忘れないでください

バグ

「確認済み」という言葉は、確認済みのバグに使用されます。存在しない場合、それはバグである可能性がありますが、まだ確認されていないことを意味します。

ハンク失敗の問題

これらの問題はすべて、元のファイルを変更したことが原因である可能性があることに注意してください。

  • Hunk Failedエラーが発生したファイルをバックアップします
  • Magentoバージョンから元のファイルをダウンロードします
  • 両方のファイルを比較する

ファイルが異なる場合は、元のファイルにパッチを適用してから、次のようなクリーンな方法でカスタム変更を再適用する必要があります。

  • カスタムテーマフォルダー内のカスタムテンプレート
  • local.xml
  • アプリ/コード/ローカルファイル

ファイルが異なっていない場合、これは許可の問題またはパッチの「バグ」です。


1
@Icon nope ダブルチェックするために、私は私の答えの上部にある参照ツールを使用する
ラファエルデジタルPianismで

1
ただ、「その他の問題」のリストに追加する:と思われるmagento.stackexchange.com/questions/167616/...は同様に最新のバージョンで修正されていません
アントンBoritskiy

1
@RaphaelatDigitalPianism:magento.stackexchange.com/q/177560/51361

1
リストに別の追加:デフォルトのテーマのためmultishippingパッチ改magento.stackexchange.com/questions/177681/...
アードMathijssen

1
「透かしは透明のときに黒の背景を取得します」-これが正しいことを確認できます。これは、cmsの透明なpngをアップロードしたときに発生します
pixiemedia

42

問題1:form_keyはチェックアウトワンページで無効です

Magentoはform_key、ほとんどのフォームを追加します。

をお持ちの場合using default onepage and using custom themeform_key各ステップでチェックアウト時に** 問題が発生し始めます**;

フォームキーを追加する必要があります <?php echo $this->getBlockHtml('formkey') ?>

以下のファイルが存在する場合、各チェックアウト手順ファイルの形式に、

  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/billing.phtml
  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/payment.phtml
  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping.phtml

  • app/design/frontend/[Your_Package]/[YOUR_THEME]/template/checkout/onepage/shipping_method.phtml

テンプレートファイルがベーステーマから呼び出している場合、問題は発生しません。パッチはこれらのファイルを自動的に更新するためです。

また、注: <?php echo $this->getBlockHtml('formkey') ?>常にフォームタグ内に配置する必要があります

 <form action="" .....>
     <fieldset>
      .......
       <?php echo $this->getBlockHtml('formkey') ?>
     </fieldset>
 </form>

** Magentoの複数配送チェックアウトを使用している場合は、

以下のファイル:

Issue2:カートページの配送見積もりフォームに対するform_keyの問題:

カートページの見積配送フォームにform_keyを追加します

次に、フォームキーを追加する必要があります <?php echo $this->getBlockHtml('formkey') ?>

app/design/frontend/{Your_Package}/{YOUR_THEME]/template/checkout/cart/shipping.phtml

問題3:Magento onepage checkout opcheckout.jsエラー

デフォルトのワンページチェックアウトを使用していてopcheckout.js 、チェックする必要がある場合

if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {opcheckout.jsで利用可能です

終了しない場合は交換します

if(elements [i] .name == 'payment [method]'){

if(elements [i] .name == 'payment [method]' || elements [i] .name == 'form_key'){

issue1、issue2、issue3の場合、@ FabianSchmenglerのスクリプトadd-checkout-form-key.shを使用して、Issueを簡単に修正できます。それはあなたの受容テーマファイルの問題を修正します

問題4:Mage_Customer_Model_Sessionの書き換え時の顧客ログイン後の無効なフォームキー

もしMage_Customer_Model_Sessionクラスの書き換えやから呼び出されています

app/code/local/Mage/Customer/Model/Session.phpを使用してセッションに顧客を設定すると、setCustomerAsLoggedIn()/またはsessionで設定した顧客の後にform_keyの問題が発生する場合があります。

この場合、追加する必要があります

Mage :: getSingleton( 'core / session')-> renewFormKey();

の 呼び出し前にsetCustomerAsLoggedIn()

Mage::dispatchEvent('customer_login', array('customer'=>$customer));

  public function setCustomerAsLoggedIn($customer)
    {
        $this->setCustomer($customer);
        $this->renewSession();
        // add this  for patch -9767
        Mage::getSingleton('core/session')->renewFormKey();
       // end this for patch 9767
        Mage::dispatchEvent('customer_login', array('customer'=>$customer));
        return $this;
    }

Issue5:ログアウト後のForm_keyの問題

セッションから顧客をログアウトした後、Mage_Customer_Model_Sessionクラスが書き換えられたり、

app/code/local/Mage/Customer/Model/Session.php

この場合の同じニーズの場合:

   protected function _logout()
    {
        $this->setId(null);
        $this->setCustomerGroupId(Mage_Customer_Model_Group::NOT_LOGGED_IN_ID);
        $this->getCookie()->delete($this->getSessionName());
// add this  for patch -9767
Mage::getSingleton('core/session')->renewFormKey();
        return $this;
    }

勧告:

推奨事項1: supee-9767の問題を修正するには、パッチhttps://github.com/experius/Magento-1-Experius-Patch-Helperを使用できます

これは今のところ最良のソリューションです。

注:その前に、ファイルとデータベースのバックアップまたはシステム全体のバックアップを取ることを強くお勧めします。


推奨事項2:ONESTEPチェックアウトでパッチ機能を使用する

セキュリティ目的でパッチsupee-9767がリリースされていることはわかっています。ONESTEPCHECKOUTを使用する場合 は、ワンステップチェックアウトコントローラーのSAVEアクションにform_key検証を追加する必要があります

配送方法の詳細を保存するために、ワンステップチェックアウトでsaveShippingmethod()を使用するとします。次に、これに追加する必要があります

if ($this->isFormkeyValidationOnCheckoutEnabled() && !$this->_validateFormKey()) {
           return;
      }

また、You on onestep <?php echo $this->getBlockHtml('formkey') ?> checkout phtml filesそれぞれのセクションでフォームキーを追加する 必要があります

関連リンク

https://peterocallaghan.co.uk/2017/06/appsec-1281-dangerous-symlinks/


1
チェックアウトでフォームキーのカスタムテンプレートファイルを見つけるための素晴らしくて速いワンライナー。アプリ/デザイン/フロントエンドを見つける| grep -E "checkout / onepage /(billing | payment | shipping | shipping_method).phtml" | grep -v "base / default" | grep -v "rwd / default"
ピーターヤープブラクメール

6
または、わずかに長い1つのライナーですぐに更新します:gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b
Fabian Schmengler

@FabianSchmenglerの魔法です!!! :)
アミットベラ

@FabianSchmenglerすごい、うまくいきました!
ピーターヤープブラクメール

1
@AmitBera FYI:一部のチェックアウトプラグインは、AJAXを使用して請求/配送/などを送信します。パッチを適用する必要がありました。簡単な方法は、<script> var formKey = "<?php echo Mage :: getSingleton( 'core / session')-> getFormKey();?>"; </ script>をテーマの先頭に入れます。次に、AJAX送信のパラメーターとしてform_key:formKeyを追加できます。もちろん、新しいパラメーターの送信を確認するためにフォームをテストし、投稿で述べたようにコントローラーを編集して処理します。
カルビンクリエン

26

パッチファイルのレビューでの最初のパスに基づいて...

  • 新しい設定 admin/security/validate_formkey_checkoutが追加されました。オンにすると、チェックアウトフォームでフォームキーの存在がチェックされます。テンプレートファイルがテーマでオーバーライドされている場合は、そこで更新する必要があります。この設定はデフォルトでオフになっているようです
  • シンボリックリンクはデフォルトでは禁止されているようです( app/etc/config.xml)。また、それらを許可する機能は、管理構成から削除されたようです。ただし、サイトで以前に明示的にシンボリックリンクを有効にした場合、設定はデータベースに保存され、この変更が上書きされます。
  • このパッチを適用するときは、キャッシュとページ全体のキャッシュの両方をクリアする必要があります。設計の例外は、デコードと互換性のない形式で保存されます。ページキャッシュをフラッシュしないと、「デコードに失敗しました:構文エラー」のようなエラーが表示されます。

1
また、単にバイナリエディタで行くと、データベースにそれを自分で追加し、それはほとんどの人々のために少しくらいかもしれでき

1
cloudflareなど、CDNを使用しているユーザーがいる場合は、必ずキャッシュを消去してください。CDNがアクティブな状態でチェックアウトを試みましたが、[支払い]ページを通過できませんでした。キャッシュをパージして開発モードを有効にした瞬間、すべてがうまくいきました。
アイコン

14

base/defaultこのパッチの影響を受けるファイルの下に、このファイルがテーマにあった場合は、それに応じて変更を行ってください

app/design/frontend/base/default/template/checkout/cart/shipping.phtml

app/design/frontend/base/default/template/checkout/multishipping/billing.phtml

app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/billing.phtml

app/design/frontend/base/default/template/checkout/onepage/payment.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml

app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml

app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml

上記のすべてのphtmlファイルに以下のフォームのキー行が追加されるので、この行をそれぞれのphtmlファイルに追加してください。

 <?php echo $this->getBlockHtml('formkey') ?>

上記の問題について、@ fabianは、テーマファイルにもフォームキーを追加するスクリプトを作成しました

https://gist.github.com/schmengler/c42acc607901a887ef86b4daa7a0445b

セキュリティパッチを適用した後、フォームキーのエラーが発生した場合、このパッチを適用できます。このパッチプロセスの適用はセキュリティパッチと同じです

  sh filename.sh

ファイルの1つのbase/default変更Js

  skin/frontend/base/default/js/opcheckout.js

このjsファイルがテーマからロードされている場合、以下の手順を実行します

ブローラインを取り外す

 if (elements[i].name=='payment[method]') {

上ではなく下の行を追加します

 if (elements[i].name=='payment[method]' || elements[i].name == 'form_key') {

編集

また、以下のファイルをオーバーライドするチェックアウト拡張機能を使用している場合は、チェックアウト拡張機能のphtmlファイルにフォームキー行を追加します。

EDIT2-問題

1)saveBillingAction()でエラーが発生するか、フォームキーを取得できません nullまたはフォームキーの問題:パッチ9767が無効なフォームキーを取得

2)ハンク#1が225で失敗しました。1ハンクのうち1つが失敗しました-ファイルapp / design / frontend / enterprise / default / template / persistent / checkout / onepage / billing.phtmlに拒否を保存します:SUPEE-9767-ハンク#1 225で失敗しました。1つのハンクのうち1つが失敗しました

3)拒否をファイルapp / code / core / Enterprise / PageCache / Model / Observer.php.rejに保存する:SUPEE-9767エラー:パッチを正常に適用/元に戻すことができません

4)SUPEE-9767、modmanおよびsymlinks:SUPEE-9767、modmanおよびsymlinks

5)app / design / frontend / rwd / default / layout / page.xmlハンク#1は36で失敗しました。ハンク#2は54で失敗しました。2つのハンクのうち2つが失敗しました:SUPEE-9767エラー

6)1つのハンクのうち1つが失敗しました-ファイルapp / code / core / Mage / Sales / Model / Quote / Item.phpに拒否を保存します:Magento 1.9.2.2 SUPEE-9767パッチエラー

7)ワンステップチェックアウトエラー(これもフォームキーの問題です):SUPEE-9767 Magento CE 1.9.3.3ワンステップチェックアウトがチェックアウト時のフォームキー検証で機能しない

8)ワンステップチェックアウトの顧客登録の問題:SUPEE-9767 Patch / CE 1.9.3.3-1ページのチェックアウト-顧客登録の問題

9)app / code / core / Mage / Core / Model / File / Validator / Image.php:Magento SUPEE 9697 1.9.2.2がImage.phpで失敗する


1
パッチのバージョン2が間もなく利用可能になります。バグを修正する必要があります。
アイコン

1
v2を待っている
@icon

9

新しいMagentoインストールでは、デフォルトでSymlinksがデフォルトで常に無効になっていることに注意してください。管理YES / NO設定値のデフォルトは「NO」です。この更新により、config.xmlのシンボリックリンクが明示的に無効になり、追加の予防措置として、設定オプションを含むadmin-> developerからテンプレートセクションも削除されます。

1.9.3.2より前のシンボリックリンクを手動で有効にした場合、これは現在のシンボリックリンクの設定には影響しませんが、adminで設定を確認することはできません。

modmanを使用してMagento 1.xモジュールを管理するユーザーは、symlink無効しないください。これにより、modmanモジュールが無効になります。

責任ある管理者は、app / code / core / Mage / Core / etc / system.xmlのテンプレートセクションに対するdiffの変更を探し、セクションを約600行でsystem.xmlに追加することにより、再度symlink管理セクションを有効にできます。ダブルチェックシンボリックリンクはまだ有効になっています

n98-magerun.phar config:dump | grepシンボリックリンク

magento1933およびmagento1932のdiffファイルは、カスタム/拡張テーマに影響を与える可能性のあるデフォルトテーマの変更を識別するのに役立ちます。

diff -r magento1933 magento1932> https://pastebin.com/ADzMBLhr


Symlinksオプションを削除したのはなぜですか?(管理ユーザーの外部で)公開されているエクスプロイトがありますか、それとも共有環境上でのリスクになりますか?
PaddyD

このスレッドは私の質問に答えているようだ:magento.stackexchange.com/questions/176952/...
PaddyD

シンボリックリンクは、理由により無効になっています。シンボリックリンクの代わりにコピーすることをお勧めします。magento.stackexchange.com
a

9

問題:php7を使用する、次のエラースローされる場合があります。

Decoding failed: Syntax error

#0 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(179): Zend_Json::decode('')
#1 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(215): Enterprise_PageCache_Model_Observer->_loadDesignExceptions()
#2 /______/app/code/core/Enterprise/PageCache/Model/Observer.php(125): Enterprise_PageCache_Model_Observer->_saveDesignException()
#3 /______/app/code/core/Mage/Core/Model/App.php(1358): Enterprise_PageCache_Model_Observer->cacheResponse(Object(Varien_Event_Observer))
#4 /______/app/code/core/Mage/Core/Model/App.php(1337): Mage_Core_Model_App->_callObserverMethod(Object({custom extensio}_Model_Rewrite_PageCache_Observer), 'cacheResponse', Object(Varien_Event_Observer))
#5 /______/app/Mage.php(456): Mage_Core_Model_App->dispatchEvent('controller_fron...', Array)
#6 /______/app/code/core/Mage/Core/Controller/Varien/Front.php(182): Mage::dispatchEvent('controller_fron...', Array)
#7 /______/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#8 /______/app/Mage.php(691): Mage_Core_Model_App->run(Array)
#9 /______/index.php(105): Mage::run('brandfield_nl', 'store')
#10 {main}

Zendバージョンがそれで何かをしなければならないことはかなり確実です。高速な修正はこれですが、確かに正しくありません:

-> app / code / core / Enterprise / PageCache / Model / Observer.php:244に置き換えます:

    if ($cachedSslOffloaderHeader !== false) {
        $cachedSslOffloaderHeader = trim(@Zend_Json::decode($cachedSslOffloaderHeader));
    }

-> and app / code / core / Enterprise / PageCache / Model / Observer.php:177 with:

    if ($exceptions !== false) {
        $exceptions = Zend_Json::decode($exceptions);
    }

もちろん、これを書き換えるアドオンを作成します。しかし、ここにはもっと良いことがあると確信しています。

更新(より良いソリューション)

-> lib / Zend / Json.phpに移動し、76行目の後にこれを追加します。

    if ((float)phpversion() >= 7.0
        && empty($encodedValue)
    ) {
        return null;
    }

拡張機能を作成してオーバーライドし、コアファイルを編集しないでください。


キャッシュは完全にクリアされました。これは同じ問題ではありません。
folektoras133

2
私たちは、この同じ問題を打つ-アプリ/コード/コア/エンタープライズ/ページキャッシュ/モデルを元に戻す/ Observer.phpは、問題を取り除くが、明らかにそれは、単に予防正しい修正ではありません a:5:{i:0;s:29:"Decoding failed: Syntax error";i:1;s:1376:"#0 app/code/core/Enterprise/PageCache/Model/Observer.php(177): Zend_Json::decode('a:0:{}')
ジャダー

9

問題:動的コードまたはcssがチェックアウト時にフォームキー入力要素を無効にする

私が見た問題は、1ページのチェックアウトプロセスで動的コード(paypalプラス)がフィールドセットを上書きする場所です 1ステップの支払い方法フォームhtml要素を -隠されたform_key要素を(cssで)削除または無効にすることです

修正は、formkey要素が動的コードまたはCSSによって無効にされないようにすることです。外formkeyコードを移動するのfieldset要素も役立つかもしれません

<form>
    <?php echo $this->getBlockHtml('formkey') ?>
    <fieldset>
        <?php echo $this->getChildHtml('methods') ?>
    </fieldset>
</form>

form_keyが検出されて1つのページコントローラーに送信されるかどうかは、チェックアウトメソッドを移動するときにブラウザーでajaxネットワークリクエストを検査することで簡単に確認できます。各メソッドは、フォームがキーはありませんが、フォームのキー要素に影響する外部コード、つまりCSSまたは動的なクライアント側の変更について、Magentoのソースコードにパッチが適用されています。

ここに画像の説明を入力してください


2
このちょっとした修正は、EEではうまくいかないようでした。ファイルapp/design/frontend/[package]/[theme]/template/giftcardaccount/onepage/payment/scripts.phtml も更新する必要がある|| elements[i].name == 'form_key'ことがわかりました。35 行目から38行目は、form_keyフォームフィールドを無効にしておくために、他のセレクターと共に含めるように更新する必要があります。
グレッグニコロフ

ありがとう、g-man1066!それがまさに私が抱えていた問題でした。
grafikchaos


8

問題: ジェネリックMagento 5ステップチェックアウトを使用すると、顧客登録が失敗します。

この問題は、フォームキー認証を有効にした場合にのみ発生します。使用されているバージョン:1.7.0.2。ただし、誰かが同じ問題が1.9.3バージョンでも発生することを投稿したようです。 SUPEE-9767 Patch / CE 1.9.3.3-1ページのチェックアウト-顧客登録の問題

チェックアウトに進むと、2つのオプションが表示されます。ゲストまたは登録者としてチェックアウト[登録]をクリックし、パスワードと一緒にフォームに入力すると、すべての手順を実行して注文を完了します。注文が行われますが、顧客はmagentoに登録されません。ゲストが注文したようです。

戻ってフォームキー認証を無効にし、顧客として登録しながら注文を行ったところ、問題なく設置され、顧客はバックエンドに登録されました。


1
ここでは、この問題についてのより詳細なポストだmagento.stackexchange.com/questions/177035/...
デジタルPianismでラファエル

8

2017年7月13日更新[問題は修正されました]

Magentoチームは、このバージョンのパッチでSUPEE-9767 V2をリリースし、透明gifおよびpngの問題が修正されました。

このスレッドで説明したファイルへのすべての変更を元に戻す必要があります。次に、適用されたV1パッチを元に戻し、最終的に新しいバージョンV2を適用します。


プレ-SUPEE-9767 V2

以下に説明するコードを使用しないでください。代わりにV2のパッチを適用してください。以下に説明する問題はこのバージョンで既に修正されています。

透明なpngで問題が発生した場合、管理パネルからアップロードすると背景が黒くなります。(製品上)は、次の場所で導入された画像アップロードコールバックに関連しています。

app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php

現時点では、この動作の正確な原因は不明ですが、コールバックが削除されると奇妙な動作がなくなることを確認できます。

ここに画像の説明を入力してください

更新

OK、SUPEE-9767から更新された関数が見つかりました。これは実際にPNGの透過性を壊しているため、元の画像のコピーが透過性なしで作成されます。

+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
@@ -87,10 +87,33 @@ public function setAllowedImageTypes(array $imageFileExtensions = array())
      */
     public function validate($filePath)
     {
-        $fileInfo = getimagesize($filePath);
-        if (is_array($fileInfo) and isset($fileInfo[2])) {
-            if ($this->isImageType($fileInfo[2])) {
-                return null;
+        list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
+        if ($fileType) {
+            if ($this->isImageType($fileType)) {
+                //replace tmp image with re-sampled copy to exclude images with malicious data
+                $image = imagecreatefromstring(file_get_contents($filePath));
+                if ($image !== false) {
+                    $img = imagecreatetruecolor($imageWidth, $imageHeight);
+                    imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
+                    switch ($fileType) {
+                        case IMAGETYPE_GIF:
+                            imagegif($img, $filePath);
+                            break;
+                        case IMAGETYPE_JPEG:
+                            imagejpeg($img, $filePath, 100);
+                            break;
+                        case IMAGETYPE_PNG:
+                            imagepng($img, $filePath);
+                            break;
+                        default:
+                            return;
+                    }
+                    imagedestroy($img);
+                    imagedestroy($image);
+                    return null;
+                } else {
+                    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
+                }
             }
         }
         throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));

更新

これは、png透明度を保持するための関数の更新バージョンです

  imagealphablending($img, false);
  imagesavealpha($img, true);

これら2行をパッチに追加する必要があります。関数を更新しますapp/code/core/Mage/Core/Model/File/Validator/Image.php

/**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                imagealphablending($img, false);
                imagesavealpha($img, true);  
                imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

更新23/06/17

この機能の更新バージョンは、PNGおよびGIFの透明度を修正します。

    /**
 * Validation callback for checking is file is image
 *
 * @param  string $filePath Path to temporary uploaded file
 * @return null
 * @throws Mage_Core_Exception
 */
public function validate($filePath)
{
    list($imageWidth, $imageHeight, $fileType) = getimagesize($filePath);
    if ($fileType) {
        if ($this->isImageType($fileType)) {
            //replace tmp image with re-sampled copy to exclude images with malicious data
            $image = imagecreatefromstring(file_get_contents($filePath));
            if ($image !== false) {
                $img = imagecreatetruecolor($imageWidth, $imageHeight);
                switch ($fileType) {
                    case IMAGETYPE_GIF:
                        imagecolortransparent($img, imagecolorallocatealpha($img, 0, 0, 0, 127));
                        imagealphablending($img, false);
                        imagesavealpha($img, true);
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagegif($img, $filePath);
                        break;
                    case IMAGETYPE_JPEG:
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagejpeg($img, $filePath, 100);
                        break;
                    case IMAGETYPE_PNG:
                        imagealphablending($img, false);
                        imagesavealpha($img, true);  
                        imagecopyresampled($img, $image, 0, 0, 0, 0, $imageWidth, $imageHeight, $imageWidth, $imageHeight);
                        imagepng($img, $filePath);
                        break;
                    default:
                        return;
                }
                imagedestroy($img);
                imagedestroy($image);
                return null;
            } else {
                throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid image.'));
            }
        }
    }
    throw Mage::exception('Mage_Core', Mage::helper('core')->__('Invalid MIME type.'));
}

1
これにより、Magento 1.7インストールでの問題が解決しました。ありがとう!
チッツェ

Tjitseは、Magentoチームがパッチを修正しない場合にこの変更をメモするだけで、次のパッチを行うときに元に戻す必要があります。bugcrowd.comのコミュニティに問題を提出しました。まもなくパッチ修正が導入されることを期待しています。
ダニエルヨブチェフ

これはpngの場合は修正しますが、透過gifファイルの場合は修正しません。gifファイルはimagecolortransparentを使用して、わずかに異なる扱いを必要とする
alternize

これを交互に指摘してくれてありがとう、gif透明度も修正する更新された関数を参照してください。
ダニエルヨフチェフ

7

問題:管理者に表示されないシンボリックリンク通知を許可する

シンボリックリンク通知は管理通知領域には表示されません。 <block type="core/text_list" name="notifications" as="notifications">

以下のCEとEEの両方のパッチ:

--- app/design/adminhtml/default/default/layout/main.xml
+++ app/design/adminhtml/default/default/layout/main.xml
@@ -119,7 +119,8 @@ Default layout, loads most of the pages
<block type="adminhtml/cache_notifications" name="cache_notifications" template="system/cache/notifications.phtml"></block>
<block type="adminhtml/notification_survey" name="notification_survey" template="notification/survey.phtml"/>
<block type="adminhtml/notification_security" name="notification_security" as="notification_security" template="notification/security.phtml"></block>
-            </block>
+                <block type="adminhtml/checkout_formkey" name="checkout_formkey" as="checkout_formkey" template="notification/formkey.phtml"/></block>
+                <block type="adminhtml/notification_symlink" name="notification_symlink" template="notification/symlink.phtml"/>
<block type="adminhtml/widget_breadcrumbs" name="breadcrumbs" as="breadcrumbs"></block>
<!--<update handle="formkey"/> this won't work, see the try/catch and a jammed exception in Mage_Core_Model_Layout::createBlock() -->

問題は(自己終了する)</block>の最後にcheckout_formkeyあるため、親を閉じますnotifications。これにより、notification_symlinkはに含まれcore/text_listず、レンダリングされません。


これは実際には問題ではありません。シンボリックリンクが明示的に無効になり、シンボリックリンク設定セクションが削除されたため、通知は削除されました。v1933でadminのsymlink値を手動で変更することはできないため、管理者通知を表示することは無意味です。問題は、シンボリックリンクを必要とするユーザー、つまりmodmanが手動で有効にできない1933年の新しいインストールで発生します。Magentoは新しい1.xのインストールを期待していないと推測できます...
...-

私は同意しません。このパッチは、既に設定されている場合は構成を明示的に無効にしません-まだ設定されていない場合にのみ無効にします。したがって、このパッチの前にインスタンスのDB / local.xmlでdev / template / allow_symlinkがyesに設定されていて、パッチを適用すると、潜在的に脆弱であるためシンボリックリンクが許可されるという警告を受け取る必要があります。
mwylde

私はあなたの主張を見て、あなたは正しいです。しかし、普通のユーザーにとっては何をするでしょう-設定オプションが削除されたため、管理者から手動で無効にすることはできません。これはちょっとしたキャッチ22の状況です
...-paj


7

問題:EE出荷テンプレートにパッチが適用されていない

EE 1.13.1.0インストールにパッチを適用し、エンタープライズ出荷テンプレート(app/design/frontend/enterprise/default/template/checkout/onepage/shipping.phtml)にformkeyを追加しませんでしたが、請求および支払いテンプレートには追加しました。

app/design/frontend/base/default/template/checkout/onepage/shipping.phtml パッチ適用れました。


また、(EE 1.14.2の場合)form_keyをに追加する必要が /app/design/frontend/enterprise/default/template... .../checkout/cart/coupon.phtmlありました.../giftcardaccount/cart/block.phtml .../giftcardaccount/cart/check.phtml
グレッグニコロフ

4

SUPEE-9767でパッチされたMagento EEバージョンには問題があります(1.14.3.3へのアップグレードではありません)。そのページのフォームキーがキャッシュされます。したがって、キャッシュをフラッシュしてから製品ページに移動し、ページが完全にキャッシュされていることを確認すると(数回更新する)、その製品をカートに追加できるはずです。

ここで、別のブラウザー(またはシークレットモード)を開いたときに、同じページを開き、製品をカートに再度追加しようとします。フォームキーのため、製品はカートに追加されません。キャッシュを再度フラッシュすると、製品を再びカートに追加できます。

おかげジャスパーZeinstra


3

Magento Composer Intallerを使用する開発者は、展開戦略をSymlinkではなくCopyに変更できます。モジュールファイルを.gitignoreに追加するように構成することもできます。これにより、リポジトリがクリーンなままになります。

https://github.com/Cotya/magento-composer-installer/blob/master/doc/Deploy.md#deploy-per-copy-instead-of-symlink

{ "extra":{ "magento-root-dir": "htdocs/", "magento-deploystrategy": "copy", "auto-append-gitignore": true } }


私たちは、コピーしていることが分かった"magento-force": true,重要になってくる
イェルーン


2

問題:バニラMagento 1.7.0.0でパッチが機能していた[編集済み]

パッチスクリプトのテスト中に、Magento 1.7.0.0のパッチに問題が見つかりました。まだそれを使用している人がいるかどうかはわかりませんが、とにかくそれはSUPEE-9767の問題です。バニラインストールを使用し、以前のすべてのパッチを最初にインストールしました。

使用されているパッチファイル:PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh パッチファイル Magento 1.7.0.1および1.7.0.2で機能します

問題の要約:

ERROR: Patch can't be applied/reverted successfully.
...
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
...
checking file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED
...

記録のために、これは1.7.0.0でパッチを試しました:

$ grep SUPEE app/etc/applied.patches.list
2017-06-01 12:59:49 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
-e 2017-06-01 12:59:49 UTC | SUPEE-1049 | EE-1.12.0.2 | v1 | 6d06f286f461562fa6d6573349f1491f7bf89859 | Wed Feb 13 17:46:13 2013 -0800 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-01 12:59:49 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-01 12:59:49 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-01 12:59:49 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-01 12:59:49 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-01 12:59:49 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-01 12:59:49 UTC | SUPEE-6788 | CE_1.7.0.1 | v1 | 04d237d56b116989e46839c41691585d927f99db | Fri Oct 23 13:52:50 2015 +0300 | f69136a
2017-06-01 12:59:49 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-01 12:59:50 UTC | SUPEE-8788 | CE_1.7.0.0 | v2 | 6b5ef4fc5b09af74d0fd401440948d0a54dd203d | Fri Oct 14 19:27:22 2016 +0300 | 84fa3dd598466fa5c482965a3f8e5395af33bf9d
2017-06-01 12:59:50 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-01 12:59:50 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523

4
そのファイルがない場合、セキュリティパッチSUPEE-7405を適用していない可能性があります。
ライアンホー

@RyanHoerrそのとおりです。1.7.0.0では公式ファイルPATCH_SUPEE-7405_CE_1.7.0.2_v1-2016-01-20-04-58-44.shが機能しないため、SUPEE-7405はスキップされました。ファイルの修正バージョンを作成しました。誰かがそれを必要とするならば、私にメッセージを送ってください。
Jeroen Vermeulen-MageHost

2

奇妙な動作のため、このパッチを元に戻す必要がありました。何らかの理由で、特定のユーザーは特定のアイテムをカートに追加できませんでした。

私はそれがその顧客の現在の見積もりと衝突する古い見積もりと関係があると思います。ユーザーとしてログインし、1D10Tだけではないことを確認して、この問題を確認しました。

先週の金曜日にパッチの寿命を取ったので、それは問題です。1.14.2.4を使用しています。私たちは大幅に変更されているため、他のユーザーでも問題なく機能する可能性があります。ただの警告!


それは正しいです。パッチは、MagentoのEEバージョンのカートに追加するアクションを中断します。基本的に、この問題は、PageCacheモジュールにform_key生成ロジックの1つのバージョンがあるために発生しますが、セッションには独自のバージョンがあります。FPCに要求されたページのキャッシュバージョンがあるが、ミニカートを再生成する必要がある場合、FPC saveが呼び出されると同時にform_keyを再生成するセッションがトリガーされ、独自のform_keyが生成されます。その時点で、form_keyのセッション値は顧客のCookie(FPCプロセッサで使用)に保存されている値と異なるため、カートコントローラーへの追加時に無効なキーを取得しています。
ステパン

私もこの問題に直面しています。修正が見つかった場合はお知らせします。
cmtickle

私はこの問題を解決し、ここでの説明:magento.stackexchange.com/questions/177942/...
cmtickle

SUPEE-9767 v2でこれが解決されたかどうかは誰にもわかりますか?
ワンの弟子

2

問題: 1.6.0.0の無限リダイレクトループ

クイックフィックス

ファイルapp / code / core / Mage / Core / Controller / Varien / Front.php内のメソッド保護関数_checkBaseUrl($ request)内の以下の行を見つけます

 if (isset($uri['scheme']) && $uri['scheme'] != $request->getScheme()
        || isset($uri['host']) && $uri['host'] != $request->getHttpHost()
        || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) {  

これらの行を

 if (isset($uri['host']) && $uri['host'] != $request->getHttpHost()
            || isset($uri['path']) && strpos($requestUri, $uri['path']) === false
 ) { 

その後、ファイルを保存し(REPOにコミット)、キャッシュをクリアし(var / cacheフォルダー内のすべてを削除し)、ストアフロントをリロードします。SUPEE 9767パッチを適用すると、302リダイレクトの問題なしにサイトがロードされるはずです。

根本的な原因

リダイレクト後の実際のリクエストとURIのSCHEME値の違い。例:実際のリクエストはスキームHTTPを返しますが、URIのスキームはHTTPSにすることができます。

考えられる根本的な理由

  1. ほとんどの場合、すべてのhttp要求をhttpsにリダイレクトするためのリダイレクトルールが.htaccessファイルにある場合があります。ユーザーがhttp://yourdomain.comをリクエストすると、スキームを変更して、実際にリクエストしたhttp://yourdomain.comではなくhttps:// yourdomainにリダイレクトした可能性があります。

  2. ベースのセキュアURLと非セキュアURLの両方がhttpsで始まります


2

CONFIRMED BUG 「顧客の登録がチェックアウト時に失敗する」は、私の側で少し異なります。

顧客がチェックアウトで登録を選択した場合、そのパスワードは正しく保存されません。パスワードが保存されていないというだけで、顧客は正しく作成されます。これは、ウェルカムメールにパスワードが表示されないという事実によって検出されました。このため、人々はログインできません。

SUPEE-9767 Patch / CE 1.9.3.3にリンクされたバグ修正-1ページのチェックアウト-顧客登録の問題が私にとっても役立った


2

supee-9767では、これが...の意味を教えてもらえますか?

ここに画像の説明を入力してください


1
jQuery 1.10.2バージョンは脆弱であると見なされ、一部のPCIスキャナーによってフラグが立てられます。1.12バージョンはそうではありません。
ライアンホール

@Detzler StackExchangeはフォーラムではありません。質問したい場合は、質問への回答ではなく、質問を投稿してください。
toon81

1
Ryan Hoerrは、パッチによってもたらされた問題について尋ねました。それで、スクリーンショットで見られるように、私は彼に可能性のある重大な変化を伝えました。この変更の理由を説明することはできません。だから私はサブ尋ねた。あなたの問題は何ですか?
デツラー

2

パッチは、バニラMagento 1.7.0.2でも機能しません。

martins@martinsmac.local:/var/www/magento1702-original$ ./PATCH_SUPEE-9767_CE_1.7.0.2_v1-2017-05-25-09-31-32.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.

patching file app/code/core/Mage/Admin/Model/Session.php
Hunk #1 succeeded at 109 (offset -29 lines).
patching file app/code/core/Mage/Adminhtml/Block/Checkout/Formkey.php
patching file app/code/core/Mage/Adminhtml/Block/Notification/Symlink.php
patching file app/code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Filter/Date.php
patching file app/code/core/Mage/Adminhtml/Model/Config/Data.php
patching file app/code/core/Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php
patching file app/code/core/Mage/Checkout/controllers/MultishippingController.php
patching file app/code/core/Mage/Checkout/controllers/OnepageController.php
Hunk #1 succeeded at 293 (offset -34 lines).
Hunk #2 succeeded at 313 (offset -34 lines).
Hunk #3 succeeded at 363 (offset -34 lines).
Hunk #4 succeeded at 392 (offset -34 lines).
Hunk #5 succeeded at 431 (offset -34 lines).
patching file app/code/core/Mage/Checkout/etc/system.xml
patching file app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php
patching file app/code/core/Mage/Core/Controller/Front/Action.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 141 (offset -7 lines).
can't find file to patch at input line 377
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git app/code/core/Mage/Core/Model/File/Validator/Image.php app/code/core/Mage/Core/Model/File/Validator/Image.php
|index 7f7b9d0..cbbcbb1 100644
|--- app/code/core/Mage/Core/Model/File/Validator/Image.php
|+++ app/code/core/Mage/Core/Model/File/Validator/Image.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored
patching file app/code/core/Mage/Core/etc/config.xml
patching file app/code/core/Mage/Core/etc/system.xml
patching file app/code/core/Mage/Customer/Model/Session.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Adapter/Zend/Cache.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Container/Abstract.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php
patching file app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php
patching file app/code/core/Mage/ImportExport/Model/Import/Uploader.php
patching file app/code/core/Mage/Sales/Model/Quote/Item.php
Hunk #1 FAILED at 502.
1 out of 1 hunk FAILED -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php.rej
patching file app/code/core/Mage/Widget/Model/Widget/Instance.php
patching file app/code/core/Mage/XmlConnect/Helper/Image.php
patching file app/design/adminhtml/default/default/layout/main.xml
patching file app/design/adminhtml/default/default/template/notification/formkey.phtml
patching file app/design/adminhtml/default/default/template/notification/symlink.phtml
patching file app/design/adminhtml/default/default/template/page/head.phtml
patching file app/design/frontend/base/default/template/checkout/cart/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/billing.phtml
patching file app/design/frontend/base/default/template/checkout/multishipping/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/billing.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/payment.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping.phtml
patching file app/design/frontend/base/default/template/checkout/onepage/shipping_method.phtml
patching file app/design/frontend/base/default/template/persistent/checkout/onepage/billing.phtml
patching file app/etc/config.xml
patching file app/locale/en_US/Mage_Adminhtml.csv
patching file app/locale/en_US/Mage_Core.csv
patching file app/locale/en_US/Mage_Dataflow.csv
patching file downloader/Maged/Connect.php
patching file downloader/Maged/Controller.php
Hunk #1 succeeded at 400 (offset -5 lines).
Hunk #2 succeeded at 923 (offset -5 lines).
patching file downloader/Maged/Model/Session.php
Hunk #2 succeeded at 235 with fuzz 2 (offset -13 lines).
patching file js/varien/payment.js
patching file skin/frontend/base/default/js/opcheckout.js

古いパッチを手動で適用した後でも。

$ grep '|' app/etc/applied.patches.list
2017-06-19 04:01:42 UTC | SUPEE-2677 | EE_1.13.0.2 | v2 | d20e6763cd0df70c4ac6e418c9775a1ff0f2618f | Tue Jan 14 17:49:25 2014 +0200 | v1.13.0.2..HEAD
2017-06-19 04:03:26 UTC | SUPEE-2629 | EE_1.12.0.0 | v1 | 5de775cf535e137b0b099d8066bd5b3a81f7ec4c | Wed Dec 11 16:50:40 2013 +0200 | v1.12.0.0..HEAD
2017-06-19 04:04:12 UTC | SUPEE-1049 | EE_1.12.0.2 | v1 | 5cd884653325315804056d4c591572385b3c1d03 | Thu Mar 20 16:33:19 2014 +0200 | v1.12.0.2..HEAD
2017-06-19 04:05:01 UTC | SUPEE-1868-1-12-0-2 | EE_1.12.0.2 | v1 | 2148b1b6be28a9bad0bec9a4aecc63ed318dd201 | Fri Jul 26 13:20:27 2013 -0700 | v1.12.0.2..HEAD
2017-06-19 04:06:38 UTC | SUPEE-4334-v1.11.1.0 | EE_1.11.1.0 | v1 | 40f5a2e4db9ca53dc6a8e62eb0c728fd63b1157e | Wed Sep 10 10:42:31 2014 -0700 | ef80f7bff749c941b4d1736cc2b502888e7540c9
2017-06-19 04:07:10 UTC | SUPEE-1533 | EE_1.12 | v1 | _ | n/a | SUPEE-1533_EE_1.12_v1.patch
2017-06-19 04:08:41 UTC | SUPEE-5345 | EE_1.12.0.2 | v1 | 2d36f61cf684ed26286b6d10307fcb99dd47ff02 | Thu Feb 5 19:39:01 2015 +0200 | v1.12.0.2..HEAD
2017-06-19 04:09:29 UTC | SUPEE-5994 | CE_1.6.0.0 | v1 | _ | n/a | SUPEE-5994_CE_1.6.0.0_v1.patch
2017-06-19 04:10:00 UTC | SUPEE-6237 | EE_1.14.2.0 | v1 | 8b216c42e2e5d2cb5d8e500fcb6690abede9df52 | Fri Jun 12 13:39:59 2015 +0300 | v1.14.2.0..HEAD
2017-06-19 04:11:22 UTC | SUPEE-6285 | CE_1.7.0.2 | v1 | 84749c91e14543e1f96af30e86efdf29f4562c98 | Tue Jun 23 09:48:07 2015 +0300 | c6e6cee8eb..84749c91e1
2017-06-19 04:11:50 UTC | SUPEE-6482 | CE_1.8.0.0 | v1 |  | Tue Jul 14 14:17:04 2015 +0300 |
2017-06-19 04:12:12 UTC | SUPEE-7616 | CE_1.7.0.2-CE_1.4.2.0 | v1 | a16c51e3679c3f19de6c3207b7a42daa7f9227fc | Fri Dec 18 12:42:03 2015 +0200 | 3617437b6da11be812fcca85f4e6ecbd8b8dc94c..a16c51e3679c3f19de6c3207b7a42daa7f9227fc
2017-06-19 04:14:30 UTC | SUPEE-8167 | EE_1.12.0.2 | v1 | b1be28f9cd8c2ecba2aa403e59ad9e3d2855eb95 | Thu May 4 13:52:13 2017 +0300 | 8d12ea6fe564b6dc9ed1affb6de990f81aca3796..HEAD
2017-06-19 04:16:21 UTC | SUPEE-8967 | EE_1.13.1.0 | v1 | 1fa53e9533f6f3a16f24d9b64dabef0ab7f965d7 | Thu Aug 18 16:32:48 2016 +0300 | 97d160644..1fa53e9533
2017-06-19 04:16:44 UTC | SUPEE-9652 | EE_1.14.3.1 | v1 | 4038f0785d828794083f53f10c01aaa6af403523 | Tue Jan 24 15:03:12 2017 +0200 | 9586981e6ca8b255014b242d50b68b88525b0754..4038f0785d828794083f53f10c01aaa6af403523
2017-06-19 04:19:35 UTC | SUPEE-6788 | CE_1.7.0.2 | v1 | 0398c4b951d9a0f64495e7b8b3b8ca480952dd70 | Fri Oct 23 13:50:23 2015 +0300 | cfc252b

私が見つけた解決策/問題は、1.7.0.2のパッチの変更の一部が1.9.2.3以前には存在しなかったファイルに対するものであることです。そのため、パッチスクリプトを実行する前に、新しい1.9.2.3インストールから次のファイルをコピーしました。

  • app / code / core / Mage / Core / Model / File / Validator / Image.php
  • app / code / core / Mage / Sales / Model / Quote / Item.php

このパッチは、他のすべてのセキュリティパッチがすでに適用されていることを前提としています。あなたが話しているファイルは、以前のパッチによって追加/変更されました。少なくともSUPEE-7405がありません。
ライアンホー

こんにちはライアン、実際に7405も適用しようとしましたが、どちらも機能しませんでした... $ ./PATCH_SUPEE-7405_CE_1.7.0.2_v1.1-2016-02-23-07-22-52 \(1) .shパッチを正常に適用/元に戻すことができるかどうかを確認しています...エラー:パッチを正常に適用/元に戻すことができません。(..)Adminhtml / Helper / Sales.php Hunk#1が121で失敗しました。1つのハンクのうち1つが失敗しました-ファイルに拒否を保存します(..)Adminhtml / Helper / Sales.php.rejパッチファイル(..)/ Core / Model / Config.php Hunk#1が1642で失敗しました。1つのうち1つのハンクが失敗しました-ファイル(..)への拒否の保存(..)Config.php.rejパッチファイル(..)/ Quote / Item.php Hunk#1 .... 509で失敗しました
リカルド・マルティンス

@RicardoMartinsこのエラーを解決するにはどうすればよいですか:app / locale / en_US / Mage_Adminhtml.csv Hunk#2にパッチを当てると36で失敗しました。 ?
zus

0

https://magento.stackexchange.com/a/176930/46249に追加します

新しいMagentoインストールでは、デフォルトでSymlinksがデフォルトで常に無効になっていることに注意してください。管理YES / NO設定値のデフォルトは「NO」です。この更新により、config.xmlのシンボリックリンクが明示的に無効になり、追加の予防措置として、設定オプションを含むadmin-> developerからテンプレートセクションも削除されます。

1.9.3.2より前のシンボリックリンクを手動で有効にした場合、これは現在のシンボリックリンクの設定には影響しませんが、adminで設定を確認することはできません。


太字のテキストは正しくありません。1.9.3.4(SUPEE-9767 V2)またはそれより新しい現在の設定に更新する場合は削除されます:

# app/code/core/Mage/Core/sql/core_setup/upgrade-1.6.0.6-1.6.0.7.php
$connection->delete(
    $this->getTable('core_config_data'),
    $connection->prepareSqlCondition('path', array(
        'like' => 'dev/template/allow_symlink'
    ))
);

責任ある管理者は、app / code / core / Mage / Core / etc / system.xmlのテンプレートセクションに対するdiffの変更を探し、セクションを約600行でsystem.xmlに追加することにより、再度symlink管理セクションを有効にできます。ダブルチェックシンボリックリンクはまだ有効になっています

構成オプションを再度表示するだけでは、問題は解決しません。このオプションは表示されますが、新しく導入されたバックエンドモデルでは値を保存できないため、設定を変更することはできません。見る:

# app/code/core/Mage/Core/etc/system.xml
<backend_model>adminhtml/system_config_backend_symlink</backend_model>

そして

# Mage_Adminhtml_Model_System_Config_Backend_Symlink
public function save()
{
    return $this;
}

したがって、このバックエンドモデルを削除またはオーバーライドする必要があります。SUPEE-9767V2のインストール後にシンボリックリンクを有効にする方法をご覧ください

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.