徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012

29,163 views
28,860 views

Published on

Published in: Technology
0 Comments
74 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
29,163
On SlideShare
0
From Embeds
0
Number of Embeds
1,103
Actions
Shares
0
Downloads
0
Comments
0
Likes
74
Embeds 0
No embeds

No notes for slide

徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012

  1. 1. 徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012 2012年9月15日 徳丸 浩
  2. 2. 本日お話しする内容• 鉄則1: PHP自体の脆弱性対処をしよう• 鉄則2: Ajaxの脆弱性対処をしよう• 鉄則3: 競合条件の脆弱性対処をしよう• 鉄則4: htmlspecialcharsの使い方2012• 鉄則5: escapashellcmdは使わないこと• 鉄則6: SQLインジェクションの対処• 鉄則7: クロスサイト・スクリプティングの対処• 鉄則8: クロスサイト・リクエスト・フォージェリの対処• 鉄則9: パスワードの保存はソルトつきハッシュ、できればスト レッチングも• 鉄則10: 他にもたくさんある脆弱性の対処 Copyright © 2012 HASH Consulting Corp. 2
  3. 3. 徳丸浩の自己紹介• 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立• 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ• その他 – 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開 「大学時代のPascal演習がCabezonでした」という方にお目にかかることも• 現在 – HASHコンサルティング株式会社 代表 http://www.hash-c.co.jp/ – 京セラコミュニケーションシステム株式会社 技術顧問 http://www.kccs.co.jp/security/ – 独立行政法人情報処理推進機構 非常勤研究員 http://www.ipa.go.jp/security/ Copyright © 2012 HASH Consulting Corp. 3
  4. 4. 鉄則1: PHP自体の脆弱性対処をしよう Copyright © 2012 HASH Consulting Corp. 4
  5. 5. PHPの脆弱性ってどれくらい危険なの? Copyright © 2012 HASH Consulting Corp. 5
  6. 6. JVN iPediaで検索してみようhttp://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja 6
  7. 7. 2011年5月以降のPHP高危険度脆弱性 JVN iPediaより引用 7
  8. 8. #1 JVNDB-2011-002207(CVE-2011-1938)PHP の socket_connect 関数におけるスタックベースのバッファオーバーフローの脆弱性概要 PHP の ext/sockets/sockets.c 内にある socket_connect 関数には、スタックベースのバッファ オーバーフローの脆弱性が存在します。CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的影響を受けるシステム PHP 5.3.3 から 5.3.6 通常あり得ない想定想定される影響 攻撃者により、UNIX ソケットの過度に長いパス名を介して、任意のコードを実行される可能性 があります。 8
  9. 9. #2 JVNDB-2011-002218(CVE-2011-3268)PHP の crypt 関数におけるバッファオーバーフローの脆弱性概要 PHP の crypt 関数には、バッファオーバーフローの脆弱性が存在します。 本脆弱性は、CVE-2011-2483 とは異なる脆弱性です。CVSS による深刻度 (CVSS とは?) 基本値: 10.0 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 全面的 完全性への影響(I): 全面的 可用性への影響(A): 全面的影響を受けるシステム PHP 5.3.7 未満 通常あり得ない想定想定される影響 攻撃者により、過度に長い salt 引数を介して、詳細不明な影響を受ける可能性があります。 9
  10. 10. #3 JVNDB-2011-002770(CVE-2011-3379)PHP の is_a 関数における任意のコードを実行される脆弱性概要 PHP の is_a 関数は、__autoload 関数の呼び出しを誘発するため、任意のコードを実行される 脆弱性が存在します。CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的影響を受けるシステム PHP 5.3.7 PHP 5.3.8 ????想定される影響 第三者により、巧妙に細工された URL、および特定の PEAR パッケージおよびカスタムオート ローダの安全でない動作を利用されることで、任意のコードを実行される可能性があります。 10
  11. 11. CVE-2011-3379入門• 以下のソースの結果わかりますか? (PHP5.3.7~5.3.8) function __autoload($class_name) { echo "autoload $class_name¥n"; } class Class1 { } $a = new Class1(); var_dump(is_a($a, "Class1")); var_dump(is_a("test", "Class1"));• 結果は以下の通り bool(true) autoload test bool(false) Copyright © 2012 HASH Consulting Corp. 11
  12. 12. CVE-2011-3379のPoC• 以下は脆弱なソース // /var/data にユーザアップロードファイルが格納される想定 <?php require_once File.php; function __autoload($class_name) { include $class_name . .php; } $uploaded_filename = /var/data/test.dat; $uploaded_file = File::readAll($uploaded_filename); if (PEAR::isError($uploaded_file)){ echo "error : $uploaded_file¥n"; }else{ echo "success : $uploaded_file¥n"; }• /var/data/test.dat の内容 /var/data/test2• /var/data/test2.php がインクルードされる Copyright © 2012 HASH Consulting Corp. 12
  13. 13. CVE-2011-3379の影響を受ける条件(AND条件)• __autoload関数によりクラスの自動ロード機能が定義されて いる• 直接・間接に、is_a関数に「攻撃者の入力した文字列」を渡 すことができる(PEARのFileクラスなど)• 以下のいずれかにより任意スクリプトを指定できること – アップロード機能などにより、サーバー上にPHPファイルを書き込み、 そのファイル名が推測できる – allow_url_includeが有効になっている• 影響を受ける環境はまれと推測される Copyright © 2012 HASH Consulting Corp. 13
  14. 14. #4 JVNDB-2012-001323(CVE-2012-0830)PHP の php_variables.c 内の php_register_variable_ex 関数における任意のコードを実行される脆弱性概要 PHP の php_variables.c 内の php_register_variable_ex 関数には、任意のコードを実行される脆弱性が存在します。 本脆弱性は CVE-2011-4885 に対する修正が不十分だったことによる脆弱性です。CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的影響を受けるシステム PHP 5.3.9想定される影響 第三者により、大量の変数を含むリクエストを介して、任意のコードを実行される可能性があります。 14
  15. 15. #番外 JVNDB-2011-003565(CVE-2011-4885)PHP におけるサービス運用妨害 (CPU 資源の消費) の脆弱性(hashdos)概要 PHP は、ハッシュ衝突を想定した制限を行わずにフォームパラメータのハッシュ値を算出するため、サービス運用妨害 (CPU 資源の消費) 状態となる脆弱性が存在します。CVSS による深刻度 (CVSS とは?) 基本値: 5.0 (警告) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): なし 完全性への影響(I): なし 可用性への影響(A): 部分的影響を受けるシステム PHP 5.3.9 未満想定される影響 第三者により、巧妙に細工されたパラメータを大量に送信されることで、サービス運用妨害(CPU 資源の消費) 状態にされる可能性があります。 15
  16. 16. http://blog.tokumaru.org/2011/12/webdoshashdos.html Copyright © 2012 HASH Consulting Corp. 16
  17. 17. #5 JVNDB-2011-001388(CVE-2012-0831)PHP における SQL インジェクション攻撃を行われる脆弱性概要 PHP は、環境変数のインポート中の magic_quotes_gpc ディレクティブへの一時的変更を適切 に処理しないため、容易に SQL インジェクション攻撃を行われる脆弱性が存在します。CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 アプリケーション側 可用性への影響(A): 部分的 でSQLインジェク影響を受けるシステム ション対策をしてい PHP 5.3.10 未満 れば問題ない想定される影響 第三者により、main/php_variables.c、sapi/cgi/cgi_main.c、および sapi/fpm/fpm/fpm_main.c に関連する巧妙に細工された要求を介して、容易に SQL インジェ クション攻撃を行われる可能性があります。 17
  18. 18. 勝手に訂正: 「PHP における SQL インジェクション攻 撃を行われる脆弱性 (JVNDB-2012-001388)」 http://co3k.org/blog/25 より引用 18
  19. 19. #6 JVNDB-2012-002235(CVE-2012-1823)PHP-CGI の query string の処理に脆弱性概要 PHP には、CGI として使用される設定において query string をコマンドラインオプションとして認識してしま う脆弱性が存在します。CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的影響を受けるシステム PHP version 5.4.2 より前のバージョン PHP version 5.3.12 より前のバージョン PHP の開発者によると、本脆弱性の修正を含む更なるリリースを予定しているとのことです。 そのため、影響を受けるシステムに関する情報が今後変更される可能性があります。想定される影響 遠隔の第三者によって、php スクリプトの内容を取得されたり、サービス運用妨害 (DoS) 攻撃を受けたり、 ウェブサーバの権限で任意のコードを実行されたりする可能性があります。 19
  20. 20. #7 JVNDB-2012-002392(CVE-2012-2311)PHP の sapi/cgi/cgi_main.c における任意のコードを実行される脆弱性概要 PHP の sapi/cgi/cgi_main.c は、CGI スクリプトとして設定される際、%3D 文字列を含み = (等号) 文字を含まないクエリ文字列を適切に処理しないため、任意のコードを実行される脆弱 性が存在します。 本脆弱性は、CVE-2012-1823 に対する修正が不十分だったことによる脆弱性です。CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 低 攻撃前の認証要否: 不要 機密性への影響(C): 部分的 完全性への影響(I): 部分的 可用性への影響(A): 部分的影響を受けるシステム PHP 5.4.3 未満の 5.4.x PHP 5.3.13 未満想定される影響 第三者により、クエリ文字列内にコマンドラインオプションを配置することで、任意のコードを実行 される可能性があります。 20
  21. 21. CVE-2012-2311のPoC allow_url_include=On auto_prepend_file=php://input<?php readfile(‘/etc/passwd’); ?> Copyright © 2012 HASH Consulting Corp. 21
  22. 22. 飽きてきたので、この辺で… Copyright © 2012 HASH Consulting Corp. 22
  23. 23. とりあえずのまとめ• PHPの高危険度脆弱性は多いが、影響を受ける局面が限ら れるものが多い• アプリケーションが、当該脆弱性の影響を受けるか、外部か らは判別しにくい• アプリケーションやフレームワークの脆弱性の原因となった 場合、外部からの攻撃が容易となる• IPA、JPCERT/CC、セキュリティ専門家の情報をウォッチし、 「騒ぎ出したら」急いで対処の準備をすること Copyright © 2012 HASH Consulting Corp. 23
  24. 24. 脆弱性対処のアプローチ• 正当的な方法 – 脆弱性情報が出る毎に影響を評価し、対処方法を決める – 影響が大きく、回避策がある場合は、まず回避策を適用する – パッチ、PHP新バージョンのアプリケーションに対する影響をテスト する – 本番環境にパッチ適用、バージョンアップ• Linuxディストリビューションのパッチに任せる – 基本的に、ディストリビューションのパッチが出るのを待って適用す る – テスト環境でパッチの影響を調べる (えいやっ! で当ててしまうのもあり) – 高危険度で攻撃が容易、かつパッチが間に合わない脆弱性につい ては、回避策を適用する Copyright © 2012 HASH Consulting Corp. 24
  25. 25. 鉄則2: Ajaxの脆弱性対処をしよう Copyright © 2012 HASH Consulting Corp. 25
  26. 26. とある入門書のサンプル 26よくわかるJavaScriptの教科書、たにぐちまこと著、2012 P228より引用
  27. 27. この本です 27
  28. 28. 動かしてみる 28
  29. 29. 結果 29
  30. 30. JSON作成をPHPに生成されるJSON[{"image":"img¥/1.jpg","image_big":"img¥/1_big.jpg","caption":"¥u30ad¥u30e3¥u30d7¥u30b7¥u30e7¥u30f31"}] 30
  31. 31. 結果 31
  32. 32. データにJavaScriptを入れてみる生成されるJSON[{"image":"img¥/1.jpg","image_big":"img¥/1_big.jpg","caption":"¥u30ad¥u30e3¥u30d7¥u30b7¥u30e7¥u30f31<script>alert(1)<¥/script>"}] 32
  33. 33. 結果 33
  34. 34. 脆弱性の原因と対策• htmlメソッドによりHTMLテキストを設定しているにも関わら ず、データをHTMLエスケープしていない• ただし、元文献は固定テキストなので、必ずしも脆弱性とは 言えない• HTMLエスケープするタイミングは、以下の候補がある – ブラウザでレンダリングする箇所 – JSONを組み立てる段階で、あらかじめHTMLエスケープしておく Copyright © 2012 HASH Consulting Corp. 34
  35. 35. 次の話題evalインジェクション Copyright © 2012 HASH Consulting Corp. 35
  36. 36. JSON解釈をevalでやってみる 36
  37. 37. JSON作成も自前で<?php $image = img/1.jpg; $image_big = img/1_big.jpg; $caption = キャプション2; $a = [{"image":" . $image . ","image_big":" . $image_big . ","caption":" . $caption . "}]; echo $a; 生成されるJSON [{"image":"img/1.jpg","image_big":"img/1_b ig.jpg","caption":"キャプション2 "}] 37
  38. 38. 結果 38
  39. 39. データにJavaScriptを入れてみる<?php $image = img/1.jpg; $image_big = img/1_big.jpg; $caption = キャプション2x"+alert("1")+"; $a = [{"image":" . $image . ","image_big":" . $image_big . ","caption":" . $caption . "}]; echo $a; 生成されるJSON [{"image":"img/1.jpg","image_big": "img/1_big.jpg","caption": "キャプション2x"+alert("1")+""}] 39
  40. 40. 結果 40
  41. 41. 脆弱性の原因と対策• JSON/JavaScriptとしての適切なエスケープを怠っているこ とが根本原因• 根本単位策:JSON生成を自前でしないで、信頼できるライブ ラリを用いる• 保険的対策(強く推奨):evalでJSONを解釈しない。 Copyright © 2012 HASH Consulting Corp. 41
  42. 42. 次の話題json.phpを直接ブラウズしてみる Copyright © 2012 HASH Consulting Corp. 42
  43. 43. データを少しいじりましょう Copyright © 2012 HASH Consulting Corp. 43
  44. 44. さまざまなブラウザでの結果 Copyright © 2012 HASH Consulting Corp. 44
  45. 45. で、IE9は?Copyright © 2012 HASH Consulting Corp. 45
  46. 46. 大丈夫なのかCopyright © 2012 HASH Consulting Corp. 46
  47. 47. でも、だめhttp://example.jp/json.php/a.html Copyright © 2012 HASH Consulting Corp. 47
  48. 48. Copyright © 2012 HASH Consulting Corp. 48http://d.hatena.ne.jp/hasegawayosuke/20110106/p1 より引用
  49. 49. Copyright © 2012 HASH Consulting Corp. 49http://d.hatena.ne.jp/hasegawayosuke/20110106/p1 より引用
  50. 50. X-Content-Type-Options: nosniff を入れてみる 生成されるJSON X-Content-Type-Options: nosniff Content-Length: 125 Content-Type: application/json; charset=utf8 [{"image":"img¥/1.jpg","image_big":"img¥/1_b ig.jpg","caption":"¥u30ad¥u30e3¥u30d7¥u30b7¥ u30e7¥u30f31<body onload=alert(1)>"}] Copyright © 2012 HASH Consulting Corp. 50
  51. 51. IE9だとOK(IE8以上)Copyright © 2012 HASH Consulting Corp. 51
  52. 52. IE7だとだめCopyright © 2012 HASH Consulting Corp. 52
  53. 53. 53
  54. 54. 対策• 必須対策(全ブラウザ共通) – レスポンスがブラウザによりtext/htmlと解釈されないようにする X-Content-Type-Options: nosniff Content-Type: application/json; charset=utf8• IE6,7対策 – IE7以前をサポートしない – ブラウザからの直接リクエストを受け付けない – 「<」、「>」などもエスケープする Copyright © 2012 HASH Consulting Corp. 54
  55. 55. Json_encodeのパラメータを追加生成されるJSON[{"image":"img¥/1.jpg","image_big":"img¥/1_big.jpg","caption":"¥u30ad¥u30e3¥u30d7¥u30b7¥u30e7¥u30f31¥u003Cbody onload=alert(1)¥u003E"}] Copyright © 2012 HASH Consulting Corp. 55
  56. 56. 今度は大丈夫Copyright © 2012 HASH Consulting Corp. 56
  57. 57. 次の話題はJSONハイジャック Copyright © 2012 HASH Consulting Corp. 57
  58. 58. Firefox3などで発現。現在の主要ブラ ウザでは対策されている Copyright © 2012 HASH Consulting Corp. 58
  59. 59. JSONハイジャックとは• JSONを罠サイトからscript要素で読み出す• 利用者のブラウザからは、正規のCookieが送信されるので、 認証ずみの状態でJSONが取得できる• なんらかの手法で、このJSONの中味を読むのがJSONハイ ジャック これは罠サイト <script> ここにJSONを読み出す仕掛けを置く // script要素で読み出したJSON [{"name":"Yamada", "mail":"yama@example.jp"}] </script> Copyright © 2012 HASH Consulting Corp. 59
  60. 60. サンプルスクリプト(罠)Copyright © 2012 HASH Consulting Corp. 60
  61. 61. 結果Copyright © 2012 HASH Consulting Corp. 61
  62. 62. Firefox11.0だと問題なし Copyright © 2012 HASH Consulting Corp. 62
  63. 63. Androidの標準ブラウザでハイジャック成功 Xperia ARC(SO-01C) Android 2.3.4 でキャプチャ Galaxy Nexus Android 4.0.3では取得できず Copyright © 2012 HASH Consulting Corp. 63
  64. 64. 対策• script要素からのリクエストにはレスポンスを返さないように する – XMLHttpRequestからのリクエストに特別なヘッダを入れておき、 JSON提供側でチェックするなど Jqueryの以下のヘッダを使っても良いかも X-Requested-With: XMLHttpRequest – POSTにのみ応答(個人的には好みません)• JSONデータを、JavaScriptとして実行できない形にする – 1行目に for(;;) ; を置く(個人的には好みません) – JSONデータをJavaScriptとして実行できない形にする(同上)• JSONハイジャック可能なブラウザを使わない(利用者側でと れる対策) Copyright © 2012 HASH Consulting Corp. 64
  65. 65. 鉄則3: 競合条件の脆弱性対処をしよう Copyright © 2012 HASH Consulting Corp. 65
  66. 66. ドリランド カード増殖祭りはこうしておこった…かも? Copyright © 2012 HASH Consulting Corp. 66
  67. 67. 67https://help.gree.jp/app/answers/detail/a_id/3231 より引用
  68. 68. こんな感じだった?必要なもの 携帯もしくはPCを二台 gleeアカウント二つ二台の機器でそれぞれのgleeアカウントでログインしてドリランド起動後お互いでトレードさせるトレード(受け取りはしない)が終わったら片方の機器はログアウトして二つの機器のアカウントを同じにするそれぞれトレード品受け取り画面にして受け取るボタン同時押しカード毎にID振って無いのかよ。。。。馬鹿じゃねぇの?>>277ちゃんとふってあるけど、トレード時にトレードされる側とする側でちゃんとアイテムIDが変わる仕様だったw 68 http://jin115.com/archives/51849925.html より引用
  69. 69. こんな感じだった?DBからトレード元のカードのデータを読み取る新しいIDをつけてトレード先に保存するトレード元のデータを削除する http://bakera.jp/ebi/topic/4722 より引用 69
  70. 70. 作ってみた// トレードするカードのidと新オーナーのidがパラメータ$item_id = (int)$_GET[item_id];$newowner = (int)$_GET[newowner];// カード情報を取得$stmt = $pdo->query( "SELECT * FROM cards WHERE item_id=$item_id");$row = $stmt->fetch(PDO::FETCH_ASSOC);$kind = $row[kind];$owner_id = $row[owner_id];// トレード後のカードを作成$stmt = $pdo->exec("INSERT INTO cards VALUES (NULL, $kind,". "$newowner, $item_id, $owner_id, NOW())");// 元のカードを削除$stmt = $pdo->exec( "DELETE FROM cards WHERE item_id= $item_id ");※デモスクリプトはプレースホルダをちゃんと使っています! Copyright © 2012 HASH Consulting Corp. 70
  71. 71. DEMOCopyright © 2012 HASH Consulting Corp. 71
  72. 72. 中ではこうなったCopyright © 2012 HASH Consulting Corp. 72
  73. 73. 対策• トランザクションを使う – PDOの場合は、begeinTransaction ~ commit / rollbackの間• ロック(排他制御) – SELECT … FOR UPDATE など• 上記の両方が必須 – トランザクションを使うだけでは排他制御にならない場合が多い 厳密にはDB依存 および モードに依存• 「クリティカルセクション」に注意 – このスクリプトの場合は、SELECT ~ DELETE FROMまではクリテ ィカルセクションであり、同一カードIDについては並行動作してはい けない• ちゃんとRDBを基礎から勉強しよう Copyright © 2012 HASH Consulting Corp. 73
  74. 74. トランザクションと行ロックで対策try { $pdo->beginTransaction(); $item_id = (int)$_GET[item_id]; $stmt = $pdo->query( "SELECT * FROM cards WHERE item_id=$item_id FOR UPDATE"); $row = $stmt->fetch(PDO::FETCH_ASSOC); if (! $row) throw new DataNotFoundException(); $kind = $row[kind]; $owner_id = $row[owner_id]; $stmt = $pdo->exec("INSERT INTO cards VALUES (NULL, $kind,". "$newowner, $item_id, $owner_id, NOW())"); $stmt = $pdo->exec( "DELETE FROM cards WHERE item_id=$item_id"); $pdo->commit();} catch (DataNotFoundException $e) { $pdo->rollback();} catch (Exception $e) { // ……※上記は概要でありデモスクリプトはプレースホルダをちゃんと使っています! Copyright © 2012 HASH Consulting Corp. 74
  75. 75. 中ではこうなるCopyright © 2012 HASH Consulting Corp. 75
  76. 76. 鉄則4:htmlspecialcharsの使い方2012 Copyright © 2012 HASH Consulting Corp. 76
  77. 77. htmlspecialcharsの使い方• PHPのリファレンスからstring htmlspecialchars ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = ‘UTF-8’ [, bool $double_encode = true ]]] )• 属性値をダブルクォートで囲むことにすれば、第2引数はデフ ォルト値( ENT_COMPAT )で問題ない• PHP5.4以降、文字エンコーディングのデフォルト(第3引数) はUTF-8になった。mbstring.internal_encodingがUTF-8の 場合は指定しなくてもよくなった – PHP5.4限定というのも難しいので当面は第3引数明示した方がよ い Copyright © 2012 HASH Consulting Corp. 77
  78. 78. 鉄則5:escapashellcmdは使わないこと Copyright © 2012 HASH Consulting Corp. 78
  79. 79. escapeshellcmdは仕様がおかしい• escapeshellcmdはコマンドライン全体をまるっと指定して得スープする ことを意図している• しかし、パラメータ中に空白があった場合、パラメータの区切りが区別 できない• すなわち、escapeshellcmdは、本質的にパラメータインジェクションの 危険性がある – 例: $cmd = grep . $_POST[’key’] . /var/data/data.txt; $escaped_command = escapeshellcmd($cmd); system($escaped_command); – keyに下記を与えると : /etc/passwd – 以下が実行される grep : /etc/passwd /var/data/data.txt• 対策:escapeshellargを使う Copyright © 2012 HASH Consulting Corp. 79
  80. 80. 鉄則6: SQLインジェクションの対処 Copyright © 2012 HASH Consulting Corp. 80
  81. 81. SQLインジェクション• SQLインジェクションとは、 WHERE句に or ’a’=’a’ を追加する攻撃…ではない• 多くの場合、SQL文の後半を自由に改変できる – WHERE句の改変 – UNION SELECTの追加 – …• DB内の任意テーブルの情報を取得可能 – 大規模な情報漏洩につながる• MS SQLやPostgreSQLの場合、第2、第3のSQL文を追加 できる(複文の実行) – 複文が実行できる場合、データの改変、追加、削除が可能 Copyright © 2012 HASH Consulting Corp. 81
  82. 82. SQLインジェクション対策• プレースホルダを用いてSQL文を呼び出す…の一択 – エスケープはややこしすぎる• DB接続の際に文字エンコーディングを指定すること• (できれば)静的プレースホルダを用いること• 安全なSQLの呼び出し方を良く読むこと(無料です) Copyright © 2012 HASH Consulting Corp. 82
  83. 83. 鉄則7: クロスサイト・スクリプティングの 対処 Copyright © 2012 HASH Consulting Corp. 83
  84. 84. クロスサイトスクリプティング(XSS)とは• XSSは、ブラウザ上でalertを表示する攻撃…ではない• 攻撃者が、一般利用者のブラウザ上で、勝手なJavaScriptを 実行できる脆弱性 / 攻撃手法• それって、ウイルス? – XSS自体はウイルスではないが、XSS脆弱性を悪用してウイルス の一種(ワーム)を作ることはできる – 不正確だが「ウイルスのように凶悪なもの」という理解はあり• 対策は、HTMLのエスケープ – これが複雑 Copyright © 2012 HASH Consulting Corp. 84
  85. 85. HTMLの構成要素Copyright © 2012 HASH Consulting Corp. 85
  86. 86. HTMLエスケープの概要場所 説明 エスケープの概要要素内容(通常の タグと文字参照が解釈さ 「<」と「&」を文字参照にテキスト) れる「<」で終端 文字参照が解釈される 属性値を「”」で囲み、「”」と属性値 引用符で終端 「&」を文字参照に URLの形式を検査してから属性値(URL) 同上 属性値としてのエスケープ JavaScriptとしてエスケープイベントハンドラ内 同上 してから属性値としてのエスの文字列リテラル ケープ JavaScriptとしてのエスケーscript要素内の文 タグも文字参照も解釈さ プおよび「</」が出現しないよ字列リテラル れない。「</」により終端 う考慮 Copyright © 2012 HASH Consulting Corp. 86
  87. 87. 鉄則8: クロスサイト・リクエスト・フォージ ェリの対処 Copyright © 2012 HASH Consulting Corp. 87
  88. 88. クロスサイト・リクエスト・フォージェリの対処• クロスサイト・リクエスト・フォージェリ(CSRF)とは – Webアプリケーションの「機能」を勝手に実行させられる – サーバー側の作用(更新、送金、投稿、削除…)に限られる• 勝手に実行させられるのは、「サーバー側に元々ある機能」 – SQLインジェクションは任意のSQLが実行可能 – XSSは任意のJavaScriptが実行可能…という点で異なる• でも、XSSとCSRFは、なんか、似ている Copyright © 2012 HASH Consulting Corp. 88
  89. 89. 反射型XSSとCSRFの比較 徳丸本P147より引用 Copyright © 2012 HASH Consulting Corp. 89
  90. 90. クリックジャッキング攻撃• 機能を勝手に実行させられるという点でCSRFと類似• ターゲットの画面をiframe上で「透明に」表示する• その下にダミーの画面を表示させる。ユーザにはダミーの画 面が透けて見える• 利用者がダミーの画面上のボタンを押すと、実際には全面の ターゲット画面のボタンが押される 本当の画面(前面、透明) ダミーの画面(後面) Copyright © 2012 HASH Consulting Corp. 90
  91. 91. CSRF/クリックジャッキングの対策• CSRF対策はトークンによる方法に統一しよう – 「ワンタイムトークン」である必要はない• クリックジャッキングされると困るページには、X-FRAME-OPTIONSヘッダを指定す る(徳丸本P63) – frame/iframeを禁止して良い場合 header(X-FRAME-OPTIONS, DENY); – frame/iframeを禁止できないが単一ホストの場合 header(X-FRAME-OPTIONS, SAMEORIGIN);• CSRF対策のトークン発行しているページが対象となる入力画面 実行画面 メールアドレス foo@pexample.jp メールアドレスアドレスを 変更しました 変更header(X-FRAME-OPTIONS, DENY); セッション等に保存したtokeとhiddenの… token値を比較)<input type="hidden" name="token" value="a89daf89af0…"> Copyright © 2012 HASH Consulting Corp. 91
  92. 92. 鉄則9: パスワードの保存はソルトつき ハッシュ、できればストレッチングも Copyright © 2012 HASH Consulting Corp. 92
  93. 93. どうして暗号化ではなくてハッシュなの?• 暗号化の場合、鍵の管理が難しい• アプリケーションは鍵を使わなければならないが、攻撃者には鍵を見せ たくない• PSNの事件では、権限昇格されたことになっているので、暗号鍵も盗ま れていると想定せざるを得ない• ハッシュだと鍵を使わないので、鍵管理のわずらわしさがない• パスワードをサイト管理者にも知られたくないというニーズも – 暗号化されたパスワードだと、サイト管理者やヘルプデスク担当者がパスワードを 知り得るのが嫌だ – ヘルプデスクに見せないようにするには、サポート用画面の機能次第で可 – 管理者の悪事は総合的な対策が必要で、パスワードの問題だけではない• PCI-DSS2.0 8.4項には「8.4 強力な暗号化を使用して、すべてのシス テムコンポーネントでの伝送および保存中のすべてのパスワードを読 み取り不能にする」とあり、ハッシュを求めてはいない Copyright © 2012 HASH Consulting Corp. 93
  94. 94. ハッシュで保存されたパスワードは本当に安全なの?• 一般的に、(暗号論的)ハッシュ値から平文を「復元する」ことはできな い – 「password」のMD5ハッシュ: 5f4dcc3b5aa765d61d8327deb882cf99• しかし、パスワードの場合は特別な事情がある• 例:4桁の暗証番号をハッシュ値で保存している場合 – 全ての可能性は1万通りしかないのだから、総当たりで確認すれば、平文の暗証 番号はすぐに判明する• 原理は8桁パスワードでも同じ• ハッシュ保存の場合、アルゴリズムは攻撃者が知っている前提で安全 な設計とする – 平文パスワード以外は、すべて「ばれている」想定を置く• 攻撃者にとって未知であることが保証された情報があれば、それを鍵と して暗号化すればよい。現実にはそのような保証がないから暗号化を 用いない Copyright © 2012 HASH Consulting Corp. 94
  95. 95. Saltってなに?• ソルト(Salt)とは、ハッシュの元データ(パスワード)に追加する文字列• 見かけのパスワードの長さを長くする – 公開されたレインボーテーブルは10文字までのパスワードに対応しているので、 パスワードとソルトを合わせて20文字以上にしておけば、当面は大丈夫• ユーザ毎にソルトを変えることで、パスワードが同じでも、異なるハッシ ュ値が得られる• ソルトの要件 – ある程度の長さを確保すること – ユーザ毎に異なるものにすること• ソルトには乱数を用いることが多いが、乱数が必須というわけではない (暗号論的に安全な乱数である必要はもちろんない)• ソルトは秘密情報ではない。ソルトは、通常ハッシュ値と一緒に保存す る Copyright © 2012 HASH Consulting Corp. 95
  96. 96. Stretchingってなに?• ストレッチング(Stretching)とは、ハッシュの計算を繰り返すこと• ハッシュの計算を遅くすることにより、辞書攻撃や総当たり攻撃に対抗 する• 1万回ストレッチすると、「 GPU で 7 時間である」が7万時間になる計算 – 7万時間 = 2916日 = 約8年• 「悪い」パスワードまで救えるわけではない – 「password」というパスワードをつけていたら、100万回ストレッチしてもすぐに解 読されてしまう• 十分長いパスワードをつけてもらえば、ストレッチングは必要ない – 1文字パスワードを長くすることは、約100回のストレッチングに相当する。パスワ ードを2文字長くしてもらえば… – でも、中々難しいのでストレッチングの値打ちがある• ストレッチングはメリットとデメリットがあるので、導入の有無と回数をよ く検討すること Copyright © 2012 HASH Consulting Corp. 96
  97. 97. 鉄則10: 他にもたくさんある 脆弱性の対処 Copyright © 2012 HASH Consulting Corp. 97
  98. 98. 徳丸本に載っている主な脆弱性4.3.1 クロスサイト・スクリプティング4.4.1 SQLインジェクション4.5.1 クロスサイト・リクエストフォージェリ(CSRF)4.6.2 推測可能なセッションID4.6.3 URL埋め込みのセッションID4.6.4 セッションIDの固定化4.7.1 オープンリダイレクタ脆弱性4.7.2 HTTPヘッダ・インジェクション 短時間ではとても4.8.2 クッキーのセキュア属性不備 説明できません4.9.2 メールヘッダ・インジェクション脆弱性4.10.1 ディレクトリ・トラバーサル脆弱性4.10.2 意図しないファイル公開4.11.1 OSコマンド・インジェクション4.12.2 アップロードファイルによるサーバー側スクリプト実行4.12.3 ファイルダウンロードによるクロスサイト・スクリプティング4.13.1 ファイルインクルード攻撃4.14.1 evalインジェクション4.15.1 競合状態の脆弱性 Copyright © 2012 HASH Consulting Corp. 98
  99. 99. 結論徳丸本を買ってよく読めご清聴ありがとうございました Copyright © 2012 HASH Consulting Corp. 99

×