PHPにないセキュリティ機能

1. PHPにないセキュリティ機能無い機能と在る機能エレクトロニック・サービス・イニシアチブ

2. 自己紹介 • 氏名：大垣靖男（おおがきやすお） • 職業： • PHPコミッター • エレクトロニック・サービスイニチアチブ代表取締役社長 • 岡山大学大学院非常勤講師/PHP技術者認定機構顧問など • Webサイト構築関連のコンサルティングなど • テクニカル・セキュア開発（開発体制・コード検査・ツール販売・セキュリティパッチサービス）など • ネット • http://blog.ohgaki.net/ • yohgaki – Facebook/Twitterなど • yohgaki@ohgaki.net 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 2

10. セッションアダプション • ここで言うセッションアダプションとはクラッシックなアダプティブなセッションマネージャーの事 • 未初期化のセッションIDを有効なセッションIDをして受け入れる脆弱性 • PHP 5.4のセッションモジュールには use_strict_modeが無い • つまりアダプティブなセッション管理 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 10 JavaScriptインジェクションに脆弱なアプリ消えないセッション IDクッキー設定攻撃者は常にターゲットのログインセッションを乗っ取り可能に

11. ブラウザのクッキー管理もいい加減 • いい加減なクッキー管理により消えないクッキーを設定可能 • クッキーのdomain、path、secure、httponly属性の取り扱いがブラウザによって異なる • 設定の順序によって分けの解らない動作をするブラウザもある • 比較的最近のRFC改定によりブラウザが最も優先順位が高いとするクッキーのみが送信される • 昔の動作であれば、同じ名前のクッキーが複数送られてきたのでサーバー側で不正なクッキーの検出が可能であったが、現在は検出不可能 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 11

12. ブラウザのクッキー管理もいい加減 • 更に悪いことに今のRFCだと、一つのレスポンスに同じクッキー名のSet-Cookieヘッダは一つのレスポンスしか返せない（ことになっている） • 知る限りところ複数かつ同名のSet-Cookieヘッダを無視するブラウザは知らない（今は無視するかも？） • つまり、以下のようなオフェンシブクッキーを削除するコードはRFC的には違反 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 12 setcookie('foo', '', 1 , "/"); setcookie('foo', '', 1 , "/myapp/"); setcookie('foo', '', 1 , "/myapp/login/"); setcookie('foo', '', 1 , "/myapp/login/reset_cookie/");

15. session_regenerate_id()の動作 • オプション引数なしでは古いセッションを削除しない • session_regenerate_id(true)は直ちに古いセッションを削除する 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 15 直ちに古いセッションを削除！これで万事OK！これで万事OKではない

17. 不正確なセッション削除 • セッションアダプションと同じく10年来知られている脆弱性 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 17 session_regenerate_id(); 10年以上前にこの関数が追加された時、セッションが消えると困るのでデフォルトでは削除しない仕様に変更 GCに任せておけば、そのうち消える

19. この問題への取り組み • ユーザーランドで対応が可能 • 削除フラグ＋タイムスタンプで確認するだけ • 詳しくは「間違いだらけのHTTPセッション管理とその対策」 • http://blog.ohgaki.net/design-bugs-in-http-session- management • 実はPHP5.6用のパッチは準備済みだった • ここ数年間、セッションIDの削除がGC任せである問題に取り組んでいる • 提案したが「この問題とセキュリティ対策の本質」を理解されず却下 • 現在は理解が進みPHP7には入るかも知れない 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 19

21. include($_GET) • PHPは埋め込み型言語なので 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 21 Include(‘/etc/passwd’); // OK!! Include(‘/www/html/upload/evil.gif’); // OK!! パスワードファイルの中身が出力されるイメージファイルの中の PHPスクリプトの実行もOK

22. include($_GET) • 他の言語で同じようなことをする“非”埋め込み型なので 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 22 Include(‘/etc/passwd’); // NG!! Include(‘/www/html/upload/evil.gif’); // NG!! 確実にパースエラー単純な画像ヘッダーのチェックなら回避できるが、まともにバリデーションしていればパースエラー

