忘れられているデータセキュリティ
•
0 gefällt mir•1,086 views
Webアプリケーション開発の現場で忘れられていたり、軽視されているのデータセキュリティです。 攻撃用データを無視する。 壊れたデータ・攻撃用データでも平気で処理し、APIや外部システムのエラーに任せる。 これではプログラムの安全性を保障できません。 プログラムに脆弱性が無い状態をできる限り保証するには、壊れたデータ・攻撃用のデータを丁寧に排除するのが近道です。
Empfohlen
Weitere ähnliche Inhalte
Mehr von Yasuo Ohgaki
忘れられているデータセキュリティ
- 2. プログラムに問題（セキュリティ含む）があった場合 • 大別して２つ問題の可能性があり、問題の種類により理想的な対策が 異なる • 問題が発生した箇所のコードに問題がある • データの妥当性に関係なく発生する問題の場合、問題が発生したコードに近い部分の コードが原因であることが多い • コードロジックやAPIの使い方などが正しくない • 問題発生箇所に近い場所で直すと良い場合が多い • 問題が発生した箇所のデータに問題がある • 入力データの妥当性が原因（出鱈目なデータが原因）で発生する問題の場合、入 力データの処理に問題がある • データバリデーションが漏れていたり、不十分 • データセキュリティを保証すべき箇所、入力処理か上流ロジックを直すと良い場合が 多い 2018/6/25Electronic Service Initiative, Ltd. 2 両方を直す必 要がある場合 も多い
- 3. コードとデータの問題 • 例：pg_query(“SELECT * FROM tbl LIMIT {$_GET[‘limit’]}”); • この書き方では、どんな“SQL文”、“データ”でも記載できる • コードに問題がある場合、そのコードを直す コードに問題 • 例：pg_query_params(‘SELECT* FROM tbl LIMIT $1’, [$_GET[‘limit’]]); • この書き方では、どんな“データ”でも記載できる • データに問題がある場合、そのデータの妥当性を保証する データに問題 2018/6/25Electronic Service Initiative, Ltd. 3 直す方法が 異なる
- 4. コードとデータの問題 • 大抵の場合、問題があるそのコードを直す コードに問題 • 出来る限り上流で、そのデータの妥当性を保証する データに問題 2018/6/25Electronic Service Initiative, Ltd. 4 直す場所が 異なる
- 5. データの問題でプログラムの実行に 支障があっても構わない、とする雑な作りの問題 2018/6/25Electronic Service Initiative, Ltd. 5 • API/外部システムのエラーに頼る設計は脆弱な設計 • エラーは”出来る限り“起きないように設計するモノ • 中途半端な処理の中断は問題の元、攻撃者の玩具 データエラーはどこで起きても良いモノではない • 不正なデータは誤作動・セキュリティ問題の元 • 出鱈目なデータを処理してしまうプログラムは攻撃者の玩具 • 解り易い例は不正な文字エンコーディング 不正なデータを処理してしまうと何をやってもダメまま データエラー は起こさせな いモノ
- 7. データのセキュリティ •プログラムが誤作動する 出鱈目（＝危険）なデータ •プログラムの正常動作に欠かせない 妥当（＝正しい/安全）なデータ 2018/6/25Electronic Service Initiative, Ltd. 7 データセキュリティ に着目した 構造・対策がないと 安全なプログラムは 作れない
- 8. インジェクション攻撃と攻撃されないプログラム • ソフトウェアに対するインジェクション攻撃は“攻撃用データ”で行われる • “攻撃用データ”は無効なデータであることが多い • 自由に記入できるデータには普通は無害化対策が取られている • “攻撃用データ”はプログラムの誤作動（バグ）を狙う インジェクション攻撃 • 無効なデータが利用・保存できてしまう動作・仕様はバグ（誤作動） • 誤作動を防ぐには「正しい（妥当な）データ」と「正しいコード」両方が必須 • データセキュリティはFail Fast原則で対策する • データセキュリティは機能構造内に抽象化すると失敗する（⇐ 抽象化はFail Fastでない） 攻撃されないプログラム 2018/6/25Electronic Service Initiative, Ltd. 8 攻撃者は出鱈目 なデータで攻撃
- 9. コードに問題はないが、データに問題がある例 •厳密にはデータをいい加減に扱うコードの問題だが、このプリペアードクエリを使う コード自体には問題がない •しかし、データ（$_GET[‘limit’]）の値が不正な値（例えば、9999999999）だと困るアプ リケーションは少なくない pg_query_params(‘SELECT* FROM tbl LIMIT $1’, [$_GET[‘limit’]]); 2018/6/25Electronic Service Initiative, Ltd. 9 データの問題が直す方法も場所も異なる。 別の問題として取り扱う方が構造化できる。
- 10. 安全なプログラムの必須要件 2018/6/25Electronic Service Initiative, Ltd. 10 安全なコード 安全なデータ ＝ 正しいコード ＝ 正しい（妥当な）データ 安全なデータは安全なプログラムに欠かせない。 構造化したデータセキュリティ対策が、かなり 多くのWebアプリケーションで“忘れられている”。
- 11. よくある間違い – 出力に出鱈目なデータを許す • 出鱈目なデータに対して何を行ってもダメ。プリペアードクエリは不完全な対策 • 郵便番号に“SQL文”が保存できても正しくない • 不正なデータ保存＝単純にバグ。比較的軽いがセキュリティ問題 • 年齢に“SQL文”を保存しようとしてエラーになっても正しくない • エラーが起きる＝正しくない、プログラムはこういったエラーが出来る限り発生しない構造で作 るモノ。比較的軽いがセキュリティ問題 • 例えば、XMLのXpathクエリならXMLデータを丸ごと盗まれる • データが盗まれる＝致命的なセキュリティ問題 • 例えば、XMLやJSON、配列のデータを改ざんできる • データが改ざんできる＝致命的なセキュリティ問題 2018/6/25Electronic Service Initiative, Ltd. 11 // PHPのPostgreSQLモジュールのプリペアードクエリを使ってデータを挿入 $result = pg_query_params(‘INSERT INTO tbl (var) VALUES ($1)’, [$_GET[‘var’]]); データの安全性 （＝妥当性）を 保証する仕組み が必須
- 13. プログラムの基本構造 2018/6/25Electronic Service Initiative, Ltd. 13 入力データ 出力データ データ処理（ロジック）
- 14. プログラムの基本構造 2018/6/25Electronic Service Initiative, Ltd. 14 入力データ 出力データ データ処理（ロジック） Web環境では攻撃用のデータは 自由自在に挿入可能 出力時に危険な攻撃用データが 挿入されるリスクがある
- 15. 一般的なWebアプリ 2018/6/25Electronic Service Initiative, Ltd. 15 入力データ（ブラウザ） 出力データ（ブラウザ） データ処理 コールグラフ例
- 16. 入力データはプログラム中のどこでも使われる 2018/6/25Electronic Service Initiative, Ltd. 16 コールグラフ例 単純化したコールグラフでも 関数/メソッドの呼び出しは 結構複雑になる しかも、関数/メソッドの呼 ばれ方は入力により異なる （コード実行パスが異なる）
- 17. 一般的なWebアプリ 2018/6/25Electronic Service Initiative, Ltd. 17 入力データ 出力データ データ処理 HTTPヘッダー クッキー入力 クエリ文字列入力 POST入力 入力データはどこで 使われるか分からない 開発者が意識していない ライブラリの中かも知れない HTTPヘッダー クエリ文字列入力 クエリ文字列入力
- 18. 一般的なWebアプリ 2018/6/25Electronic Service Initiative, Ltd. 18 入力データ 出力データ データ処理 HTTPヘッダ入力 クッキー入力 クエリ文字列入力 POST入力 メール出力 DB出力 ログ出力 クエリ文字列入力 クエリ文字列入力 キャッシュ出力 入力データはどこで 使われるか分からない 開発者が意識していない ライブラリの中かも知れ ない
- 19. 機能に合わせてデータセキュリティ対策を行うと バラバラで構造がない対策に • 「構造がない対策」ではセキュアコーディング原則１の 「全ての入力をバリデーションする」 の実施さえ怪しい • データセキュリティ構造がないと 場当たり的なブラックリスト対策 にならざるを得ない ⇒ セキュリティ対策でブラックリスト はNG • バグがないプログラムには 「正しい（妥当）データ」 が欠かせない の前提条件が満たせない 2018/6/25Electronic Service Initiative, Ltd. 19 入力データ 出力データ データ処理 HTTPヘッダ入力 クッキー入力 クエリ文字列入力 POST入力 メール出力 DB出力 ログ出力 クエリ文字列入力 クエリ文字列入力 キャッシュ出力
- 20. 出力時点では「データの妥当性」を保証できない • 「構造的データセキュリティがない対策」ではセキュアコーディング原則７の 「全ての出力を無害化する」 を実施しても「出鱈目なデータ」を利用・出力する • 「出鱈目なデータ」を出力する ようでは「正しく実行」できた とは言えない • 攻撃用の「出鱈目なデータ」 でも出力してしまう 攻撃可能な個所を残してしまう ⇒ 出力コンテクストの中に別の コンテクストがある場合など 2018/6/25Electronic Service Initiative, Ltd. 20 入力データ 出力データ データ処理 HTTPヘッダ入力 クッキー入力 クエリ文字列入力 POST入力 メール出力 DB出力 ログ出力 クエリ文字列入力 クエリ文字列入力 キャッシュ出力
- 21. データセキュリティの概念がないと ソフトウェアのセキュリティは成り立たない • 出力対策だけ、では「その場しのぎのインジェクション対策」 • 無害化しても「出鱈目なデータ」はあらゆる問題の元 • 「その場しのぎのインジェクション対策」では雑なセキュリティ対策 • 攻撃用の出鱈目なデータを別のプログラムに渡す無責任な対策 • 出力用に無害化しても出鱈目なデータ」は出鱈目のまま • データセキュリティを考えたアーキテクチャーが必要 2018/6/25Electronic Service Initiative, Ltd. 21
- 22. 入力の妥当性検証さえない物の例 • Webアプリ入力データの代表 • HTTPヘッダー • クッキー • クエリ文字列 • パス情報 • POSTパラメータ • 入力データ全てを検証していない • 余計なデータがあっても無視している • テキストI/Fなのに、文字種、文字エン コーディングさえ検証していない • 長さ・範囲の検証がない • 検証しているモノでも、不正形式をエラー にしていない • 数を検証しているモノはほぼない 2018/6/25Electronic Service Initiative, Ltd. 22 これら全て バリデーション可能
- 23. セキュアなコード＆データの基礎原則 • 入力処理 • 入力データ形式が正しい • 出力処理 • 出力先の入力データとして正しい ＝出力先を誤作動させない Electronic Service Initiative, Ltd. https://es-i.jp 23 ✓ データの“正しさ”は入力処理の責任 ✓ コンテクストに対して“正しい” （誤作動しない）が出力処理の責任 例：escape($ID)で完全な安全性を 保障 ✓ コンテクストに対して“正しい” ✓ 出力しても“正しい”データのみ 例：IDに“<script>alert(‘xss’) </script>”などの可能性を完全 に排除（無用なリスクを排除） ✓ 呼び出す側が誤作動しない・正しい データを送信する責任を持つ ✓ 誤作動しないデータはエスケープ・ API・バリデーションで保証 2018/6/25 ✓ 外部入力は呼ばれた側がバリデー ションの責任を持つ ✓ 内部的には基本として呼び出し側が 正しいデータ送信の責任を持つ 入力 処理 出力 入力元 出力先 信頼境界線 入力処理では “データ“の正しさを保証 出力処理では ”出力”の正しさを保証
- 24. 改良した構造 2018/6/25Electronic Service Initiative, Ltd. 24 入力データ 出力データ データ処理 HTTPヘッダ入力 クッキー入力 クエリ文字列入力 POST入力 メール出力 DB出力 ログ出力 クエリ文字列入力 クエリ文字列入力 キャッシュ出力 入口の時点で全ての 入力データを一括バリデーション ファイルやDBからの入力が信頼 できない場合、バリデーション が必要 全てのプログラムが 入力データをバリデーション していれば、ファイルやDBの データ形式は信頼可能 出力データの一括無害化は難しいが、 テンプレートシステムなどである程度 は対応可能 データバリデーション処理 入口対策 （信頼境界対策） が必須
- 26. 出鱈目なデータ出力・利用を許す＝脆弱なプログラム • Fail Fast原則違反 • 失敗する物は出来る限り早く失敗させる原則に違反 • セキュアコーディング原則第１原則違反 • 全ての入力をバリデーションする原則 • SoC原則違反 • Separation of Concerns原則違反。入力データ形式の妥当性検証は入力処理 の責任で、入力データの論理的妥当性の検証はビジネスロジックの責任。出力処理に はデータの形式的・論理的な妥当性検証の責任はなく、無害化の責任しか持たない。 • プログラムの動作原理違反 • プログラムは正しいコード＆正しいデータでのみ正しく動作する • そもそも出鱈目なデータを出力できてしまうのはバグ＆セキュリティ問題 2018/6/25Electronic Service Initiative, Ltd. 26 書ききれないので省略 したが、他にも様々な ベストプラクティスや ガイドラインに違反し ている
- 27. データセキュリティの保証は必須のセキュリティ対策 • 出鱈目なデータを出力してしまう構造になっ ているプログラムはNG • 原理・原則に反するセキュリティ対策の場合、 セキュリティ問題が発生し訴訟になった場合、 開発側が著しく不利な状況になる • 訴訟では「みんなやってない」「顧客からの要 求仕様に含まれていない」などは恐らく通用 しない • セキュリティ専門家はデータの妥当性検証を 30年くらい前から必要だと啓蒙している 2018/6/25Electronic Service Initiative, Ltd. 27 データを丁寧に扱う 丁寧なデータバリデー ションによるデータセ キュリティが必須
- 28. 全ての入力データをバリデーションする • より正確には、全ての“信頼できない”入力 データをバリデーションする • “信頼できる”入力データならバリデーションを 省略可能 ※参考：契約プログラミング • “ソフトウェアの信頼境界を越える入力データ 全て”が対象 • システム（プログラム、ネットワーク・通信、モ ノ）の“境界防御で改ざんを防げる”場合、 “信頼できる範囲”で信頼しバリデーションを省 略可能 2018/6/25Electronic Service Initiative, Ltd. 28 “信頼できる”は常に“条 件付きの信頼”である こと、注意する 全てのデータは 信頼可能できなければ ならない
- 29. ソフトウェアは「不正な入力を拒否」 するように設計しなければならない 不正な 入力値 入力ミスの 入力値 正しい 入力値 2018/6/25Electronic Service Initiative, Ltd. https://es-i.jp 29 入力バリデーション エラーの入力値は 「拒否すべき入力」 仕様上、あり得ない入力 入力ミスの入力値は 「受け入れるべき入力」 仕様上、あり得る入力 入力値には右の三種類しかない 入力バリデーションエラーと 入力ミスエラーの違いは明白 だが、区別ができないケース も時々見かけるので注意！ Fail Fastの原則に従い、不正な 入力値は可能な限り早く検出・ 拒否しなければならない プログラムは正しい（妥当な） データでしか正しく動作しない
- 30. ただし、データバリデーションには３種類がある 2018/6/25Electronic Service Initiative, Ltd. 30 入力データ 出力データ データ処理（ロジック） 入力データバリデーション データの形式的検証 論理的データバリデーション データの論理的・仕様的検証 出力データバリデーション データの無害化保証
- 31. データは丁寧に扱う Webアプリサーバーの入力バリデーション • 全ての入力を検証 • 全てのクエリ文字列のパラメーター名とパラメー ター値、パラメーター数 • 全てのHTTPヘッダーのパラメーター名とパラメー ター値、パラメーター数 • CookieもHTTPヘッダー値の一つ • 全てのPOSTのパラメーター名とパラメーター値、 パラメーター数 • パラメーター名は出来る限り厳格に検証 • 厳格に完全一致検証できる物は厳格に検証 • 完全一致検証できない物は、利用文字および 文字数をできる限り厳しく検証 • パラメーター値は出来る限り厳格に検証 • 数値なら数値であることの検証と範囲検証 • 文字列な長さの範囲、特定形式との一致、文 字エンコーディング、利用文字種 • パラメーター数の検証も必須 • 攻撃者は余計なパラメーターを無視する仕様も 攻撃に利用する • 全てのバリデーションエラーを拒否 • 論理的整合性の検証はビジネスロジックの責任 • 入力ミスの検証と対応はビジネスロジックの責任 • ブラウザ以外からの入力も検証 • データ検証済みでない場合は検証が必須 2018/6/25Electronic Service Initiative, Ltd. 31
- 32. データは丁寧に扱う アプリケーションのビジネスロジックでのバリデーション • 単純に拒否できる検証は含めない • 単純にバリデーションエラーで拒否できるモノは入 力処理のバリデーションでも行える • 入力処理のバリデーションで拒否できる入力デー タは「攻撃」として処理できる入力 • 論理的な整合性検証 • 入力データの整合性 – データセットがビジネス ロジックに適合しているか？ • 有効期限/存在/権限などの検証など • 入力ミスの検証 • アプリケーション仕様上あり得る入力ミスは「妥当 な入力データ」 • 入力処理では「正しいデータ」 • ビジネスロジックでの入力データバリデーショ ンで“例外”が発生する場合、設計上に 何らかの問題がある • 基本、インタラクティブに対応するバリデーションエ ラーしか発生しないはず • ビジネスロジックでもサニタイズ（データを 加工して処理できる形に変換）は禁止 • 正規化はサニタイズではないが、正規化が必要 な場合は入力データ処理で正規化すべき • 正規化やその他の変換はデータバリデーションの 前に行う必要がある 2018/6/25Electronic Service Initiative, Ltd. 32
- 33. データは丁寧に扱う アプリケーションの出力処理でのバリデーション • 出力処理の目的・役割は出力データの完 全な無害化 • 基本はエスケープ/エンコードにより無害化 • 無害化して出力可能なAPIがある場合、APIを 利用 • バリデーションはフェイルセーフ。バリデーションエ ラーは“例外”を投げる • 出力処理時のバリデーションエラーは基 本発生しない構造が必要 • 例：SQL識別子を英数字でバリデーションして、 エラーになるのはプログラムのバグ • 基本、出力データをバリデーションしてもエラーには ならないハズだから、とバリデーションを省略しない • 出力処理は「完全」（＝確実）に無害なデータ のみが出力される事を保証する責任を持つ • 出力データの「完全な無害化」には出力コンテ クストの理解が欠かせない • 出力データが複数のコンテクストで解釈されるケースは 少なくない • 例：RDBMSのXML型、JSON型、正規表現、 LIKEクエリのSQLパラメーター • ただし、出力時点ではデータの論理的正しさの検証責 任はない。これはビジネスロジックの責任として、ビジネ スロジックが確実に検証する • 複数コンテクストで解釈されるデータの無害 化 • この種のデータはどのコンテクストで解釈されても無害 である形にエンコード/エスケープまたはバリデーション • 例：HTML中のJavaScript文字列データを出力す る場合、英数字を含めUnicode形式でエンコード 2018/6/25Electronic Service Initiative, Ltd. 33
- 35. 信頼できる ≠ 全面的に信頼できる • バリデーション済みのデータでも“信頼できる”には“条件”がある • “全面的に信頼できる”と勘違いすると大問題 • “信頼できる”ので、そのままビジネスロジックで使っても大丈夫 ⇒ NG • 入力処理のバリデーションは“形式的”検証の責任しか持たない • “信頼できる”ので、そのまま出力しても大丈夫 ⇒ NG • 出力処理はそれ以前の処理でのデータバリデーションとは独立（無関係）に出力の無害化 を行う（必須セキュリティ対策＋フェイルセーフ対策） • バリデーション済みのデータでも“どこまで信頼できるのか？”を意識 2018/6/25Electronic Service Initiative, Ltd. 35
- 36. 信頼できるデータ ≠ 安全なデータ 2018/6/25Electronic Service Initiative, Ltd. 36 信頼できる データ 安全に利用できる データ 入力値として信頼できるデータでも、 出力・利用時に安全に出力・利用できるデータとは限らない。 安全性は“出力・利用先のコンテクスト”に依存する。
- 37. “信頼できる”入力データには“条件”がある • アプリケーションの入力処理は基本的に形式的なバリデーションしか行わない • “形式的な正しさ”は“信頼できる” • “論理的な正しさ”は“信頼できない” • ビジネスロジックの入力データバリデーションは論理的なバリデーションを行う • 入力処理で“データ形式のバリデーション”は済んでいる場合、“形式的な正しさ”は信頼し て構わない ⇒ 形式のバリデーションは省略可能 • 下流のビジネスロジックは上流で“論理的な正しさ”がバリデーションされている場合、入力 データの“論理的な正しさ”を信頼して構わない ⇒ 論理的整合性のバリデーションも省略 可能 • 出力処理の時点では“形式的”にも“論理的”にも信頼できるデータにする • “形式的”にも“論理的”にも信頼できるデータであっても、出力先で誤作動しないデータで ある保証がない場合がある • 実用的なプログラムは複雑。“形式的”、“論理的”バリデーションが実施済みでも、バグ による最悪の事態（インジェクション）を防ぐ為、フェイルセーフ対策として“全ての出力 データを無害化”する方が良い 2018/6/25Electronic Service Initiative, Ltd. 37
- 38. ソフトウェア信頼境界とデータセキュリティ • ソフトウェア信頼境界を越えたデータは基本的に信頼できない • 例：ユーザーのブラウザから送信されたはずのデータも信頼できない • ソフトウェア信頼境界の限界は同じプロセス/スレッド上で動作するコードまで • しかし、ソフトウェア信頼境界を越えたデータにも“信頼できる範囲”がある • 正しくブラウザがデータを出力したなら、ブラウザからのデータは • 規定の形式のデータだけを送ってくるはず • 規定の形式以外の不正なデータは全て機械的に排除できる • 暗号を用いてブラウザ側で改ざんができないデータであることを保証しているなら、ソフト ウェア信頼境界を越えたデータであっても信頼できる（ただし、再生攻撃に注意！） 2018/6/25Electronic Service Initiative, Ltd. 38
- 40. 安全性が高いアーキテクチャー データバリデーションを出来る限り上流で対応する 2018/6/25Electronic Service Initiative, Ltd. 40 入力データ（ブラウザ） 出力データ（ブラウザ） データ処理 コールグラフ例 Webアプリサーバーの 入力処理でデータバリデーション ブラウザ上でも データバリデーション ビジネスロジックでも早く データバリデーション 出力処理でも データバリデーション ただし、出力処理は 出力の無害化が本来の責任 出力時のバリデーションエラーの 大半は設計・構造上の問題
- 41. 安全でないプログラムのアーキテクチャー データのセキュリティ確保を下流に任せる構造 2018/6/25Electronic Service Initiative, Ltd. 41 入力データ（ブラウザ） 出力データ（ブラウザ） データ処理 コールグラフ例 入力処理でデータ検証をせず 出鱈目なデータでも受け入れ ブラウザ上の データ検証なし ビジネスロジックで遅く データ＆形式検証もなし 出力処理での データ検証なし 出鱈目なデータが出力される
- 42. 信頼境界外でのデータバリデーション • ソフトウェアの信頼境界は最大でも同一プロセス/スレッドで動作するコード まで • 信頼境界を越える場合、データバリデーションが必要 • しかし、信頼境界外のソフトウェア（ブラウザ）によるデータバリデーションも 有用 • サーバー側（Webアプリサーバー）はブラウザ側でバリデーションし妥当性 を保証したデータ以外を全て単純に無効なデータとして拒否できる • ブラウザで年齢の入力値を０～150でバリデーション • サーバーは年齢が0～150の入力データだけ受け入れ、他は全て攻撃として拒否 2018/6/25Electronic Service Initiative, Ltd. 42
- 43. 安全なプログラムの必須要件 2018/6/25Electronic Service Initiative, Ltd. 43 安全なコード 安全なデータ ＝ 正しいコード ＝ 正しい（妥当な）データ “コード”と“データ”の両方を丁寧に扱うプログラム が安全なプログラム
- 44. 安全なプログラムの要件 2018/6/25Electronic Service Initiative, Ltd. 44 安全なコード 安全なデータ 適切な機能の抽象化 適切なデータの検証 “コード”：機能を安全に抽象化し実装 （機能の複雑性を内部・下流に閉じ込める） “データ”：データの安全性を早く検証 （データの正しさ・妥当性検証を外部・上流で対応） データの安全性を 内部に抽象化する、 は機能しない
- 45. • 基本アーキテクチャーはアプリケーション、モジュール、関数・メソッド、粒度に 関わらず共通 セキュアなコードとデータのソフトウェア構造 2018/6/25Electronic Service Initiative, Ltd. https://es-i.jp 45 入力 （HTML/JavaScript/JSON/データベース/OS/WebAPIなど） 入力処理 ロジック処理 出力処理 出力 （HTML/JavaScript/JSON/データベース/OS/WebAPIなど） アプリケーション 入力処理 ロジック処理 出力処理 入力処理 ロジック処理 出力処理 モジュール 関数・メソッド 各レイヤーの 境界防御 がデータ防御の基本 ✓ アプリケーションレベル の境界防御が特に重要 ✓ データは基本的に全て信 頼できない。アプリレベ ルで完全に入力バリデー ションすれば、形式の妥 当性を保証可能
- 47. データセキュリティの基本 データセキュリティ ≒ データの妥当性検証 • 出来る限り上流で保証する • 下流で局所化・抽象化はバグの原因 • 検証の前に必要なデコード・正規化を終わら せる • 検証の事前条件 • ホワイトリスト型で検証する • ブラックリストは脆弱で危険な方法 • ソフトウェアの信頼境界で検証する • ソフトウェアの信頼境界の限界は「同一プロセス/ス レッド上のコードまで」 • ソフトウェアの信頼境界を越える度に再検証 が必要 • 再検証は多層防御。無駄ではなく、下流の検証 精度を向上できる。 • 検証済みの信頼できるデータには“条件”があ る • 検証済みの内容により信頼可能な範囲が変わる • 出力・利用時の安全性を保障するモノではな い • データ検証は「入力処理」であり、「出力処理」の安 全性確保の機能・責任はない • 形式的検証と論理的検証は別の検証 • 「入力処理」と「ロジック処理」の責任は異なる • 出力時のデータ検証はフェイルセーフ対策 • この時点での検証エラーはバグ • 出力時の検証エラーは下流過ぎて、補助的セキュリ ティ対策でしかない • 出力した結果、出力先でエラーになるのも同じ 2018/6/25Electronic Service Initiative, Ltd. 47
- 48. 2018/6/25Electronic Service Initiative, Ltd. 48 よくある間違い・勘違い データの安全性はソフトウェアの機能構造の 中に抽象化すればよい
- 49. 2018/6/25Electronic Service Initiative, Ltd. 49 データの安全性はFail Fast原則に従って 保証しないと機能しない
- 50. 2018/6/25Electronic Service Initiative, Ltd. 50 構造的データセキュリティ対策は セキュリティ対策の基礎の基礎 構造的データセキュリティ対策がないアプリケーションは 設計から脆弱なアプリケーション
- 51. 2018/6/25Electronic Service Initiative, Ltd. 51 CERT セキュアコーディング原則 第1位 入力をバリデーションする