ソフトウェアに入力バリデーションは必要ない 〜 ただし条件付きで
「ソフトウェアには入力バリデーションは必要ない」そんな事がある訳けないだろう？！いつも言っている事と真逆でしょ？！と思うでしょう。
しかし、「入力バリデーションが必要ないソフトウェア（＝コード）」は沢山あります、条件付きですが。
もっと読むデータフロー分析とセキュリティ
データフロー分析とはコールフローグラフ（CFG）を使ってプログラムを分析する手法です。ソフトウェアのセキュリティ対策にもデータフロー分析は広く利用されています。例えば、静的ソースコード検査ツールは静的（＝プログラムを動作させず）にプログラム実行時のデータフローを分析し、問題を発見する手法です。
コールフローグラフ
データフロー分析の基礎知識はハーバード大学コンピューターサイエンス学科の講義資料（PDF）が参考になります。こちらを参考にしてください。英語の資料ですが容易な内容です。
もっと読むゼロトラストとフェイルファースト
今のプログラムに足りないモノでセキュリティ向上に最も役立つ考え方のトップ2つ挙げなさない、と言われたらどの概念／原則を挙げるでしょうか？
私なら
- ゼロトラスト
- フェイルファースト
を挙げます。
極論すると、この2つ知って実践するだけでセキュアなソフトウェアを作れるようになるからです。この2つだけでは十分ではないですが、これを知って、実践しているだけでも開発者は今のコードより段違いにセキュアなコードが自分で書けるようになります。
もう一つ追加するなら
- 多層防御（縦深防御）
を加えます。これはゼロトラストとフェイルファーストから導き出せる概念です。ゼロトラストとフェイルファーストで検証を行うと自然と多層防御になります。多層防御はセキュリティ対策の基本ですが、特にソフトウェアでは実践されている、とは言えない状況です。
これら3つはとても有用な概念で単純明解な概念ですが、知られていなかったり、誤解されていたりすることが多い概念／原則と言えるかも知れません。
もっと読むNHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ
NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。
ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。
- Androidの設定から「提供元不明のアプリ」のチェックボックスをオンにしてはならない、必ずオフにする、の説明が無かった。
- セキュリティベンダー広報担当者の説明を長々と回りく引用し説明に終始し、インストールしないことが大事であるのに、インストールしてしまった場合の症状や攻撃手法を羅列した。
- 「見覚えのないアプリは速やかに削除すること。そして、自分がどんなアカウントを利用していたかを確認し、パスワードを変更したり、企業に相談したりするなどしてほしい」などど、そもそもインストールしない、怪しいアプリをインストールできないようにする、の説明がなかった。
要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、
▽セキュリティー対策ソフトを入れる。
などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。
NHKが紹介した対策ページではスクリーンショット等も交えながら
▽アプリは公式アプリストアからのみダウンロードする。
としているのに、「提供元不明のアプリ」（Android 8ではアプリごとの「不明なアプリ」）のチェックボックスをオフにする、を説明しないのは何事だ！という事です。
確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。
このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」（公開していません）の導入部分に追加したスライドを紹介します。
とあるネットワーク技術者の防御法
今回は「とあるネットワーク技術者がいかにしてネットワークシステムのセキュリティを守っているのか？」という話です。
「え？！」と思うハズですが、最後までお読みください。
正しく動作するソフトウェアの作り方
ソフトウェアを開発している時に困るのは、ソフトウェアが正しく動作しないケース、に対応する事です。
実用的なソフトウェア作るよりもプロトタイプを作る方が簡単であるのは、ソフトウェアが正しく動作しないケース、に対応する必要がないことが大きな理由です。ソフトウェアが正しく動作しないケースに対応するには、様々な例外的な状態（入力データとソフトウェアの内部状態）全てに対応する必要があります。
例外的な状態を定義するには”ダメな状態”を定義する必要があります。”ダメな状態”を漏れ無く定義するのは結構大変です。ソフトウェアバグの多くは”ダメな状態”を漏れ無く定義することに失敗した為に生まれています。
参考：データセキュリティの概念がないと「正しく動作するプログラム」は作れない。
知っておくべきITセキュリティ概念Top 10 〜ショート版〜
ITシステム開発者必修のセキュリティ概念 Top 10です。ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。順序はその基礎知識性、重要性、分かり易さで付けています。
では開発者必修のセキュリティ概念 Top 10です。
※ 長くなったので短い版を作りました。ロング版はこちら
当たり前？非常識？開発者必修のセキュリティ概念 Top 10
ITシステム開発者必修のセキュリティ概念 Top 10です。さっと考えたので変更するかも知れません。これらの考え方や概念を理解していないと、ITセキュリティ標準やガイドラインなどで要求されているセキュアプログラミング／セキュアコーディングを効率的かつ効果的に利用することはできないでしょう。
ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。
順序はその基礎知識性、重要性、分かり易さで付けています。では開発者必修のセキュリティ概念 Top 10です。
参考：思いの外、長くなったのでショート版を作りました。
信頼境界線の引き方と防り方 – セキュリティの構造と設計
信頼境界線（Trust Boundary）と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」（≒効率的なセキュリティ対策）ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。
このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方（≒セキュリティ構造/設計）、ついて紹介します。かなり長いエントリになりましたがお付き合いください。
セキュアプログラミングの７つ習慣
セキュアなプログラミングには基本的な考え方があります。それ守ることによりセキュアなプログラムを作ることができます。基本的な考え方を無視または意識しないでセキュアなプログラミングを目指しても遠回りだったり、漏れが生まれたりします。基本的な考え方を無視・意識しないでセキュアなプログラミングを行おうとしても無理があります。
ここで紹介するのは私の考えであり、どこかで標準化されている物ではありません。しかし、基礎からまとめると概ね同じような物になると思います。
個々の脆弱性に対応する効果的な方法
全体的なセキュリティ対策やセキュリティ対策の基本的概念の話が続いたので、個々の脆弱性に対応するための効果的な方法を紹介します。前提知識なく、個々の脆弱性に対応するには、個々の脆弱性全て知る必要があります。
ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション 〜 ただし出力対策も必須です 〜
入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか？を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか？
ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。
厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。
重要：セキュア／防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。どちらかをすれば良い、ではなく入力と出力の両方で対策を行います。よく誤解されるので注意してください。
重要 その2：ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。ホワイトリストによる入力バリデーションは”無害化”ではありません。”妥当性の検証”です。
重要 その3：あまり広く理解されていませんが、セキュアコーディングの第1原則は「全ての入力をバリデーションする」、第7原則が「全ての出力を（エスケープ／API／バリデーションで）無害化する」です。セキュアコーディングはISMS／PCI DSSなどの認証規格の要求事項です。
なぜこのようなブログを書いたか？というと入力バリデーションしていても、”ほぼ全てのインジェクション攻撃を無効化／防止できる入力バリデーション”でない場合、入力時のセキュリティ処理だけでは”残存リスク”としてインジェクション攻撃が可能になる、という事を理解して欲しいからです。
参考：
攻撃者が”嫌う”セキュリティ対策とは何か？
「攻撃者が”嫌う”セキュリティ対策＝効果的なセキュリティ対策」です。これに異論は無いと思います。
攻撃者が最も困るセキュリティ対策とは何でしょうか？それは境界防御です。なぜ境界防御が攻撃者が最も困るセキュリティ対策なのでしょうか？それはCWEやCVEを見ればわかります。CWEやCVEに登録されている脆弱性の多くが、境界防御で守れるからです。
エンジニア必須の概念 – 契約による設計と信頼境界線
少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。
契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
もっと読む