Contents
脆弱性てなんて読むの？
脆弱性とは「ぜいじゃくせい」と読みます。
たまに、お客様と会話していると「きじゃくせい」と言われる方がおられ、さりげなく「そのぜいじゃくせいですが・・・」と正しい読み方を教えてあげるくらいは優しい私です。
ごく稀に、制作会社の方でも「きじゃくせい」と言われる方がおられるのにはビックリ仰天です。
それだけWEB制作業界も敷居が低くなったんだなぁ。。。と感慨深くなります。
脆弱性て何？
すみません。
冒頭から脱線しました。
脆弱性とは、システムの不具合（プログラムの不具合、仕様の不具合）によるセキュリティの欠陥のことを言います。
悪意のある人がその脆弱性を利用して、システムの内部に入り込んだり、情報を盗んだりすることができます。
ですので、システム（サイト）に脆弱性が発見された際には、速やかに対応する必要があります。
脆弱性はあってはならないものですが、ほとんどのシステムには「存在し得るもの」です。
それを念頭に置いて、サイト運営を行う必要があります。
もちろん、iPhoneにも脆弱性があります。
参考サイト：Apple iOS に複数の脆弱性
EC-CUBEの脆弱性
EC-CUBEにも脆弱性はあります。
脆弱性が発見される都度、開発元の株式会社ロックオンから脆弱性に関する情報と、パッチ（脆弱性を直す為のプログラム）が公開されます。
ですので、パッチを当てれば問題ありません。
EC-CUBEで運営しているECサイト様は、今一度下記ページをご確認下さい。
参考サイト：EC-CUBE脆弱性リスト
※脆弱性があった場合には都度ロックオン社より連絡がございますので、メールをしっかりチェックしておいて下さい。
EC-CUBE脆弱性の詳細情報を公開する意図と公開中止を求める意図
で、昨日、EC-CUBE脆弱性の公開・公開中止に関するtogetterがまとめられていました。
参考ページ：EC-CUBE脆弱性 公開中止関連反響まとめ
ことの発端は、Twitterアカウントg_satoさんが、EC-CUBEの脆弱性に関する情報をブログで公開したことにあるようです。
参考ページ：EC-CUBEで発見した脆弱性の詳細 前編｜WEB系情報セキュリティ学習メモ
脆弱性情報を公開したg_satoさんの意図は以下です。
脆弱性の情報を全員が把握している状態になっているほうが、攻撃ログを解析しやすくなったり、脆弱性の有無を判定できるようになったり等、脆弱性への対策を立てやすくなります。
おっしゃっていることは、至極当然だと思います。
この記事公開を受けて、EC-CUBE開発元の株式会社ロックオンより、後編の公開を中止して欲しいとの申し入れがあったようです。
ロックオン社の意図は以下のようです。
EC-CUBE開発元の株式会社ロックオンより、脆弱性の再現手順の一般公開はユーザーへの被害が発生する恐れがあるため、今回のブログ記事の後編の公開は止めてほしい、との申し入れが来ましたので、後編の公開を中止いたします。
ロックオン社の意図も至極当然です。
なぜロックオン社は公開中止を要請したのか？
記事は前後編に分けて公開される予定で、まずは比較的危険性が低いものから前編として公開されたようです。
前編では、再現に失敗はしたものの検証プログラムが公開されています。
また、後編では他の脆弱性に関しての再現方法を公開すると予告していました。
再現方法が公開されると、「具体的にどうすれば脆弱性を攻撃できるか」が明確にされる訳です。
その点に、ロックオン社はリスクを感じたと思われます。
ロックオン社が公開しているレベルなら具体的に行動に起こす人は少ないだろうが、g_satoさんの情報だと実際に行動する人が出てくる確率が高くなる。
あくまで確率の問題ですが、そこを重視したと思われます。
EC-CUBEはオープンソースだからこそ、公開すべきでは？
EC-CUBEはオープンソースです。
ソースコードが公開されており、誰もが自由に扱ってよいシステムです。
開発元がロックオン社となっているものの、法人・個人を問わず、ボランティア精神溢れる有志が集って、日々機能追加・改善を行っています。
オープンソースであることを考えると、脆弱性の情報もしっかり公開して、皆（開発者・利用者）で共有し、いち早く対応すべきだと思います。
残念ながら、EC-CUBE利用者はEC-CUBEをオープンソースであることを正確に理解していない。
弊社は8年EC-CUBEを取り扱っています。
その長年の経験から分かることは、EC-CUBEを指定して問い合わせしてくるクライアントのほとんどが「EC-CUBE＝無料で使えるシステム」という認識であるということです。
（ちなみに、弊社には、サイトを運営する企業、制作会社・デザイン会社からEC-CUBEに関して問い合わせがあります。
ですので、上記のクライアントはすべてを含んでいます。）
「EC-CUBE＝オープンソース」と理解しているクライアントはかなり少ないです。
ですから、弊社がお取引する際には、「EC-CUBEとはなんぞや」「オープンソースはなんぞや」というお話をさせて頂きます。
決して「無料で使えるシステム」だけではないことを理解頂けるよう努めています。
オープンソースのメリット・デメリットをご理解頂いた上で、EC-CUBEでサイトを構築するようにしています。
それでも、サイトオープン後はシステムに無頓着
上記の通り、クライアントにご説明しても、サイトオープン後はシステムには無頓着です。
弊社では、サイトオープン後の月額保守サービスを提供していますが、保守サービスを契約されるサイト様は半分以下です。
保守をご契約頂いていない場合、システムの管理はクライアントで行って頂きます。
もちろん、脆弱性の情報はロックオン社から届くメールを自社で確認頂く必要がありますし、パッチ適用も行って頂く。
尚、自社でのパッチ適用が困難な場合は、弊社にお問い合わせ頂ければ個別見積もりにて対応させて頂きます。
しかし、保守契約を未締結なサイトはパッチ適用さえ行っていないし、それを依頼しようともしません。
以前、試しに脆弱性が発表されたタイミングで、保守契約未締結のサイトにパッチ適用を打診しましたが、返信は一切ありませんでした。
（自社でパッチを適用したか、もしくは他の制作会社に依頼していればいいのですが。）
やはり、ロックオン社の判断は正しかったのでは？
EC-CUBEをベースに構築しているサイトで、脆弱性対応を行っていないサイトは少なくない。と私は見ています。
そのような状況で、g_satoさんの情報はやはりリスクが高いと思います。
ロックオン社の判断が正しかったのではないでしょうか？
可能性の問題ですが、可能性は極力小さくしておくべきです。
EC-CUBEインテグレートパートナーとしての課題
弊社は8年間EC-CUBEインテグレートパートナーに認定されております。
その名に恥じないよう、EC-CUBE案件に誠心誠意関わって参りました。
もちろん、弊社が制作したサイトには成功して頂きたいです。
もっと基本的なことを言うならば、安定稼働し続けて欲しいです。
その為にも、サイト構築後のシステム保守の重要性、脆弱性対応の重要性をしっかり認知頂けるよう、クライアントの意識改革にも努めて参りたいと思います。
2016.08.29 23:17追記
@ohorikawa 返信が遅れてすみません、ブログ記事での言及ありがとうございます。内容問題ありません。
EC-CUBEに関わる方で、EC-CUBEの利用ユーザーが脆弱性対応パッチをあまり当てていないのではないかという感覚を持っている人が多いようなので、（→）— g_sato (@secmemoblog) 2016年8月29日
@secmemoblog ご了承頂きまして、ありがとうございます。
ご批判が出てくる覚悟でロックオンさんの意向に賛同する形で記事を終えました。
旧EC-CUBEでは自動アップロード機能もありませんし、カスタマイズをしている場合、パッチをそのまま適用できないサイトもあります。1/2— 堀川 治 (@ohorikawa) 2016年8月29日
↑「自動アップロード機能」ではなく『自動アップデート機能』ですね。お恥ずかしい。。。
@secmemoblog また、利用者のリテラシーも低いなど課題が多いのは確かです。
今回の件で、様々な議論がなされ、少しでも前進すればればよいと思っています。
そんな悠長なことを言っている場合ではないのですが。。。
これからも一石を投じるような記事を期待しております。2/2— 堀川 治 (@ohorikawa) 2016年8月29日
