(Photo by：Yuri Samoilov)
- このような方におススメ：ウェブアプリケーションを開発する上でチェックすべきセキュリティ要件を確認したい
- このような方におススメ：セキュリティ要件「SQL インジェクション」について知りたい
今年、クレジットカード情報が漏洩したECサイトでのSQLインジェクション対策に不備があったとして、システム開発を行ったベンダー企業へ損害賠償の支払いを認める判決が話題になりました。
セキュリティに対するリスクはユーザー企業が管理し、今回のようにユーザー企業からクレジットカード情報をデータベース内に保存する仕様での開発を指示された場合、問題が起こってもベンダー企業は責任を負わないのが、今までのシステム開発・情報システム担当の常識でした。
しかし「東京地方裁判所判決／平成２３年（ワ）第３２０６０号」により、ベンダー企業は独立行政法人情報処理推進機構（以下IPAとする）の指針に則った技術的責任を果たしていない場合、ユーザー企業の損失の一部をベンダー企業が負担するのが妥当と判断される判決が出たため、今までの常識は危ういものとなりました。
ユーザー企業がセキュリティ監査を実施したシステムを本稼働させるのであれば、ベンダー企業は安心できます。ですがクレジットカード情報（セキュリティーコードも含め）をデータベースに保存する事を指示するユーザー企業の場合を考えると、クレジットカード情報が漏洩した場合のリスクが大きすぎるため、新規のシステム開発を行えなくなってしまいます。
判決の中でIPA指針について触れられており、これを読むと平成１９年４月以降に開発されたウェブアプリケーションでSQLインジェクションがある場合はベンダー企業の重過失に成り得るため、ベンダー企業にはSQLインジェクションを始めとしセキュリティ対策が求められます。
(Photo by：GotCredit)
経済産業省は，平成１８年２月２０日，「個人情報保護法に基づく個人データの安全管理措置の徹底に係る注意喚起」と題する文書において，ＳＱＬインジェクション攻撃によってデータベース内の大量の個人データが流出する事案が相次いで発生していることから，独立行政法人情報処理推進機構（以下「ＩＰＡ」という。）が紹介するＳＱＬインジェクション対策の措置を重点的に実施することを求める旨の注意喚起をしていたこと
ＩＰＡは，平成１９年４月，「大企業・中堅企業の情報システムのセキュリティ対策～脅威と対策」と題する文書において，ウェブアプリケーションに対する代表的な攻撃手法としてＳＱＬインジェクション攻撃を挙げ，ＳＱＬ文の組み立てにバインド機構を使用し，又はＳＱＬ文を構成する全ての変数に対しエスケープ処理を行うこと等により，ＳＱＬインジェクション対策をすることが必要である旨を明示していたことが認められ，
引用元URL: http://www.softic.or.jp/semi/2014/5_141113/op.pdf
ここまで読んでIPAによる「情報システムのセキュリティ対策」が存在している事を初めて知った方も多いと思います。本記事ではIPAが公開しているSQLインジェクション指導について主に説明して行きます。
IPAによるSQLインジェクション指導について
今回取り上げた判決ではIPAから出されている「大企業・中堅企業の情報システムのセキュリティ対策～脅威と対策」に則り対策がされていれば損害が発生しなかったとされていますので、まずこの文書を紹介します。
※ただし自社内データベースにクレジットカード情報を保存する指示に則りシステムが構築されているため、ウェブアプリケーション以外にもクレジットカード情報が漏洩する経路が存在しています。
ページ名： 大企業・中堅企業の情報システムのセキュリティ対策～脅威と対策～
URL：http://www.ipa.go.jp/security/fy18/reports/contents/enterprise/html/index.html
該当サイト内の「2 公開Webサイトの運用におけるセキュリティ対策（URL: http://www.ipa.go.jp/security/fy18/reports/contents/enterprise/html/621.html）」に記載されているSQLインジェクションの対策指針を抜粋します。
SQLインジェクションによる攻撃を防ぐためには、プログラミングの時点から不正なSQL文を実行しないように対策することが必要である。以下に、SQLインジェクションの対策方法を示す。
・SQL 文の組み立てにバインド機構 3を使用する。バインド機構を使用できない場合は、SQL 文を構成する全ての変数に対しエスケープ処理 4を行う
・Webアプリケーションに渡されるパラメータにSQL 文を直接指定しない
・エラーメッセージをそのままブラウザに表示しない
・データベースアカウントに適切な権限を与える
え？これだけ？と思った方も多いと思います。SQLインジェクションへの対処の詳細については合わせて参照するようと「安全なウェブサイトの作り方」が指示されていますのでこちらの内容を確認します。該当サイト内でのリンクは第6版を指していたため、最新版である第7版のURLを記載します。
ページ名：安全なウェブサイトの作り方（改訂第7版）
URL：http://www.ipa.go.jp/files/000017316.pdf
こちらには少し具体的なSQLインジェクションの対策指針が以下2つの章に記載されています。
- 1.1 SQLインジェクション
- 3.1 SQLインジェクションの例
「3.1 SQLインジェクションの例」でSQLインジェクションを考慮せず、与えられたパラメータをそのままSQLで利用する失敗したコードに対して修正方法がPHPで明記されていますので該当箇所を引用します。
【脆弱な実装】
$query = “SELECT * FROM usr WHERE uid = ‘$uid’ AND pass = ‘$passh’;
$result = pg_query($conn, $query);
【修正例1】
プリペアドステートメントを使う
pg_query()の代わりに、pg_prepare()およびpg_execute()を利用する$result = pg_prepare($conn, “query”, ‘SELECT * FROM usr WHERE uid= $1 AND pass=$2);
$result = pg_execute($conn, “query”, array($uid, $passh));
【修正例2】
プレースホルダの仕組みを持つ関数を利用
pg_query()の代わりに、pg_query_params()を利用する$result = pg_query_params($conn, ‘SELECT * FROM usr WHERE uid = $1 AND pass = $2’, array($uid, $passh));
【修正例3】
専用のエスケープ関数を利用
pg_escape_string()を利用し、pg_query()で実行するSQL文中の全ての変数要素に対してエスケープ処理を行う$query = “SELECT * FROM usr WHERE uid = ‘”.pg_escape_string($uid).”‘ AND pass = ‘”.pg_escape_string($passh).”‘”;
$result = pg_query($conn, $query);
これらはPHPで開発されたウェブアプリケーションにセキュリティホールや脆弱性の問題が多かった時期があったため、当時の事情を踏まえてPHPでサンプルが書かれていると思われます。各開発言語でも同じ様にプリペアドステートメントを使う等してSQLインジェクションが発生しない実装を行う必要があります。
SQLインジェクションの影響度について
「2 公開Webサイトの運用におけるセキュリティ対策（URL: http://www.ipa.go.jp/security/fy18/reports/contents/enterprise/html/621.html）」内で参照するようウェブ健康診断仕様（URL：http://www.ipa.go.jp/files/000017319.pdf）
に、具体的なSQLインジェクションの検査項目が記載されています。また、各種脆弱性の危険度と想定被害の一覧が「2.1. 診断対象脆弱性（診断項目）及びその選定理由」に記載されています。SQLインジェクションはOSコマンドインジェクションと同じレベルでの影響があるため、脆弱性がある状態で攻撃を受けると大量の情報漏洩や改ざんの被害が発生する事が説明されています。
判決ではIPAが明示しているSQLインジェクションへの対策が行われたシステムが納品されていない事に問題が合ったとされています。SQLインジェクションへの対策内容を見ると、お約束な事柄のため一定の経験のあるベンダー企業であれば問題になりづらい事も想像できます。
(Photo by：Linux Screenshots)
ウェブアプリケーションのセキュリティは、実装のタイミング、納品前の結合テスト、納品時の検収作業、同じく納品時のセキュリティ監査、とベンダー企業で2回、ユーザー企業側で2回の合計4回テストされます。
もし開発者がウェブアプリケーションのセキュリティに対し理解が薄くても、実装フェーズ以後3回テストされるタイミングがありますので、ウェブアプリケーションの実装、品質管理、検収、監査に携わるそれぞれの責任者が、ユーザー企業、ベンダー企業問わずIPAのSQLインジェクションを含むウェブアプリケーションのセキュリティの指針に目を通し、テストを行う事が、ベンダー企業にとって賠償責任を回避する、ユーザー企業にとって情報漏洩による実害を防ぐために求められます。
要約・まとめ
今回はIPAが提供しているSQLインジェクションに関する文章のどこを見ればセキュリティ不備に気付き未然に訴訟を防げたのかについて説明をしました。
次記事では、ウェブアプリケーションにセキュリティ不備が紛れ込む事を防ぐためにユーザー企業側とベンダー側の両方で利用できる「セキュリティ要件確認支援ツール」を紹介して行きたいと思います。
本ブログは、Git / Subversion のクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
開発の効率化をしたい！もっと便利なツールを使いたい！そんなお悩みをtracpathで解決！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
1 Comment
[…] 前回(IPAのウェブアプリケーション・セキュリティ要件を確認する（SQLインジェクション）)は、クレジットカード情報が漏洩したECサイトでの判例からIPAで提示されているSQLインジェク […]