23. PHPのinclude文は読み込み・実行に脆弱 • 過去に数年間にわたり様々な改善提案 • “非”埋め込みモード：他の言語並みに安全 • 拡張子ホワイトリスト：.phar, .phpのみ実行許可 • スクリプトホワイトリスト：実行可能なスクリプトを指定 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 23 今はココです。開発者うけも比較的よくこの提案なら承認されるかも。 Opcacheにプリロードするので実行速度も向上する

25. PHP7のタイプヒントには任意精度数値がない • データ型は単純に指定すれば良い、物ではない 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 25 Validate for expected data types OWASP Secure Coding Practices(v2) – InputValidation 整数型のデータ型には、signed/unsignedがありchar/byte/ short/word/int/longなどがある浮動小数点型にも通常の倍精度のみでなく、四倍精度もある 32ビットCPUのPHPは符号付32ビット整数、64ビットCPUは符号付64ビット整数 http://blog.ohgaki.net/owasp-secure-coding-practices-quick-reference-guide

26. PHP7は任意精度整数、浮動小数点型のタイプヒントがない • 特に32ビットCPUのPHPは符号付32ビット整数しかサポートしないので影響が大きい 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 26 function getMyTableByID(int $id) { // データベースからレコードを取得 } DBのIDは普通は 64ビット整数 JSONデータ？numericに精度指定は無い

28. 重要：データ型は指定すれば良い、という物ではない • PHPがサポートするデータ型（整数、浮動小数点）の範囲を超えるデータにはint/floatタイプヒントを使ってはならない • 年齢や月など確実に範囲内に収まるデータにのみ int/floatタイプヒントを使う • 全ての例外・エラーはキャッチする • PHP7のZPPではデータ型の範囲内かチェックしエラー（例外でなく、エラーです。今のところ）が発生する 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 28

29. 整数オーバーフローを検出できない • Webシステムの入力は基本「文字列」 • ブラウザ • データベース（LDAPなどを含む） • JSON/XML • 大きすぎる整数はキャスト後に PHP_INT_MAX/PHP_INT_MINのどちらかになる • PHP_INT_MAX/PHP_INT_MINをオーバーフローとして取り扱うと簡単 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 29

33. LDAPエスケープが無い、無かった • PHP 5.5までLDAPエスケープ関数が無い • LDAPエスケープにはFilterコンテクストとDNコンテクストのエスケープが必要 • ldap_escape関数はPHP 5.6から • 参考 • http://php.net/manual/ja/function.ldap- escape.php 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 33

35. XPathエスケープが無い • XPath 1.0の定義には、そもそもエスケープ方法が定義されていない • XPath 1.0の仕様は壊れている • 参考 • http://blog.ohgaki.net/xpath-query-1 • http://blog.ohgaki.net/xpath-query-2 • http://blog.ohgaki.net/reason-why-xpath1-0-is- broken • XPath 2.0ではエスケープ仕様が追加された 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 35

37. SQL識別子エスケープが無い • PostgreSQLモジュールにはSQL識別子エスケープ関数（pg_escape_identifier）がある • 他のDBモジュールには無い • DBMS自体は識別子エスケープを定義 • しかし、PostgreSQLを除いてクライアントアクセスライブラリに識別子エスケープAPIがない • 仕様として問題 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 37

39. JSONエスケープはある • しかし、デフォルトで安全ではない • 参考 • http://blog.ohgaki.net/json-escape • http://blog.ohgaki.net/php7-json-decode-json- encode-problem 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 39

41. JSON Numeric型は int/floatに自動変換されてしまう • intはオプションで文字列のまま取得可能 • floatは無理 • PHP7用にオプションで文字列のまま取得可能にするよう検討中 • 基本的にこのような自動変換/型の強制はセキュリティ的に問題 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 41

43. HTMLエスケープはあるがその他コンテクスト用エスケープが無い • OWASP ESAPIは各コンテスト用のエスケープ（エンコード）メソッドを提供 • https://github.com/OWASP/PHP-ESAPI • 最近は更新されていない 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 43

44. htmlspecialcharsはデフォルトで安全でない • PHP 5.6未満は明示的文字エンコーディング設定が必要 • PHP 5.6以降はdefault_charsetが利用される • ‘ （シングルクオート）をデフォルトでエスケープしない • HTML5に対応していない • / のエスケープに対応していない。HTML5ではクオート文字なしの属性が許される 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 44

46. OSコマンドの完全なエスケープは非常に困難 • 多数のOS、シェル＋コマンド引数パーサー • escape_shell_argsも完璧ではない • 参考 • http://blog.ohgaki.net/os-command-escape- shell-spec-command-implementation • pcntl_execはコマンドと引数を分離して実行 • 内部的にexecv, execveを利用 • shell_execなどで使えるように提案中 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 46

50. SQL文のLIKEエスケープがない • おかしなクエリ結果が返るだけで、セキュリティ上のインパクトがあることは少ない • しかし、余計な結果が表示されることが問題となる場合も • そもそもDBMSがエスケープAPIを提供していない • “％”、“_”をエスケープ 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 50

52. 正規表現メタ文字エスケープ関数がない • quotemeta関数はあるがこれでは不十分 • http://php.net/manual/ja/function.quotemeta.php • PCRE用には専用関数がある • http://php.net/manual/ja/function.preg-quote.php • mbstring用には専用関数がない • PCRE用が流用できる • SQLのLIKE文と同じく、余計な結果が返ることが問題となる場合がある • エスケープしないと正規表現ライブラリ脆弱性攻撃に利用される 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 52

54. 使いやすい入力バリデーターが無い • Filterモジュールは在る • http://php.net/manual/ja/book.filter.php • 入力バリデーターとして使いやすい、とは言いがたい • フレームワークのバリデーターを使いましょう 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 54

58. タイプコンフュージョン • タイプコンフュージョンとはPHP組み込み関数が変数型を間違えて処理してしまう脆弱性 • 最近、頻繁に修正されている脆弱性 • 例えば、内部関数が整数型を期待しているのに、ユーザーが配列型を渡す 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 58 +-Core: + . Additional fix for bug #69152 (Type confusion vulnerability in + exception::getTraceAsString). (Stas) +- SOAP: + . Fixed bug #69152 (Type Confusion InfoleakVulnerability in unserialize() + with SoapFault). (Dmitry)

59. 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 59 typedef union _zvalue_value { long lval; /* long value */ double dval; /* double value */ struct { char *val; int len; } str; HashTable *ht; /* hash table value */ zend_object_value obj; } zvalue_value; struct _zval_struct { /*Variable information */ zvalue_value value; /* value */ zend_uint refcount__gc; zend_uchar type; /* active type */ zend_uchar is_ref__gc; }; PHP 7のZVAL（PHP変数の構造体）の定義これがPHP変数の構造体実際に変数を保存するユニオン構造体

60. タイプコンフュージョンユニオン構造体はメモリ領域を共有つまり整数型であると仮定して処理していて、配列型が渡された場合、ハッシュのメモリアドレスが判るハッシュのメモリアドレスが判ると、ハッシュ構造体がデストラクタを持っていることを利用し、ヒープ領域で任意コード実行ができる。 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 60 ただし、そのメモリに書き込める別の脆弱性が必要

64. Use After Free • PHP 5.4.40のNEWSより 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 64 - cURL: . Fixed bug #69316 (Use-after-free in php_curl related to CURLOPT_FILE/_INFILE/_WRITEHEADER). (Laruence) - Sqlite3: . Fixed bug #66550 (SQLite prepared statement use-after-free). (Sean Heelan)

65. Use After Free • 開放済みメモリにアクセスしてしまう脆弱性 • 高度なメモリ破壊攻撃の一種 • スタックオーバーフローは単純なメモリ破壊攻撃 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 65 別の変数のメモリが割り当てられる解放後のポインタを使い不正にメモリに書き込み別の変数のメモリが開放されるメモリの解放後にメモリマネージャーのデストラクタを書き換える改ざんデストラクタが実行される

66. PHPユーザーの防御策（緩和策）出来る限り厳格な入力バリデーションを行う • 数値データのみなら文字列でも20バイトも無い • 20バイト以下のシェルコードは困難 • 数字だけでは無理（ただし、制御コードなしのシェルコードは可能） 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 66 CERT Top 10 セキュアコーディングプラクティス 1. 入力をバリデーションする全ての信頼できないデータソースからの入力をバリデーションする。適切な入力バリデーションは非常に多くのソフトウェア脆弱性を排除できる。ほぼ全ての外部データソースに用心が必要である。これらにはコマンドライン引数、ネットワークインターフェース、環境変数やユーザーが制御可能なファイルなどが含まれる。

69. include文に対するヌル文字インジェクション対策？？ • 例 <?php //ファイルアップロード処理のどこかで //拡張子が画像かチェック if (!preg_match(“.png¥z”, $_GET[“module”)) { die(“Do not upload other than .png”; } <?php $module = $_GET[‘module’]; include(PATH_MODULE . $module); 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 69

70. include文に対するヌル文字インジェクション対策 <?php include(“/path/to/any.file¥0.png”); include文の実態はC言語のファイル関数つまり非バイナリセーフ 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 70 PHPの変数はバイナリセーフつまり、￥0までがファイル名として解釈される

71. include文に対するヌル文字インジェクション対策？？ <?php //ファイルアップロード処理のどこかで //拡張子が画像かチェック if (!preg_match(“.png¥z”, $_GET[“module”)) { die(“Do not upload other than .png”; } <?php $module = $_GET[‘module’]; include(PATH_MODULE . $module); 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 71 preg_matchはバイナリセーフ。￥0 も普通の文字として解釈される PHP変数はバイナリセーフ。$_GET なら%00は¥0文字として解釈される include文は非バイナリセーフ “../../../etc/password%00.png”なら

72. include文に対するヌル文字インジェクション対策 <?php include(“/path/to/any.file¥0.png”); 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 72 PHP5.3.4からストリームラッパーでヌル文字を不許可 http://attack/script.php%00.png なども不許可 - Security enhancements: . Paths with NULL in them (foo¥0bar.txt) are now considered as invalid. (Rasmus)

75. ヌル文字インジェクションは終わったか？ • ついこの前のリリースでも脆弱性が修正される 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 75 14 May 2015 PHP 5.4.41 . Fixed bug #69418 (CVE-2006-7243 fix regressions in 5.4+). (Stas) <?php include(“/path/to/any.file¥0.png”); PHP5.3.4からストリームラッパーでヌル文字を不許可 http://attack/script.php%00.png なども不許可ストリームラッパー以外での場所では対応していなかった。例）unlinkなど

76. ヌル文字インジェクションは終わったか？ • ストリームラッパー以外の場所での対応 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 76 diff --git a/ext/standard/file.c b/ext/standard/file.c index 708c3e2..21e1e53 100644 --- a/ext/standard/file.c +++ b/ext/standard/file.c @@ -813,7 +813,7 @@ PHP_FUNCTION(tempnam) char *p; int fd; - if (zend_parse_parameters(ZEND_NUM_ARGS()TSRMLS_CC, "ps", &dir, &dir_len, &prefix, &prefix_len) == FAILURE) { + if (zend_parse_parameters(ZEND_NUM_ARGS()TSRMLS_CC, "pp", &dir, &dir_len, &prefix, &prefix_len) == FAILURE) { return; } ZPPを拡張し”p”タイプを追加 ”p”タイプはヌル文字を拒否

77. ヌル文字インジェクションは終わったか？ • ストリームラッパー以外の場所での対応 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 77 diff --git a/ext/standard/file.c b/ext/standard/file.c index 708c3e2..21e1e53 100644 --- a/ext/standard/file.c +++ b/ext/standard/file.c @@ -813,7 +813,7 @@ PHP_FUNCTION(tempnam) char *p; int fd; - if (zend_parse_parameters(ZEND_NUM_ARGS()TSRMLS_CC, "ps", &dir, &dir_len, &prefix, &prefix_len) == FAILURE) { + if (zend_parse_parameters(ZEND_NUM_ARGS()TSRMLS_CC, "pp", &dir, &dir_len, &prefix, &prefix_len) == FAILURE) { return; } ZPPを拡張し”p”タイプを追加 ”p”タイプはヌル文字を拒否 3rdパーティモジュールなど ZPP拡張の”p”タイプに未対応ならヌル文字インジェクションに脆弱になる

78. ヌル文字インジェクションは終わったか？ • ストリームラッパー以外の場所、ZPPの“ｐ”タイプに未対応のケースを考慮しなければならない 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 78 以下の物は個別に確認しなければならない • ヌル文字（%00）をチェックする • 改行文字（%0d, %0a, ¥r, ¥n） • パスを変更する文字列（../ および ..¥）をチェックする。 • UTF-8の拡張文字セットがサポートされている場合、 %c0%ae%c0%ae/ など別形式の形もチェックする（Canonicalizeを利用し重複エンコーディングや他の不明瞭化攻撃に対応する）（訳注：../ や ..¥ を取り除きなさい、ではありません。単純に取り除くだけだと簡単に攻撃できます） OWASP Secure Coding Practices http://blog.ohgaki.net/owasp-secure-coding-practices-quick-reference-guide

79. ヌル文字インジェクションの技術的・セキュリティ的な根本を理解バイナリセーフ（ヌル文字に意味がない）非バイナリセーフ（ヌル文字が文字列終端）ヌル文字の解釈の違い → 処理に相違が発生一文字でも意味がある文字（バイト）があるとインジェクション攻撃の可能性が発生する 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 79

80. ヌル文字インジェクションの技術的・セキュリティ的な根本を理解バイナリセーフ（ヌル文字に意味がない）非バイナリセーフ（ヌル文字が文字列終端）ヌル文字の解釈の違い → 処理に相違が発生一文字でも意味がある文字（バイト）があるとインジェクション攻撃の可能性が発生する 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 80 基本的にこの構造は文字に意味がある全てのインターフェースに共通インジェクション攻撃に共通

83. HTTPヘッダーインジェクション • header()/setcookie()関数で対策済み • PHPからHTTPヘッダーを送る手段は header()/setcookie()しかない（基本的には） • 自分でソケット作ったり、cURLでリクエストを送ったりすると、当然自分でHTTPヘッダーを取り扱うことになる • 新しいRFCでは複数行にまたがる単一HTTPヘッダーは許可されていない • IEは既にこのタイプのヘッダーは無視している • HTTPヘッダーに改行を許さない、でOK 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 83

84. メールヘッダーインジェクション 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 84 • mail関数にはメールヘッダーインジェクション脆弱性が残されている • https://github.com/php/php-src/pull/1273 • https://bugs.php.net/bug.php?id=68776 [2015-01-09 09:59 UTC] yohgaki@php.net Description: ------------ mb_send_mail() parses additional headers and stores into hash. During the parse process, invalid headers are discarded. However, mail() simply check ¥0 and strip trailing ¥r¥n. Therefore, mail() is vulnerable to mail header injections via additional header parameter.

85. メールヘッダーインジェクション 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 85 • https://bugs.php.net/bug.php?id=68776 はセキュリティバグとして処理されていない • PHPコミッターはどう考えているのか？ • 入力バリデーションは当たり前 • PHP本体だけでなく3rdパーティモジュールもある • そもそもPHPプログラム/ライブラリ/フレームワークの脆弱性も考慮すべき • 例）ZendFramework 1.xのメールヘッダーインジェクション

86. 改行インジェクションとは • 一行が意味を持つプロトコルに有効な攻撃手法 • HTTPプロトコル • SMTPプロトコル • その他、一行が意味を持つプロトコルほぼ全て 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 86 問題の本質を知ることが、問題への対応・解決への近道 HTTPヘッダレスポンススプリッティング、メールヘッダーインジェクションの理解は本質の理解に比べ重要ではない例：memcachedインジェクション

88. ヌル文字・改行インジェクションの技術的・セキュリティ的な根本を理解・バイナリセーフ（ヌル文字に意味がない）・非バイナリセーフ（ヌル文字が文字列終端）ヌル文字の解釈の違い → 処理に相違が発生一文字でも意味がある文字（バイト）があるとインジェクション攻撃の可能性が発生する 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 88 固定長インターフェースのインジェクション攻撃にはオーバーフロー攻撃が有効 C言語のバッファーオーバーフロー攻撃が有名だが、固定長テキストデータでも同類の攻撃が可能な場合もある基本的にこの構造は全ての可変長インターフェースのインジェクション攻撃に共通

96. 全体最適化と部分最適化 • 全体として最適化しない場合、目的が達成できない全体最適化 • 部分最適化も重要だが、部分最適化では全体最適は実現しない • 合成の誤謬 • http://blog.ohgaki.net/fallacy-of-composition-and-it- security 部分最適化 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 96

97. 部分最適化で全体最適化ができない理由 • 部分最適化の場合、アプリケーションロジックの中にセキュリティ対策が埋没する • アプリケーションロジックのバグは発見しづらい • しかも、変更が多い • アプリ自体の仕様変更、リファクタリング（継続的開発） • テストの主目的が「正常系」テスト • ライブラリ/フレームワークの更新・バージョンアップ • OS/低層ライブラリの更新・バージョンアップ • 個々の対策を積み重ねても、全体的に対策した状態にならない 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 97

98. 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 98 Webアプリ情報 HTML/CSS FW/API OSコマンドパス SQL/Xpath/ LDAP/etc JavaScript GET/POST/ HEADER Web サービス信頼境界線信頼境界線を越える“もの” は“安全性の担保”が必要つまり、入出力制御これらはテキストI/Fでバリデーション・エスケープは必須

101. 契約プログラミング契約のよる設計の構造 2014/10/11 PHPカンファレンス2014 101

103. 2014/10/11PHPカンファレンス2014 103 入力入力入力入力入力処理処理処理処理処理処理処理処理処理処理処理処理処理処理処理処理処理処理契約プログラミングでは入力が契約を守っているか入出力で確認万が一セキュリティ処理がなくても安全になることが多い信頼境界線ここで追加のセキュリティ確認も勿論OK。縦深防御（多重のセキュリティ・多層防御）

104. 2014/10/11PHPカンファレンス2014 104 入力入力入力入力入力入力処理入力処理入力処理入力処理入力処理処理処理処理処理処理処理処理処理処理出力処理出力処理出力処理出力処理信頼境界線出力出力出力出力出力信頼境界線出力処理多くのリスクを緩和するセキュアなアーキテクチャ

105. セキュアな入出力制御で対策・緩和できる脆弱性入力出力 CWE High CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('PathTraversal') Mod High CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Mod High CWE-79: Improper Neutralization of Input DuringWeb Page Generation ('Cross-site Scripting') Mod High CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Mod CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') Mod CWE-131: IncorrectCalculation of Buffer Size High CWE-134: Uncontrolled Format String Mod CWE-190: Integer Overflow orWraparound Mod CWE-434: UnrestrictedUpload of File with DangerousType Mod Mod CWE-601: URL Redirection to Untrusted Site ('Open Redirect') Mod High CWE-676: Use of Potentially Dangerous Function Ltd CWE-732: Incorrect Permission Assignment for Critical Resource Mod CWE-807: Reliance on Untrusted Inputs in a Security Decision High CWE-829: Inclusion of Functionality from UntrustedControl Sphere DiD CWE-862: Missing Authorization 2014/10/11PHPカンファレンス2014 105

106. 「入力」「出力」を確実にするだけで8割9割の脆弱性を防止・緩和可能 2014/10/11PHPカンファレンス2014 106

107. 職人技セキュリティからエンジニアリングされたセキュリティへ 2014/10/11PHPカンファレンス2014 107

108. 2014/10/11PHPカンファレンス2014 108 入力入力入力入力入力入力処理入力処理入力処理入力処理入力処理処理処理処理処理処理処理処理処理処理出力処理出力処理出力処理出力処理信頼境界線出力出力出力出力出力信頼境界線出力処理出力処理に問題があっても出力処理に問題があっても、結果的に安全である場合も多い途中の処理に問題があっても

109. アプリの入力・出力の安全性確保はセキュアアプリの土台・基礎 2014/10/11 PHPカンファレンス2014 109

110. 継続的インテグレーション高速な開発サイクルも契約プログラミングで効率化 2014/10/11 PHPカンファレンス2014 110

111. 間違えてはならないのは契約プログラミング契約による設計でも 2014/10/11PHPカンファレンス2014 111 多層防御は必要！

112. セキュアなプログラムの基本構造 2014/10/11PHPカンファレンス2014 112 入力ソース入力処理ロジック処理出力処理出力バリデーションで攻撃可能範囲を限定・緩和出力で完全に安全にできるデータは完全に安全にエスケープ、セキュアAPI、バリデーションで攻撃可能範囲を限定・緩和ロジックでも必要なセキュリティ対策は行う多層防御

113. 普通のアプリは単純な「入力→処理→出力」ではない 2014/10/11PHPカンファレンス2014 113

114. セキュアなプログラムの基本構造 2014/10/11PHPカンファレンス2014 114 入力ソース入力処理ロジック処理出力処理出力 SQLクエリ入力ソース入力処理ロジック処理出力処理出力クエリ結果 WebAPI 入力ソース入力処理ロジック処理出力処理出力 API結果 HTML リクエスト

115. アプリは複数の「入力→処理→出力」の組み合わせの構造 2014/10/11PHPカンファレンス2014 115

116. ロジック処理セキュアなプログラムの基本構造 2014/10/11PHPカンファレンス2014 116 入力ソース入力処理出力処理出力入力ソース入力処理ロジック処理出力処理出力入力ソース入力処理ロジック処理出力処理出力入力ソース入力処理ロジック処理出力処理出力

117. 契約プログラミング契約による設計は高性能 2014/10/11PHPカンファレンス2014 117

118. 例：文字エンコーディングのバリデーション 2014/10/11PHPカンファレンス2014 118

119. 2014/10/11PHPカンファレンス2014 119 入力ソース入力処理ロジック処理出力処理出力ロジック処理ロジック処理ロジック処理入力ソース入力処理ロジック処理出力処理出力ロジック処理ロジック処理ロジック処理バリデーションバリデーションバリデーションバリデーションバリデーションバリデーション

120. 契約プログラミング契約による設計はセキュア 2014/10/11PHPカンファレンス2014 120

121. 2014/10/11PHPカンファレンス2014 121 入力ソース入力処理ロジック処理出力処理出力ロジック処理ロジック処理ロジック処理バリデーションエスケープ API バリデーション仮にバリデーション漏れがあったとしても入力バリデーションが確実に行われ安全性が保障できる場合もある個々のロジック処理でも、信頼境界線を越える入出力には「契約」の順守が求められる ↓ 安全性の担保が行われる可能な限りの安全性対策を行う

122. 2014/10/11PHPカンファレンス2014 122 入力ソース入力処理ロジック処理出力処理出力ロジック処理ロジック処理ロジック処理バリデーションエスケープ API バリデーション縦深防御も忘れずに！ロジック中にも入出力があることにも注意！

123. ロジック処理セキュアなプログラムの基本構造 2014/10/11PHPカンファレンス2014 123 入力ソース入力処理出力処理出力入力ソース入力処理ロジック処理出力処理出力入力ソース入力処理ロジック処理出力処理出力入力ソース入力処理ロジック処理出力処理出力縦深防御も忘れずに！ロジック中にも入出力があることにも注意！適度な粒度（モジュール単位など）で境界防御（縦深防御）

124. 情報セキュリティ対策とは • 対策・緩和策を積み重ねて、データ/プログラムの安全性を管理 • 安全性を管理する、とは • リスクを管理する、であり • 許容可能な程度までリスクを緩和する • 万が一のインシデント発生時には原因が判るようにする • CIAに加え、Accountabilityも重要なセキュリティ要素 • この他にAuthenticityも重要なセキュリティ要素 2014/10/11PHPカンファレンス2014 124

125. 参考にすべきセキュアコーディングガイド 2015/5/30(c) Electronic Service Initiative, Ltd. All rights reserved. 125 • CERT Secure Coding Standard • http://blog.ohgaki.net/cert-top-10-secure-coding- standard • CWE/SANS TOP 25 • http://blog.ohgaki.net/sans-cwe-top-25-monster- mitigation • OWASP Secure Coding Practices • http://blog.ohgaki.net/owasp-secure-coding- practices-quick-reference-guide

PHPにないセキュリティ機能

Yasuo Ohgaki

Transcript