脆弱性対応（Heartbleed）の責任の所在 東京地判令元.12.20（平29ワ6203） - IT・システム判例メモ
クレジットカード情報漏えい事故に関し，その原因の一つと考えられる脆弱性対応が運用保守業務に含まれていたか否かが争われた事例。 事案の概要 Xは，Xの運営する通販サイト（本件サイト）を第三者に開発委託し，運用していたが，その後，2013年1月ころまでに，Yに対し，本件サイトの運用業務を月額20万円で委託した（本件契約）。本件サイトはEC-CUBEで作られていた。なお，XからYへの業務委託に関し，契約書は作成されておらず，注文書には「本件サイトの運用，保守管理」「ＥＣ－ＣＵＢＥカスタマイズ」としか記載されていない。 2014年4月には，OpenSSL*1の脆弱性があることが公表されたが*2，本件サイトでは，OpenSSLが用いられていた。 2015年5月ころ，Xは，決済代行会社から本件サイトからXの顧客情報（クレジットカード情報を含む）が漏えいしている懸念があるとの連絡を受け（本件情報漏えい）
EC-CUBEで発見した脆弱性の詳細 前編
本件はEC-CUBEに関しての一番最初の届出だったのですが、再現方法が複雑で、自分の説明がうまくなかったのもあって、IPAの方と話がうまくかみ合わず苦労した覚えがあります。 これはPostgresを利用しているEC-CUBEの上記バージョンにおいて、不正なUTF-8文字コードをリクエストに含めるとエラーが発生し、エラーメッセージとして、PHPSESSIDに紐づいているPHPセッションオブジェクトに入っている情報の先頭680バイト部分（長さは環境による）が、ユーザーのブラウザ上で暴露されてしまう、という脆弱性と、そのエラーメッセージのダンプにタグを含ませることができ、XSSが可能、という脆弱性です。 再現に使ったPostgreSQLのバージョンは9.2.3で、MySQL利用のEC-CUBEだと再現せず、またEC-CUBE2.12.3では同様の攻撃を行っても情報は出力されませんでした。 当時使
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
