SQLインジェクション対策を真面目に考えないとまずい時代

Webアプリの情報事故に関する判決(2015/1/23)に関して、
開発者が他人事じゃいられないものがあったので、広くみなさんに問題を知ってもらいたくメモしておきます。

##■ 問題の判決について

● privacy:個人情報漏洩で脆弱なシステムの責任をソフトメーカーに問う事例(追記あり)
　 http://matimura.cocolog-nifty.com/matimulog/2015/01/privacy-8cc8.html

以下は上記サイトの抜粋。

個人情報が漏洩してしまったという場合、漏洩した企業はお詫びとか、お詫びの品の
クオカードとか、さらには調査費用とか、様々な出費を迫られる。

その出費は誰のせいにできるかというと、漏洩させた従業員とか委託先とかがあれば、
そいつに請求できる。漏洩がシステムの脆弱性にあるとすると、例えばSQLインジャンクション
SQLインジェクション対策が十分でなかったというような既知のリスク対策を怠ったシステム
納入業者があれば、その業者に請求する。(ご指摘によりタイポ修正)

そんな事例が判例集に載っていた。

この判決の重要なポイントは、Webアプリケーションに含まれていたSQLインジェクション対策不備（いわゆるソフトの脆弱な実装）への責任が、依頼主であるサービス提供者が負うのではなくて、Webサイト開発を受託した業者側の過失として背負わされている点です。

経産省やIPAが個人情報漏洩対策に注意喚起をし、ＳＱＬインジェクションに際しての
「バインド機構の使用又はエスケープ処理を施したプログラム」が推奨されていたことから、
これらの対策をとるべき債務があったのにこれを怠った債務不履行責任を認めたのである。

経産省やIPAから、SQLインジェクション対策として、プレースホルダの利用が注意喚起されているのは少しでもセキュリティに興味のある方なら知っているとは思いますが、デザイン畑の人でも気軽に作れる敷居の低さがWebの魅力でもありますし、知らないWebサイト開発者の方も多い世情なんじゃないかと個人的に思います。

にも関わらず、

注目の損害だが、以下のように認められている。
契約委託料27万円程度
顧客への謝罪費用1863万円余り
クオカードと包装代1636万円余り
郵送代124万円余りなど
顧客からの問い合わせ等の対応費用500万円弱
調査費用400万円弱(これは半分以上がラックの調査費用)
売上損失400万円等
合計約3232万円が相当因果関係ある損害と認められている。

なお、システム改修の必要についてはショップ側も認識していながら先延ばししていたという
ことも認定されていて、3割の過失相殺が主張なしにされている。

かくして、弁護士費用も含めて2262万円余りの賠償を認めたというものである。

受託業者側で支払わなければならない費用はなんと2262万円。
セキュリティについては委託/受託側双方がぐずぐずの状況だったにも関わらず、専門家としての責任を問われて受託側の過失の方が重い判決となっています。

今回は、クレジットカード情報が漏えいしてしまったのも影響してますが、自転車操業な小規模なベンダだとこんな金額要求されたら経営の進退問題に発展しちゃいます。Webサイト開発は安く請け負って短納期、大量生産なスタイルも多いと思いますが、セキュリティリスクまで負わされるとなると、怖くてそんな操業ができなくなる所も出てくるかもしれません。

まだ地裁ですのでセキュリティ研究家の徳丸さんの感想にもありますが、判決が覆される可能性はあります。正直、今回のケースのようにSQLインジェクションなどごく基本的・常識的な脆弱性であれば過失と認められても致し方ない面はあるなと個人的には思うのですが、これがもっと拡大解釈されてマイナーな脆弱性を踏み台にさせられた場合にも受託側が責任を負わされてしまう？と考えるとこの判決は深刻に思えます。

##■ 今回の件を受けて、開発者(受託)側でできる対策は？

###①開発者が脆弱性の知識を得る。
脆弱性について何も知らない状況で開発を続けるのは非常に危険です。まずは、脆弱性について理解し、その対策であるセキュアプログラミングについて、勉強していくしかないと思います。そうした地道な努力から初歩的なミスを減らしていくことでセキュリティリスクを大幅に低減させることができます。

少なくとも、下記の資料に載ってるような知名度の高い脆弱性は、プロとしての最低限の嗜みとして知っておかなければなりません。（SQLインジェクションはOWASP Top 10の中で堂々1位の脆弱性です）

• OWASP Top 10
  　https://www.owasp.org/images/7/79/OWASP_Top_10_2013_JPN.pdf

• 安全なウ ェ ブ サ イ ト の作り方
  　http://www.ipa.go.jp/files/000017316.pdf

• 安全なSQLの呼び出し方
  　http://www.ipa.go.jp/files/000017320.pdf

また、下記のようなセキュアプログラミング教材もIPAから無料で展開されていますので社員・チーム内教育等に活用して下さい。

• IPA セキュア・プログラミング講座
  
  　http://www.ipa.go.jp/security/awareness/vendor/programming/

###②外部の脆弱性診断会社を利用する。
Webサイトの脆弱性診断は多くのセキュリティ業者が行っています。想定されるセキュリティリスクの多寡に合わせて、専門家に相応の診断を依頼するのが安全パイと思います（1万～100万）。

外部の診断会社に診断を依頼して安全だったからといって、それが金銭面での保証になるわけではありませんが、大きくセキュリティリスクを低減させることができます。少なくともECサイト等、（事故発生時に大きな影響が想定される）顧客の金銭情報を扱うサイトを開発する場合は、信頼のおける専門家に診断してもらう必要があります。

※この記事は広告ではありませんので診断会社の紹介はしません。「WEBセキュリティ 診断」等でぐぐって下さい。

###③セキュリティ要件と対策について発注元と合意を取っておく
これが一番大事なことなのかもしれません。
開発契約の場合、セキュリティ要件を明記しない場合も多いと思いますが、委託元企業との契約時に、事前にセキュリティ要件・対策内容を合意しておくことを強くお勧めします。
ユーザー（委託）側は、Webアプリ？なにそれの世界の住人である可能性も十分にあります。そこはそうした危険性があることを専門家の側から積極的に委託側に伝えてリスクヘッジしていくべきです。たとえば、少なくとも上で挙げたような基本的な部分は受託側で努力するのは基本ですが、Dos攻撃には？認証方式は？など実際の所その他多くの合意すべき事項があります。望ましいあり方としては、そうしたセキュリティ要件とその対策内容をしっかりと契約時に合意し、コストがかさむ部分は上積み請求することだと思います。
予め、リスクを想定して対策を取っておくことは委託側/受託側双方に益のあることです。
※情報事故が起こった場合、結局、委託側も金銭や信頼の喪失につながりますので。

セキュリティ要件の定義は、下記なんかが参考になると思います。

• セキュリティ要件を定義しよう（Webアプリ編）
  　http://qiita.com/YusukeSaito/items/967d22d6aae0a05c8837

• JNSA セキュアシステム開発ガイドライン「Web システム セキュリティ要求仕様（RFP）」編
  　http://www.jnsa.org/active/houkoku/web_system.pdf

---

※この記事が参考になった！という方は是非「ストック」お願いします