タグ付けされた質問 「supee-6788」

2015年10月27日に、MagentoはセキュリティパッチSUPEE-6788をリリースしました。技術的な詳細によると、修正された4つのAPPSECには、ローカルモジュールとコミュニティモジュールでのいくつかの修正が必要です。 APPSEC-1034、カスタム管理URLのバイパスのアドレス指定（デフォルトでは無効） APPSEC-1063、可能なSQLインジェクションに対処 APPSEC-1057、テンプレート処理方法により、個人情報にアクセスできます APPSEC-1079、カスタムオプションファイルタイプで潜在的なエクスプロイトに対処 このセキュリティパッチの影響を受けるモジュールを確認する方法を知りたいと思いました。 私は次の部分的な解決策を思いつきました： APPSEC-1034：<use>admin</use>すべてのローカルおよびコミュニティモジュールのconfig.xmlで検索します。これにより、この問題の影響を受けるすべてのモジュールがリストされるはずです。 APPSEC-1063：を検索addFieldToFilter('(し、addFieldToFilter('`地元やコミュニティのモジュールのすべてのPHPファイルに。変数も使用できるため、これは不完全です。 APPSEC-1057：を検索{{config path=し、{{block type=地元やコミュニティのモジュールのすべてのPHPファイルで、そしてホワイトリストからすべての要素をフィルタリングします。ただし、管理者によって追加されたテンプレート変数が含まれていないため、これは不完全です。 APPSEC-1079：わかりません。 Peter Jaap BlaakmeerによってコンパイルされたAPPSEC-1034およびAPPSEC-1063に対して脆弱な拡張機能のリストもあります。

71 extensions  security  patches  routing  supee-6788 

APPSEC-1057（SUPEE-6788の一部）状態 Magentoには、許可されるブロックまたはディレクティブのホワイトリストが含まれるようになりました。モジュールまたは誰かがCMSページや電子メール{{config path=”web/unsecure/base_url”}}などの 変数を使用{{block type=rss/order_new}}し、ディレクティブがこのリストにない場合は、データベースインストールスクリプトでそれらを追加する必要があります。 コンテンツを処理する拡張機能またはカスタムコード（ブログ拡張機能など）が影響を受ける可能性があります。コードでいくつかの構成変数またはブロックを使用する場合、変数またはブロックをホワイトリストテーブルに追加するデータ更新スクリプトを作成する必要があります。 カスタム変数とブロックをホワイトリストに登録するにはどうすればよいですか？

45 admin  patches  supee-6788  template-directive  directive-whitelist 

SUPEE-6788パッチで動作するようにカスタムモジュールを更新する方法がわかりません。手順はあまり明確ではありません。 Alan Stormのチュートリアルに基づいて、テスト用のジェネレーターwww.silksoftware.com/magento-module-creator/に簡単なモジュールを作成しました。adminにカスタムページがあり、完全に正常に動作しますが、SUPEE-6788で必要な修正を適用すると、adminページに404エラーが表示されます。 カスタム管理ページのURLは次のとおりです。 localhost / index.php / admin / admin_adminhello / adminhtml_adminhellobackend / index / key / 83f08ec4bddff37e47412e16acc8d3f6 / モジュールの構成は次のとおりです。 <config> <modules> <Pulsestorm_Adminhello> <version>0.1.0</version> </Pulsestorm_Adminhello> </modules> <global> <helpers> <adminhello> <class>Pulsestorm_Adminhello_Helper</class> </adminhello> </helpers> <blocks> <adminhello> <class>Pulsestorm_Adminhello_Block</class> </adminhello> </blocks> </global> <admin> <routers> <adminhello> <use>admin</use> <args> <module>Pulsestorm_Adminhello</module> <frontName>admin_adminhello</frontName> </args> </adminhello> </routers> </admin> …

34 adminhtml  routing  supee-6788  custom-admin-url  ce-1.9.2.2 

今日（2015年10月27日）パッチを数週間待ってからリリースされました：SUPEE-6788 多くのパッチが適用されており、インストールされているモジュールの脆弱性を確認することも推奨されます。 パッチの適用方法に関する洞察を得るために、この投稿を開きます。パッチを適用する手順は何ですか？私の理解では、これは手順です： 管理URLの下にない管理機能を持つモジュールを修正する フィールド名またはエスケープフィールドとしてSQLステートメントを使用するモジュールを修正する {{config path=”web/unsecure/base_url”}}およびなどの変数を使用するホワイトリストブロックまたはディレクティブ{{bloc type=rss/order_new}} カスタムオプションファイルタイプによる潜在的なエクスプロイトへの対処（これを行う方法がわかりません） パッチを適用する これは正しい手順ですか？

29 admin  security  patches  supee-6788 

注： この問題は、SUPEE-6788パッチを受け取ったMagentoのすべてのバージョンに当てはまるようです。私の答えでは、パッチを成功させるには両方 .htaccessを.htaccess.sample復元する必要があることがわかります。 magentocommerce.com/downloadsが提供するシェルスクリプトを使用して、CE 1.7.0.2サイトにSUPEE-6788パッチを適用する作業を行っています。このサイトには、以前のセキュリティパッチがすべて適用されています。 スクリプトの名前はPATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.shmd5sumですcfc0cf533fe36a5f573414f0feeb1590（このパッチは、圧縮されていない状態でリリースされたという点で異常でしたが、ファイルは破損または切り捨てられていないようです）。 このスクリプトを実行すると、含まれているパッチの少なくとも1つが失敗したかスキップされたが、パッチの多くの部分が成功したが、git変更が表示されていないことを示すコンソール出力が表示されます。このスクリプトは、同じコードベースを持つ2つの異なる環境でテストされています。1つはUbuntu GNOME 14.04 LTSワークステーション、もう1つはnexcess.com共有サーバー（CentOSを実行）です。 興味深いのは、2つの環境での出力がわずかに異なることです。「checking」と「patching」で始まる行に注意してください。 Ubuntu環境からの出力のサンプル： bash PATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.sh [19:27:10] Checking if patch can be applied/reverted successfully... ERROR: Patch can't be applied/reverted successfully. checking file .htaccess Hunk #1 FAILED at 207. 1 out of 1 hunk FAILED can't find file to patch at input line …

21 magento-1.7  ce-1.7.0.2  security  patches  supee-6788 

SUPEE-6788適用後のPHPの致命的エラー： 113行目のapp / code / core / Mage / Adminhtml / controllers / Permissions / BlockController.phpの非オブジェクトに対するメンバー関数setData（）の呼び出し まず、パッチを適用できませんSUPEE-6788。と言いました -eエラー：パッチを適用/元に戻すことができません リンク「PATCH_SUPEE-6788が1.7.0.2のインストールに影響を与えないように見えるのはなぜですか？」に記載されている手順に従って、パッチを適用できました。 しかし、一部のMagentoブロックがホームページにありません。Googleでの長い検索の結果、ブロックを作成する必要があることがわかりました。System > Permissions > Blocks しかし、一部のテーブルが作成されないため、アクセスできません ( permission_block and permission_variable ) この問題は、次の手順で解決されました（テーブルpermission_blockおよびpermission_variableがSUPEE-6788の後に作成されませんでした） しかし、私は権限の下でブロックを編集または作成することができず、リストビューのみが表示されます。上記のエラーを取得する

7 magento-1.8  supee-6788 

ストアを最新のMagento CE 1.9.2.2ソフトウェアバージョンに更新しました（パッチSUPEE-6788ではなく、Magento Downloaderを使用して完全なコア更新を行いました）。 更新後、私は行きました System > Configuration > Advanced > Admin > Security そして、Admin routing compatibility mode for extensionsオプションが有効に設定されていることを発見しました。 ただし、「有効/無効」セレクタのすぐ下には、短い説明があります この設定を有効にすると、管理機能に対する自動攻撃のリスクが高まります。 この設定を変更する必要があるかどうかわからなかったので、MagentoのWebサイトにアクセスすると、 デフォルト以外の管理URLを自動化された攻撃から保護するには、構成のルーティング互換モードを変更して、パッチを有効にする必要があります。[システム]> [構成]> [管理]> [セキュリティ]の[管理ルーティング互換モードを有効にする]を使用します。 バイトの人々は言う 最後に、セキュリティを強化するために、ここで「互換モード」を無効にします。 System > Config > Admin > Security > Admin routing compatibility mode for extensions そして、有効モードのオプションを示すスクリーンショットを表示します。 私はこれらすべてが非常に混乱しているので、私の質問は、このオプションのどのモードが最もセキュリティを提供するのですか？ 設定を保存した後、セレクターに「有効」または「無効」を表示する必要がありますか？

7 admin  security  supee-6788  ce-1.9.2.2