SQLインジェクション対策もれの責任を開発会社に問う判決

1月13日に、北大の町村教授による興味深いブログ記事が発表されました。

• privacy:個人情報漏洩で脆弱なシステムの責任をソフトメーカーに問う事例

この記事によると、SQLインジェクション脆弱性が原因でクレジットカード情報が漏洩した事件につき、ショップ側が開発会社を相手取り損害賠償請求の裁判を起こし、ショップ側が勝訴したとのことです。

判決はこのURLで読むことができます。以下、判例時報2221号に掲載された判決文も参照しながらエントリを書くことにします。

事実および裁判所の判断

まずは、事実および東京地裁の判断を説明します。

登場人物は下記の通りです。

• X株式会社: インテリア商材の通信販売を営む（原告）
• Y株式会社: システム開発の会社（被告）

概要
X社が運営するECサイトに対して、外部からの不正アクセスにより、最大7316件のクレジットカード情報が漏洩した。X社は謝罪、対応、調査等の費用、売上減少による損害等に関して、Y社に対して、委託契約の債務不履行にもとづき1億円余りの損害賠償を請求、東京地裁に起訴した。結果、原告が勝訴し、東京地裁は約2262万円の損害賠償金を支払うよう被告に命じた（確定）。

時系列まとめ:

日時	事実
2009年1月30日	X社とY社が業務委託基本契約書を締結
2009年2月4日	X社がY社にウェブサイト向け商品受注システムを発注（889万円余）
2009年4月15日	ウェブサイト稼働開始。この時点ではクレジットカード情報はサーバーに保存せず
2010年1月26日	X社は顧客のクレジットカード情報をX社の基幹システムに転送する旨の仕様変更をY社に発注(31万5千円)
2010年1月29日	同引き渡し、稼働（この時点からカード情報がサイトDBに保存される）
2011年4月20日	カード会社から原告にカード情報漏洩の可能性を伝える
2011年4月21日	ECサイトのサービスを停止
2011年4月30日	セキュリティを強化してサービス再開。クレジットカード決済は停止
2011年5月26日	情報漏洩の旨を告知（アーカイブ）
2011年8月23日	原告は別会社に委託した新サイトに移転
2011年10月14日	原告が東京地裁に告訴
2011年12月22日	原告がマザーズ上場
2014年1月23日	判決（概ね原告の勝訴、確定）

ポイントは下記の通りです。

• X社（原告）はセキュリティ対策について特に指示はしていなかった
• 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった
• 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった
• X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日）
• X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった
• 以下の脆弱性その他が認められた
• システム管理機能のIDとパスワードが admin/password であった
• 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイル公開）
• SQLインジェクション
• クロスサイトスクリプティング
• ログにカード情報が保存されていた
• DBに保存されたカード情報にはセキュリティコードも含まれていた

これに対して、東京地裁の判決は下記の通りです。

• クレジットカード情報が漏洩した原因は複数考えられるが、脆弱性やアクセスログ、不正利用の状況からSQLインジェクション攻撃によるものと断定
• セキュリティ対策についてX社からの指示はなかったが、Y社は必要なセキュリティ対策を講じる義務（債務）があり、それを怠った債務不履行がある
• Y社は、SQLインジェクションはカード情報とは無関係の箇所にあったので、この脆弱性が原因ではないと主張したが、裁判所はこの主張を退けた
• 損害賠償責任制限について
• 損害賠償責任制限自体については認める
• 契約書に明記はないが、故意あるいは重過失に起因する損害については責任制限の範囲外とする
• 仕様書に記載はないがSQLインジェクション対策を怠ったことは重過失である
• よって今回の事案は損害賠償責任制限には該当しない
• 原告からの損害賠償請求のうち、おわびのQUOカード代や梱包発送費などの損害は全額認められたが、売上減の機会損失は6041万4833円の要求に対して、400万円のみが認められ、システム委託契約費用約2074万円に対しては、他社システムに移行後の利用料等（約27万円）のみが認められた
• Y社がカード情報をDBに保存しない方式をX社に提案したにも関わらずX社がそれを採用しなかった件をX社の過失と認め、過失相殺3割が認定された
• 瑕疵担保期間(1年)を超えていたが、瑕疵担保期間はあくまで無償補修の期間を定めたもので、損害賠償請求権の期間制限を定めたものではないので、損害賠償請求は有効（2015/1/22 22:30追記）
• 結果、3131万9568円の損害を認定し、その3割を控除して、2262万3697円の損害賠償をY社に命じた

SQLインジェクション対策がY社の債務である理由を判決文より引用します。

そこで検討するに，証拠（甲１４，２５，２９）によれば，経済産業省は，平成１８年２月２０日，「個人情報保護法に基づく個人データの安全管理措置の徹底に係る注意喚起」と題する文書において，ＳＱＬインジェクション攻撃によってデータベース内の大量の個人データが流出する事案が相次いで発生していることから，独立行政法人情報処理推進機構（以下「ＩＰＡ」という。）が紹介するＳＱＬインジェクション対策の措置を重点的に実施することを求める旨の注意喚起をしていたこと，ＩＰＡは，平成１９年４月，「大企業・中堅企業の情報システムのセキュリティ対策～脅威と対策」と題する文書において，ウェブアプリケーションに対する代表的な攻撃手法としてＳＱＬインジェクション攻撃を挙げ，ＳＱＬ文の組み立てにバインド機構を使用し，又はＳＱＬ文を構成する全ての変数に対しエスケープ処理を行うこと等により，ＳＱＬインジェクション対策をすることが必要である旨を明示していたことが認められ，これらの事実に照らすと，被告は，平成２１年２月４日の本件システム発注契約締結時点において，本件データベースから顧客の個人情報が漏洩することを防止するために，ＳＱＬインジェクション対策として，バインド機構の使用又はエスケープ処理を施したプログラムを提供すべき債務を負っていたということができる。

