【EC-CUBE】セキュリティアラート(2013/11/19)

EC-CUBE にセキュリティ上の問題が見つかったそうです。
セキュリティ関連の対処をちゃんとやってくれるのは有難いのですが、このシステム、アップデートやらパッチ当てやらがどうにも厄介。
WordPress ならWeb上の操作でアップデートできるし、CakePHPもシステム領域と開発領域が綺麗に分かれてるから簡単にアップデートできて便利なのですが。
少しでも楽に EC-CUBE のアップデートやパッチ当てを行うためには、こんな風にすればいい~と思いついたことを書いてみます。

1)ソースカスタマイズはExクラスで

サイト機能の実装領域は class と class_extends があり、以下のような構造になっています。

  • 通常クラス(class内)には ec-cube.net 提供のソースコードがびっちり
  • Exクラス(class_extends内)は空っぽか、親クラスの関数を呼び出すだけの関数があるだけ
  • 同名のExクラスは通常クラスを親クラスにする(例: LC_Page_Ex は LC_Page を継承する)
  • 他クラスが親クラスを持ったりインスタンスを作るときはExクラスを呼ぶ(例: LC_Page_Index は LC_Page_Ex を継承する)

つまり、Exクラス内に書いたソースは通常クラスよりも優先されます。
たとえばExクラスに関数を追加すると、追加した関数内で呼び出しをしない限り、通常クラスの同名関数は呼び出されなくなります。
Exクラスはカスタマイズをするための場所なわけです。

パッケージ内のExクラスは必ず空ですし、セキュリティパッチにExクラスのファイルは含まれません。
そのため、通常クラスを変更せず、カスタマイズをExクラス内に限定しておくと、バージョンアップとパッチ当てのときに楽ができます。

2)class の上書きはExクラス確認してから

基本的に class はカスタマイズしないので上書きしても問題なさそうですが、Exクラス側に問題が出る可能性があります。
ファイルの変更がExクラスの処理に影響を与えるかどうかを確認してから上書きしましょう。
変更あるファイルのExクラスがカスタマイズしていない場合は、上書きしてOKです。

3)Smarty以下は手動マージ

機能部分である class と class_extends とは違い、デザイン部分であるSmarty以下はカスタマイズするのが当たり前だと思われます。
こっちはもう諦めて手動マージするしかありません。わたしはFileZillaとWinMergeでがんばりました。
カスタマイズしないページ(例: 複数配送の宛先入力)はWinMergeで確認した結果、新ファイルをそのままアップロードすればよい場合もあります。

こんなところでしょうか。
弊社はかなりの数のEC-CUBEを管理しており、しかもそれぞれがかなりカスタマイズしてあるので、パッチ当てはなかなか大変な作業です。
脆弱性は潰すに越したことは無いので、対応しないわけにはいきませんが、このような手間はないほうが望ましいものです。


投稿者:

さみどり

さみどり

パラファミリーの技術担当です。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です