メモ代わりに残しておきます。
SQLインジェクション対策の仕方
被告は，ＳＱＬインジェクション対策として，ＳＱＬ文の組立てにバインド機
構を使用し，又はＳＱＬ文を構成する全ての変数に対してエスケープ処理を行うべき義務が
あったにもかかわらず，これらの対策を行わなかった。すなわち，プログラムの一か所にで
もプログラム作成者の予想しないＳＱＬ文が実行される状態にあれば，第三者がクレジット
カード情報等の個人情報を窃取することが可能であるため，ＳＱＬ文を構成する部分の一か
所にでもバインド機構の使用又はエスケープ処理によるＳＱＬインジェクション対策がされ
ていなければ，本件ウェブアプリケーションには脆弱性があり，被告の債務不履行を構成す
るというべきである。
http://www.softic.or.jp/semi/2014/5_141113/op.pdf
・SQLインジェクション対策について - 独立行政法人 情報処理推進機構（ＩＰＡ）-PDFファイル
理論的には、ＳＱＬ文を構成する全ての変数に対してエスケープ処理を行うだけなんですね。
新規に作る部分、追加する部分については、初めからこの部分を意識していれば対策は理論上は出来る。またソースを机上でチェックすることも可能である。
既存のフレームワークや既存のCMSとかある場合は、その部分のチェックをするのは事実上？コスト上？無理な気はしなくはないが・・・。
クレジット決済処理について
今回の件とは関係ないが、セキュリティーコードをローカルに保存しても問題ないかを調べたときに出てきた事例のリンクも貼っておく・クレジットカード情報流出事件があったようなので、決済システム周りについて語ってみます。 - フジイユウジ::ドットネット
・「あれ？使えない…」突然のカード利用停止とネットの関係とは - WooRis（ウーリス）WooRis（ウーリス）
・【速報】イモトのWiFi・グローバルデータが11万件クレジットカード流出。セキュリティコードを含み、発表も1ヶ月後 - ライター三上洋 事務所
・エクスコムの情報流出はシステム設計というより業務設計がだめな件 - aikeの日記
セキュリティコードは、保存してはダメ？！
昔、セキュリティコードを保存してはいけないとか開発時に聞いたことがあるんですが、今調べてみると、ダメだという根拠が見つけることができないんですね。
例えば、日本クレジットカード協会のガイドライン？には、上記のように書いてあって、絶対にダメとは書いてないんですね。
ただ、必然性がないのに保存するのはダメと書いてあるし、また実際、必要ないのに将来の為とか思って保存するのはリスク以外の何物でもないのは明白。
セキュリティコードは、保存しないためには？
正しいやり方として、申し込み時に与信（オーソリ）だけやって利用後に売上処理をやる、あるいは決済代行会社のカード番号あずかりサービスを利用する、といった方法があるようです。後から売上確定ってシステムは少し携わったことあるけど、あれって確定／キャンセルくらいしかできないかと思ってました。まだまだ修行が足りません。
エクスコムの情報流出はシステム設計というより業務設計がだめな件 - aikeの日記
例えば申し込み時には金額が確定しなくても、上記のように処理すればセキュリティーコードを保存する必要はないということです。
決済サービスに丸投げすべきなのでは？
開発者側の立場でリスク回避するのならそうなると思うけど、お客さんにとっては、単にリスクの場所が移動するだけだという話はある。
決済関係を扱う時のセキュリティ？の話
図1：PCI データセキュリティ基準 概要（PCI DSS version2.0）
安全なネットワークの構築と維持：
1. カード会員データを保護するために、ファイアウォールをインストールして構成を維持する
2. システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
カード会員データの保護：
3. 保存されるカード会員データの保護
4. オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
脆弱性管理プログラムの整備：
5. アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新する
6. 安全性の高いシステムとアプリケーションを開発し、保守する
強固なアクセス制御手法の導入：
7. カード会員データへのアクセスを、業務上必要な範囲内に制限する
8. コンピュータにアクセスできる各ユーザに一意のID を割り当てる
9. カード会員データへの物理アクセスを制限する
ネットワークの定期的な監視およびテスト：
10. ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
11. セキュリティシステムおよびプロセスを定期的にテストする
情報セキュリティポリシーの整備：
12. すべての担当者の情報セキュリティポリシーを整備する
コラム PCI DSS対応を検討する加盟店が知っておくべき選択肢｜ NTTインターネット 総合決済情報サービス
判決でも、上記ににた観点で評価しているみたいで・・・・。
SQLインジェクション対策もれの責任を開発会社に問う判決
あまり話題になってないね。これは予想外。
Winny裁判に匹敵するぐらい、結構衝撃的だと思うんだけど…。
SQLインジェクションで開発業者に有罪判決が出た件
この手の話は、総合的な判断で妥当かどうか見ないとダメだと思うんですね。
医療ミスとかでも、すぐに医者とかがその程度で責任を問われたら現場は成り立たないとか騒いだりするけど、そういうのと一緒で、技術者がそういっても妥当かどうかどうかは別の問題だと思う。
・東京地方裁判所判決／平成２３年（ワ）第３２０６０号
原告は，平成２１年２月４日，被告に対し，注文書を交付して，原告のウェブサイ
ト「×××オンラインショップ」（以下「本件ウェブサイト」という。）における商品のウ
ェブ受注システム（以下「本件システム」という。）の導入を合計８８９万５６００円（消
費税込み。以下では，特に断らない限り，消費税込みの金額を意味する。）で発注した（以
下「本件システム発注契約」という。）。（甲４の１ないし４，乙３）
（６） クレジットカード情報の保存開始
原告は，平成２２年１月頃，被告に対し，本件ウェブサイトにおいて顧客が利用し
た決済方法（金種）について，従前はクレジットカード決済，代金引換又は銀行振込みの区
別しか原告では把握できていなかったため，原告の基幹システム側で請求元情報を正確に管
理する目的から，各種クレジットカード種別（カード会社）を原告の基幹システムに送信す
る旨の本件システムの仕様変更（以下「金種指定詳細化」という。）を依頼し，同月２６日，
注文書を被告に交付し，「機能カスタマイズ（金種指定詳細化）」を３１万５０００円で発
注した。（甲８ないし１０，乙４）
各カード会社に対する毎月の売掛金額を個別に把握できるようにする旨の仕様
変更を依頼したにすぎず，クレジットカード情報の取得及び保存を被告に依頼したものでは
ないし（金種指定詳細化のために当然にクレジットカード情報全部を保存することが必要と
なるわけではない。），金種指定詳細化の際には，被告からは本件データベースにクレジッ
トカード情報を保存する設定とする旨の説明を受けていなかった。原告は，その後の被告と
のメールのやり取りにおいて，クレジットカード情報を保存する設定となっていることは認
識したが，クレジットカード情報を暗号化していないこと及びクレジットカード情報をデー
タベース上で保存することの危険性を認識できなかったために，クレジットカード情報を保
存せず，又は暗号化する設定への改修を求めなかったのであるから，かかる経緯からすると，
原告の行為により被告の債務不履行と本件流出との因果関係が断絶するものではない。
被告は，ＥＣ－ＣＵＢＥをベースとした本件ウェブアプリケーションについても同様の脆弱性が存在する可能性が
高いことを容易に認識し得たのであり，原告との間で保守契約を締結して本件システムを管
理及び運用していたのであるから，納品後も修正プログラム（パッチ）を適用し，又は原告
に適用を推奨すべきであったにもかかわらず，本件システムに上記修正プログラム（パッチ）
を適用していなかったことからして，被告には重過失が認められ，本件基本契約２９条２項
は適用されない。
東京地方裁判所判決／平成２３年（ワ）第３２０６０号
システムは900万円程度で、追加のカスタマイズとして30万ぐらいの機能で、その30万の機能が今回の該当部分だと思われる
あとは、必要ないのにクレジット情報を保存していたと僕には読めた。また暗号化していないとかそういう意識の低いところも僕が同情を示さないという要因はなったと思う。
あとはシステムの金額と、保守の金額で、その程度はやるべきことだったか？という話かとは思う。
・SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記
・SQLインジェクション対策漏れが重過失認定された判決文を読んだメモ | F's Garage＠fshin2000
上記は、システムに詳しい人の見解？感想？みたいです。
・・・
これだけのお金しかもらってないので、ここまでしか責任持てないという話はあるとは思うのですが、そういう観点でみても、不当かどうかなんですけどね。
SQLインジェクション対策を完璧にするのはなんとなく難しい気がするのですが、
今回の場合、SQLインジェクション対策をしている形跡があったのかどうかも気になります。
何にしろ、今後はまた、こういうことがあったからということで
顧客から見当はずれな要求をされたり
会社から意味なく何回もチェックするようにいわれたり
するようになるのかもしれません。
・・・・
SQLインジェクションで開発業者に有罪判決が出た件「専門家が容易に発見できるバグなら重過失」ってことの前例ならWinnyじゃなくてこっちの高裁判決だろ http://itpro.nikkeibp.co.jp/article/COLUMN/20130802/496224/
2015/01/28 13:28
こういう事例もあるらしい。
バグの発見が容易であれば、重過失
SQLインジェクションは、ソース（机上）で初心者がみても発見できるので、容易といえばそういう感じ。
スポンサーリンク
コメントを残す