感想は以下の通り

• 発注者（原告）および受注者（被告）ともにグダグダの状況であった
• 原告は発注者としての責務を果たしておらず、（ほぼ）すべての責任が被告にあるとの判断は、被告に厳しすぎると思う
• とはいえ、被告もなんら「専門家としての責務」を果たしておらず、裁判所はこの点を重視した
• 経産省およびIPAからの注意喚起が「専門家として当然はたすべき責務」の基準と判断された点に注目したい
• 管理機能のID/パスワードが admin/password であった箇所を読んで、しばらく余韻にひたっていた
  ※ただし、被告はシステム引き渡し後に原告がパスワードを変更すると想定していたと主張

考察とまとめ

従来筆者は、経産省の「モデル取引・契約書」などを根拠として、「仕様書に明記されないWebアプリケーションの脆弱性に対する責任は発注者にある」との見解を持っておりましたが、同時に「判例があるわけではないので要注意」としていました（例: PHPカンファレンス2009の講演資料）。今回の東京地裁の判断は、開発会社の「専門家としての暗黙の責務」として、セキュリティ対策の責務（契約上の債務）があると認定した点で画期的なものと言えます。判例時報の記事によると、この判決は「確定」とありますが、下級審判決ですので、今後の事案でどのような判決となるかは分かりません。
また、SQLインジェクション脆弱性が（要求仕様に明記されていないにもかからわず）受注者の重過失であると認定した点にも注目する必要があります。今後は、開発会社は自衛のため、せめて「安全なウェブサイトの作り方」に載っている脆弱性くらいは、顧客から要求がなくても、対策しておくべきでしょう。
発注者の立場に話を戻すと、今回紹介したような判例があったとしても、脆弱性対策を発注仕様に盛り込むべきです。そもそも脆弱性がなく、侵入もされないことが望ましいことは言うまでもないからです。
また、原告は、20万円の追加対策を指示しなかったことを過失と認定され、過失相殺として損害賠償金額を3割減額されました。20万円ケチったために、1,000万円近く損したことになります。
このことから、開発会社側は、採用される見込みが薄くても、自衛策としてセキュリティ対策の提案はどんどんした方が良いということになります。提案した上で発注側が拒否すれば、責任を発注側に転嫁できる（可能性がある）からです。さらに、よくある損害賠償の制限条項が「重過失による場合は無効」と判断されましたので、法務的な対策もあわせて考える必要があるでしょう。

先にも書いたように、今回の判決は「開発会社には厳しいもの」と受け取りましたが、それは私は開発の現場に長くいたからであり、世間一般の常識からすれば、「専門家なのだからそれくらいやって当たり前」ということではないでしょうか。
契約論的な責任の所在は別として、SQLインジェクション対策は今や「やって当たり前」なのですから、開発サイドとしては、要求仕様にあってもなくても淡々とSQLインジェクションが混入しない作り方を実践すべきであると考えます。

追記（2015/1/22 22:30）

はてブコメントに瑕疵担保期間に関する言及がありましたので追記します。
東京地裁の判断は、瑕疵担保期間はあくまで無償補修の期間を定めたもので、損害賠償請求権の期間制限を定めたものではないので、損害賠償請求は有効としました。以下、判決文の該当箇所を引用します。

本件基本契約は，「乙は，委託業務の完了の後その成果物に瑕疵が発見されたとき，乙の責任において無償で速やかに補修のうえ納入を行うものとする。」（２６条１項），「乙の保証期間は，特に定めるものを除き委託業務の完了の後１年間とする。ただし，乙の責に帰すべきものでない場合はこの限りではない。」（２６条２項）と定めている。
以上の規定からすれば，本件基本契約２６条２項は，被告による無償補修を定めた本件基本契約２６条１項を前提とした規定であり，被告が無償補修する義務を負う期間を原則として委託業務の完了後１年間とすることを定めたものと解することができ，原告の被告に対する損害賠償請求権の期間制限を定めたものと解することはできない。
これに対し，被告は，本件基本契約に基づく個別契約は請負契約としての性質を有し，請負契約では債務不履行責任の特則として瑕疵担保責任の規定が適用される以上，原告の本件請求も瑕疵担保責任の規定に従った請求というべきであるから，本件請求についても本件基本契約２６条２項が適用される旨主張する。しかし，本件基本契約２６条２項は，その文言上被告による無償補修期間を定めたものと解釈できることは前記説示のとおりであり，本件個別契約の性質が請負契約に当たるか，原告の請求が瑕疵担保責任に基づく請求といえるかといった点は，上記解釈に影響を与えるものではないから，被告の上記主張は採用できない。