PHPカンファレンス2014セキュリティ対談資料
•
36 likes•7,530 views
「ウェブエンジニアが必要なセキュリティとは」の対談セッション時の資料として用意したスライドです。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to PHPカンファレンス2014セキュリティ対談資料
Similar to PHPカンファレンス2014セキュリティ対談資料 (20)
More from Yasuo Ohgaki
PHPカンファレンス2014セキュリティ対談資料
- 1. PHPカンファレンス2014 セキュリティ対談 エレクトロニック・サービス・イニチアチブ有限会社 http://www.es-i.jp/ 2014/10/11 PHPカンファレンス2014 1
- 2. 自己紹介 •氏名：大垣靖男 •エレクトロニック・サービス・イニシアティブ有限会社代表取 締役社長 •社団法人PHP技術者認定機構顧問理事 •その他–BOSSCONJAPANPHPセキュリティアライアンスCTO、 PostgreSQLユーザー会、PHPプロジェクトコミッター、岡山大 学大学院非常勤講師など •著作：はじめてのPHP言語プログラミング、PHPポケット リファレンス、Webアプリセキュリティ対策入門など •Twitter/Facebook：yohgaki •メール：yohgaki@ohgaki.net •ブログ：http://blog.ohgaki.net/ 2014/10/11 PHPカンファレンス2014 2
- 3. 注意事項 •このスライドはPHPカンファレンス2014での徳丸氏 との対談セッションの資料用に作成しています。講 演用の資料ではありません。 2014/10/11 PHPカンファレンス2014 3
- 4. ウェブエンジニアが必要な セキュリティスキルとは？ 2014/10/11 PHPカンファレンス2014 4
- 6. 情報セキュリティ対策 の概念・基礎知識 2014/10/11 PHPカンファレンス2014 6
- 7. 概念・基礎知識が 無ければ破綻は必然 2014/10/11 PHPカンファレンス2014 7
- 8. 基礎をしないで ビルを建てるに等しい 2014/10/11 PHPカンファレンス2014 8
- 9. セキュリティ対策とは何か？ •守るべき物に対するリスクの緩和策・管理策 セキュリティ対策≠ リスクの排除 セキュリティ対策= リスク管理策、リスク緩和策 •特定・限定したリスク排除は可能だが、 ITを使うリスク自体の排除は不可能 •セキュリティ対策の評価は「費用」と「効果」で判断 •費用は直接的な金銭的コストのみではない •効果は必ずしも定量評価できるものではない 2014/10/11 PHPカンファレンス2014 9
- 10. ITセキュリティ対策の 目的は 「全体最適化」 2014/10/11 PHPカンファレンス2014 10
- 11. 完全でなくても 非常に効果的な 対策はある 2014/10/11 PHPカンファレンス2014 11
- 12. 全体として許容可能な リスクにまで 低減できればOK 2014/10/11 PHPカンファレンス2014 12
- 13. 例えば、オフィスビルの安全 •何を何から守るのか •現金？貴重品？情報？ •事故？窃盗？災害？テロ？ •用途は •不特定多数が利用？特定利用者が利用？ •どんな対策を行うか •まず、不審者の侵入を防止（入口チェック） •次に、退出者の持ち出しを防止（出口チェック） •キャビネット施錠なども重要だが、まず全体の対策 2014/10/11 PHPカンファレンス2014 13
- 14. ウェブアプリの安全 •守る物 •データ、プログラム •WebアプリケーションのセキュリティのCIA •アプリが不特定多数・特定多数かは重要ではない •データが重要 •ほぼ全てデータは何らかの形式を持っている •発見される脆弱性の多くが「インジェクション」脆弱性 •最も重要な対策は •ビルと同様に「入口」と「出口」チェック •データ入力と出力の確実な制御 2014/10/11 PHPカンファレンス2014 14
- 15. 2014/10/11 PHPカンファレンス2014 15 ビル 情報 自社社員 協力会社 運送会社 ビル管理 会社 清掃会社 顧客 ビジター 犯罪者
- 16. 2014/10/11 PHPカンファレンス2014 16 Webアプリ 情報 管理者 開発者 FW ライブラリ OS データ ベース ユーザー ビジター 犯罪者
- 17. セキュリティ対策基礎の基礎 •境界防御（BorderDefense）と 縦深防御（DefenseinDepth)は基本中の基本 •ソフトウェアでは多重防護、多層防御などと呼ばれるこ とが多い •基本は境界防御で境界を守る。ただし境界防御が できない場合、失敗した場合に備えて縦深防御 •侵入を許す縦深防御は最初に選択する防衛策ではな い •基本は境界防御–信頼境界線を守る 2014/10/11 PHPカンファレンス2014 17
- 18. 2014/10/11 PHPカンファレンス2014 18 Webアプリ 情報 管理者 開発者 FW ライブラリ OS データ ベース ユーザー ビジター 犯罪者 信頼境界線 自分のコード以外の“もの”を 信頼境界線の中に入れるに は“安全性の担保”が必要 “安全性の担保”が可能な“も の”は信頼境界線の中に入れ ることも可能
- 20. 2014/10/11 PHPカンファレンス2014 20 Webアプリ 情報 HTML/CSS FW/API OSコマンド パス SQL/Xpath/ LDAP/etc JavaScript GET/POST/HEADER Web サービス 信頼境界線 信頼境界線を越える“もの”は “安全性の担保”が必要 つまり、入出力制御 これらはテキストI/Fでエスケープ・バリデーションは必須
- 21. CWE/SANSTOP25MonsterMitigation ID Name M1 Establish and maintain control over all of your inputs. M2 Establish and maintain control over all of your outputs. M3 Lock down your environment. M4 Assume that external components can be subverted, and your code can be read by anyone. M5 Use industry-accepted security features instead of inventing your own. GP1 (general)Use libraries and frameworks that make it easier to avoid introducing weaknesses. GP2 (general)Integrate security into the entire software development lifecycle. GP3 (general)Use a broad mix of methods to comprehensively find and prevent weaknesses. GP4 (general)Allow locked-down clients to interact with your software. 2014/10/11 PHPカンファレンス2014 21 最も重要な セキュリティ対策TOP5 怪物的なセキュリティ対策 （緩和策）
- 22. トップ５の情報セキュリティ対策 1.入力の制御（バリデーション） 2.出力の制御（エスケープ、セキュアAPI、バリデーション） 3.環境のロックダウン •制限的な環境・制約 •問題発生時のロック 4.外部コンポーネントは信頼しない、自分のコードは読ま れることを前提とする 5.独自実装せず業界標準のセキュリティ機能を利用する 2014/10/11 PHPカンファレンス2014 22
- 23. エスケープ バリデーション 不要論？ 2014/10/11 PHPカンファレンス2014 23
- 24. エスケープ バリデーション を無くすには 2014/10/11 PHPカンファレンス2014 24
- 25. エスケープ バリデーション が完全に不必要な 環境が必要 2014/10/11 PHPカンファレンス2014 25
- 26. 完全に不必要な 環境でない場合 不要論は リスク増大要因 2014/10/11 PHPカンファレンス2014 26
- 27. ソフトウェアと境界防御 •最近開発された言語は “契約プログラミング/契約による設計”をサポート •契約プログラミングの基本 •呼び出し側が呼び出される側の契約を守る •契約プログラミングでは、最低限アプリケーション の「入力のバリデーション/エラーチェック」を行う 2014/10/11 PHPカンファレンス2014 27
- 28. 今までの構造 構造化プログラミング 2014/10/11 PHPカンファレンス2014 28
- 29. 2014/10/11 PHPカンファレンス2014 29 入力 入力 入力 入力 入力 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 構造化プログラ ミングでは低い レイヤーで処理 をまとめる
- 30. 2014/10/11 PHPカンファレンス2014 30 入力 入力 入力 入力 入力 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 構造化プログラ ミングでは処理 をまとめる 安全な処理をし ていない場合、 攻撃可能に
- 31. 契約プログラミング 契約のよる設計 の構造 2014/10/11 PHPカンファレンス2014 31
- 32. 2014/10/11 PHPカンファレンス2014 32 入力 入力 入力 入力 入力 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 契約プログラミン グでは入力が契 約を守っている か入出力で確認 万が一セキュリ ティ処理がなくて も安全になること が多い 信頼境界線 ここで追加のセキュリティ確認も勿論OK。縦深防御（多重のセキュリティ・多層防御）
- 33. 2014/10/11 PHPカンファレンス2014 33 入力 入力 入力 入力 入力 入力処理 入力処理 入力処理 入力処理 入力処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 出力処理 出力処理 出力処理 出力処理 信頼境界線 出力 出力 出力 出力 出力 信頼境界線 出力処理 多くのリスクを緩和 するセキュアな アーキテクチャ
- 34. 入出力の安全性を担保 しない場合 どこで危険となるか判 別が困難になる 2014/10/11 PHPカンファレンス2014 34
- 35. 2014/10/11 PHPカンファレンス2014 35 入力 入力 入力 入力 入力 入力処理 入力処理 入力処理 入力処理 入力処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 出力処理 出力処理 出力処理 出力処理 信頼境界線 出力 出力 出力 出力 出力 信頼境界線 出力処理 実行パスにより地 雷を踏んでしまう
- 36. セキュアな入出力制御で 対策・緩和できる脆弱性 入力 出力 CWE HighCWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Mod HighCWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Mod HighCWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Mod HighCWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') ModCWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') ModCWE-131: Incorrect Calculation of Buffer Size HighCWE-134: Uncontrolled Format String ModCWE-190: Integer Overflow or Wraparound ModCWE-434: Unrestricted Upload of File with Dangerous Type Mod ModCWE-601: URL Redirection to Untrusted Site ('Open Redirect') Mod HighCWE-676: Use of Potentially Dangerous Function LtdCWE-732: Incorrect Permission Assignment for Critical Resource ModCWE-807: Reliance on Untrusted Inputs in a Security Decision HighCWE-829: Inclusion of Functionality from Untrusted Control Sphere DiDCWE-862: Missing Authorization 2014/10/11 PHPカンファレンス2014 36
- 37. 「入力」「出力」を確実にす るだけで8割9割の 脆弱性を防止・緩和可能 2014/10/11 PHPカンファレンス2014 37
- 38. 2014/10/11 PHPカンファレンス2014 38 入力 入力 入力 入力 入力 入力処理 入力処理 入力処理 入力処理 入力処理 処理 処理 処理 処理 処理 処理 処理 処理 処理 出力処理 出力処理 出力処理 出力処理 信頼境界線 出力 出力 出力 出力 出力 信頼境界線 出力処理 出力処理に問題が あっても 出力処理に問題が あっても、結果的に安 全である場合も多い 途中の処理に問題 があっても
- 39. アプリの入力・出力の 安全性確保は セキュアアプリの 土台・基礎 2014/10/11 PHPカンファレンス2014 39
- 41. 契約プログラミング 契約による設計でも 2014/10/11 PHPカンファレンス2014 41 多層防御は必要！
- 42. セキュアなプログラムの基本構造 2014/10/11 PHPカンファレンス2014 42 入力ソース 入力処理 ロジック処理 出力処理 出力 バリデーションで 攻撃可能範囲を 限定・緩和 出力で完全に安全 にできるデータは 完全に安全に エスケープ、セキュアAPI、 バリデーションで 攻撃可能範囲を限定・緩和 ロジックでも必要な セキュリティ対策は 行う 多層防御
- 43. 普通のアプリは単純な 「入力→処理→出力」 ではない 2014/10/11 PHPカンファレンス2014 43
- 44. セキュアなプログラムの基本構造 2014/10/11 PHPカンファレンス2014 44 入力ソース 入力処理 ロジック処理 出力処理 出力 SQLクエリ 入力ソース 入力処理 ロジック処理 出力処理 出力 クエリ結果 WebAPI 入力ソース 入力処理 ロジック処理 出力処理 出力 API結果 HTML リクエスト
- 45. アプリは複数の 「入力→処理→出力」 の組み合わせの構造 2014/10/11 PHPカンファレンス2014 45
- 46. ロジック処理 セキュアなプログラムの基本構造 2014/10/11 PHPカンファレンス2014 46 入力ソース 入力処理 出力処理 出力 入力ソース 入力処理 ロジック処理 出力処理 出力 入力ソース 入力処理 ロジック処理 出力処理 出力 入力ソース 入力処理 ロジック処理 出力処理 出力
- 47. 契約プログラミング 契約による設計は 高性能 2014/10/11 PHPカンファレンス2014 47
- 48. 例：文字エンコーディング のバリデーション 2014/10/11 PHPカンファレンス2014 48
- 49. 2014/10/11 PHPカンファレンス2014 49 入力ソース 入力処理 ロジック処理 出力処理 出力 ロジック処理 ロジック処理 ロジック処理 入力ソース 入力処理 ロジック処理 出力処理 出力 ロジック処理 ロジック処理 ロジック処理 バリデーション バリデーション バリデーション バリデーション バリデーション バリデーション
- 50. 契約プログラミング 契約による設計は セキュア 2014/10/11 PHPカンファレンス2014 50
- 51. 2014/10/11 PHPカンファレンス2014 51 入力ソース 入力処理 ロジック処理 出力処理 出力 ロジック処理 ロジック処理 ロジック処理 バリデーション バリデーション 仮にエスケープ・バリ デーション漏れがあった としても 入力バリデーションが確 実に行われ安全性が保 障できる場合もある 個々のロジック処理でも、 信頼境界線を越える入出 力には「契約」の順守が求 められる ↓ 安全性の担保が行われる 可能な限りの安全性対策 を行う
- 52. 情報セキュリティ対策とは •対策・緩和策を積み重ねて、 データ/プログラムの安全性を管理 •安全性を管理する、とは •リスクを管理する、であり •許容可能な程度までリスクを緩和する •万が一のインシデント発生時には原因が判るようにする •CIAに加え、Accountabilityも重要なセキュリティ要素 •この他にAuthenticityも重要なセキュリティ要素 2014/10/11 PHPカンファレンス2014 52
- 53. 開発者はウェブアプリの ルールを作れる 2014/10/11 PHPカンファレンス2014 53
- 54. それなりなルール VS 厳格なルール 2014/10/11 PHPカンファレンス2014 54
- 55. 2014/10/11 PHPカンファレンス2014 55 簡単に侵入可能 そもそも侵入が困難 入力バリデーションなしで侵入可能 それなりなルール 入力バリデーションありで侵入が困難 厳格なルール
- 56. セキュリティの基礎を知っ た上で 2014/10/11 PHPカンファレンス2014 56
- 58. 結論 2014/10/11 PHPカンファレンス2014 58
- 59. ウェブエンジニアが必要な セキュリティスキルとは？ 2014/10/11 PHPカンファレンス2014 59
- 61. 情報セキュリティ対策 の概念・基礎知識 2014/10/11 PHPカンファレンス2014 61
- 62. 正しい概念・基礎知識 なしでは セキュアなアプリ構築は 不可能 2014/10/11 PHPカンファレンス2014 62
- 65. 徳丸さんと見解が異なる点 •ブラックリストとホワイトリスト •入力バリデーションはセキュリティ対策 •入力バリデーションはできない？ •出力エスケープは必須知識 •その他？ 2014/10/11 PHPカンファレンス2014 65
- 66. バリデーションとエラー •「バリデーション」と「入力」エラーの違い •バリデーション •入力としては妥当な入力を許可 あり得ない入力は受け入れない •例：キーボードからデータに入力できない制御文字、壊 れた文字エンコーディング •入力エラー •入力としてあり得る入力 •例：人間が入力したためのタイプミス 2014/10/11 PHPカンファレンス2014 66
- 67. ホワイトリストとブラックリスト •ホワイトリスト–許可することを定義 •ブラックリスト–許可しないことを定義 •人はブラックリストによるルールを作りがち •例：校則、法律 •ブラックリストでは漏れが発生しやすい •例：入社1年目の社員は○○にアクセスできない ↓ 協力社員は？ •ホワイトリストは漏れが発生しずらい •例：○○にアクセスできるのは◇◇、△△のみとする •ホワイトリストが基本 2014/10/11 PHPカンファレンス2014 67
- 68. 入力バリデーションの誤解 •入力バリデーションは出来ない •アプリケーションプログラマならどんな入力が期待され るか、必ず知っているはず •入力形式が不定のランダムバイト列の入力はほぼない •入力バリデーションは 「許可された入力を許可」 ≒ 「あり得ない入力を不許可」 2014/10/11 PHPカンファレンス2014 68
- 69. 入力バリデーションの基本 •ホワイトリスト方式が基本 •ただし、慎重に例外の利用もOK •例：フリーテキスト入力における制御文字の排除 •入力バリデーションエラーは致命的エラー •処理を中止→ ロックアウト •処理の中止が不適切なエラーは「入力ミス」 •通常のエラー処理 2014/10/11 PHPカンファレンス2014 69
- 70. 出力制御の誤解 •エスケープは排除 •そもそもエスケープを排除できない •WebアプリはテキストI/Fの塊 ＆ 全てのI/FにセキュアなAPIはない •プリペアードクエリもセキュアなAPIではない •CSPは非常に有効な緩和策だが、JSインジェクションが JSコンテクストのみに限定されるだけ •「デフォルトでエスケープ」はHTMLテンプレートが行っ ているが、他の出力先でも有効 2014/10/11 PHPカンファレンス2014 70
- 72. 出力制御の基本 •エスケープ •WebアプリはテキストI/Fの塊 •エスケープAPIがない場合でもエスケープ方法が定義 •例：SQLクエリの識別子エスケープ、コマンドエスケープ、LDAP エスケープ、XPATHエスケープなど •セキュアAPI •エスケープなしでも安全に出力できるAPI •セキュアなAPIと言われていても制限あり •例：プリペアードクエリ・プレイスホルダはパラメータのみ対応、 テキスト埋め込みに対応不可 •バリデーション 2014/10/11 PHPカンファレンス2014 72
- 73. フレーワーク・ライブラリ・言語 を知る •処理仕様を知るのみでは不十分・不完全 •入力仕様 •どのようなデータ入力を期待しているのか？ •どのようなデータ入力が安全なのか？ •出力仕様 •どのようなデータが出力されるのか？ •どのようなデータ出力が安全なのか？ 2014/10/11 PHPカンファレンス2014 73
- 74. 静的型言語が安全な理由 •WebアプリはテキストI/Fのアプリだが 2014/10/11 PHPカンファレンス2014 74 「型」を強制することで、 入力バリデーションの一部を強制 入力バリデーションは 言語仕様を問わず実装可能 DbCではこれらの制約（契約）を強制 ※出力の「型」の議論は省略
- 75. 合成の誤謬 •合成の誤謬とは経済用語 •局所最適化は必ずしも全体最適化とはならない •例：節約は個人レベルでは美徳だが、経済全体では経済の 縮小となる •個別の脆弱性を局所最適化しても、全体最適化とは ならない •局所最適化＝縦深防御 •全体最適化にはアプリケーションレベルで確実な入出力制 御が必要 •境界防御が基本 •ITセキュリティの目的は全体最適化 2014/10/11 PHPカンファレンス2014 75
- 76. APIを使えばよい？！ •そもそもAPIが安全でない •プリペアードクエリは埋め込みを禁止していない •識別子、SQL語句の埋め込みが可能 •そもそもAPIがない •安全なAPI自体がない •エスケープAPIさえない •PHPの場合、LDAPエスケープが追加されたのは最近 •XPATHクエリのエスケープがない •HTMLタグ名のエスケープがない 2014/10/11 PHPカンファレンス2014 76
- 77. CSPはインジェクションの 切り札か？ •CSPはJavaScriptとHTMLを分離を強制可能 •HTMLコンテクストにおけるJavaScriptインジェクションが不可 能となる •CSPはJavaScriptインジェクションは防止できても、HTML インジェクションの防止は不可能 •JavaScript内でのインジェクション、DOMの危険な操作 などは防止できない •CSPも「緩和策」であり、出力制御の基本が重要 2014/10/11 PHPカンファレンス2014 77
- 78. プレイスホルダはインジェクション の切り札か？ •SQLクエリのプレイスホルダは「パラメータ」の分離 は可能 •「パラメータ」の分離は出来ても「識別子」「SQL語 句」の分離は不可能 •変数の埋め込み自体は禁止・防止できない •プレイスホルダも「緩和策」であり、出力制御の基 本が重要 2014/10/11 PHPカンファレンス2014 78
- 79. セキュリティ対策に対する過信 •入力バリデーション、確実な出力制御、これだけでは 不十分 •全体最適化（セキュア化）には非常に有用だが、カバーでき る範囲に限界がある •プレイスホルダやCSPは不十分 •局所最適化（SQLパラメータ・HTMLコンテクストへのインジェ クション対策）には非常に有用だが、カバー範囲に限界があ る •セキュリティ対策は緩和策の積み重ねによるリスクの 管理（リスクの緩和） 2014/10/11 PHPカンファレンス2014 79
- 80. APIを知るポイント •「APIが何をするのか・どう使うか」を知るだけでは、 セキュアなコードは書けない •危険性があるAPIも •「APIの入力の制限・前提」がセキュアコーディング では重要 •「APIの出力結果の制限・前提」も重要 •データのやりとりが信頼境界線の中であるか、外であ るか？ 2014/10/11 PHPカンファレンス2014 80
- 81. デフォルトでエスケープ •テキストに意味（命令）が含まれるI/Fでは、エス ケープAPIがない場合でもエスケープ方法がほとん ど定義されている •HTMLテンプレートシステムでは標準 •HTML以外にもURLパラメータ名、URLパラメータ値、 JavaScript、LDAP、Xpath、OSコマンド、SQLなどでも 適用すべき 2014/10/11 PHPカンファレンス2014 81
- 82. エスケープは悪で失敗した XPath1.0 •XPath1.0にはエスケープ方法が定義されていない •“（ダブルクオート）と‘（シングルクオート）による文字リ テラル定義が規定されているのみ •詳細は私のブログを参照 •恐らく、エスケープは悪、という前提で設計された と思われる •ＸPath2.0では失敗に気付き、SQLエスケープのよう なエスケープ方法が定義される •クオートを重ねることでエスケープ 2014/10/11 PHPカンファレンス2014 82
- 83. セキュリティ対策の基準は 時代とともに変化 •古いキャッシュカードには暗証番号がカードに記録 •パスワードのハッシュ化はDESで十分だった •暗号理論的ハッシュ関数としてMD5が十分だった •SSLでなくても十分だった •パスワードによる認証で十分だった 2014/10/11 PHPカンファレンス2014 83
- 84. プロが決めた仕様は完璧か？ •完全でない物が多い •初期のHTML5は数多くの問題が発見された •現在のCOOKIEの仕様の結構いい加減 •現在のセッション管理の仕様は結構いい加減 •XPath1.0の文字リテラルは致命的に設計ミス •広く利用されている≠ 理想に近い仕様・実装 2014/10/11 PHPカンファレンス2014 84 盲 目 的 に信 用 するのはNG
- 85. 知らなくてもよい事 •攻撃スキル •アプリケーションを守る為には「原理」だけ知っていれば よい 2014/10/11 PHPカンファレンス2014 85