入力処理と出力処理はプログラムの基本処理です。当たり前の処理ですが、Webアプリケーションでは基本的な事が知られているようで知られてないと思います。
入力処理と出力処理の両方ともがデータに対する責任を持っています。データに対する責任といっても、その責任は異なります。このエントリはプログラムの基本機能、入力処理/ロジック処理/出力処理が持っている責任を紹介します。
脆弱性がないプログラムを作るには、コードからの視点、データからの視点、両方が必要です。ソフトウェアセキュリティの専門家は両方の視点からのセキュリティ対策を啓蒙しているのですが、上手く伝わっていないです。
このエントリはデータからの視点で見たデータセキュリティの話です。
ソフトウェアのセキュリティ問題の多くは「ソフトウェアの誤作動」です。つまり、正しく動作するソフトウェアならセキュリティ問題の大半は発生しません。1
コンピュータープログラムが正しく動作するには「正しいコード」と「正しいデータ」の両方揃う事が必須条件です。これはプログラムの動作原理に基づく条件なので、誰にも変えることは出来ません。
ビルドを繰り返して時間があったので、ついついとても長いデータの話を書いてしまいました。今さら聞けない「コード（機能）」と「データ」の話として、もっと単純化してみます。
当然の話なのですが、現実には当たり前ではなかったりします。
「データ」のセキュリティを考慮しないセキュリティ対策はあり得ないのですが、多くのプログラムは「コード（機能）」のセキュリティに偏重した構造と対策になっています。
安全なプログラムの作成には「コード（機能）」と「データ」のセキュリティを分けて考える必要があります。
プログラムを作っているとOSコマンドを実行したくなる時があります。OSコマンドの実行に問題があり、不正なコマンドをインジェクションされると大変な事になります。
どのようなセキュリティガイドラインでも「OSコマンドの実行に注意する」と大抵書かれています。
多くの場合、「コマンド実行時、コマンドと引数を分離すれば安全に実行できるAPIを利用すれば安全に実行できる」としています。
この記述は間違ってはいないです。しかし、正しくは
です。
コマンドと引数を分離するAPI利用だけでは完璧とは言えないセキュリティ対策です。
まず結論から。タイトルの通り「出力対策だけのセキュリティ設計は設計ミス」です。
なぜ「出力対策だけのセキュリティ設計は設計ミス」なのか？
全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション１つとっても本当に完全であるか？検証することは容易ではありません。プログラムが本当に思っているように動作するのか？検証する研究は、まだまだ研究段階です。
しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。
ITシステム開発者必修のセキュリティ概念 Top 10です。ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。順序はその基礎知識性、重要性、分かり易さで付けています。
では開発者必修のセキュリティ概念 Top 10です。
※ 長くなったので短い版を作りました。ロング版はこちら
ITシステム開発者必修のセキュリティ概念 Top 10です。さっと考えたので変更するかも知れません。これらの考え方や概念を理解していないと、ITセキュリティ標準やガイドラインなどで要求されているセキュアプログラミング／セキュアコーディングを効率的かつ効果的に利用することはできないでしょう。
ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。
順序はその基礎知識性、重要性、分かり易さで付けています。では開発者必修のセキュリティ概念 Top 10です。
参考：思いの外、長くなったのでショート版を作りました。
第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。
関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。
PDFはこちらからダウンロードできます。
勉強会で使ったスライドは、面白おかしく柔らかい（？）スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。
プログラム・コードが正しく動作する為の必要条件と十分条件を考えたことがあるでしょうか？
プログラム・コードが正しく動作する為の必要条件と十分条件とは何でしょうか？
コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。
今回はセキュリティ対策におけるAPIとエスケープ/バリデーションをどう考えるかの話です。
Cプログラマになろうとしているプログラマにメモリ管理を教えないことは考えられません。メモリ管理を考えなくても文字列の処理をしたりするライブラリなどもありますが、メモリ管理をあまり考えなくても良いAPIさえ使っていればOK、メモリリークもValgrindでチェックしてレポートされなければOK、と考えているプログラマが作ったプログラムが安全である可能性は低いでしょう。
言語やプラットフォームの基本中の基本を避けて通っては安全なプログラムの構築が難しくなるだけです。
安全なプログラムを作るために「プログラマに何を教えるべきか？」が今日のテーマです。
出力先のシステムが同じでも、出力先が異なる場合はよくあります。これを意識していないとセキュリティ問題の原因になります。
もっと読む
少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。
契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
もっと読む