安全なPHPアプリケーションの作り方2014

44,698 views
44,949 views

Published on

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

No Downloads
Views
Total views
44,698
On SlideShare
0
From Embeds
0
Number of Embeds
10,212
Actions
Shares
0
Downloads
1
Comments
0
Likes
193
Embeds 0
No embeds

No notes for slide

安全なPHPアプリケーションの作り方2014

  1. 1. 安全なPHPアプリケーションの作り方2014 2014年10月11日 徳丸浩
  2. 2. 徳丸浩の自己紹介 • 経歴 – 1985年京セラ株式会社入社 – 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – HASHコンサルティング株式会社代表http://www.hash-c.co.jp/ – 独立行政法人情報処理推進機構非常勤研究員http://www.ipa.go.jp/security/ – 著書「体系的に学ぶ安全なWebアプリケーションの作り方」(2011年3月) – 技術士(情報工学部門) Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 2
  3. 3. • PHPの脆弱性にどうつきあう? – PHP自身の脆弱性対策の考え方 – PHPのリリースサイクル • アプリケーションの脆弱性を対策しよう – クロスサイト・リクエストフォージェリ(CSRF) – クロスサイト・スクリプティング(XSS) – SQLインジェクション – HTTPヘッダインジェクション – セッション固定 • まとめ Copyright © 2008-2014 HASH Consulting Corp. All rights reserved アジェンダ 3
  4. 4. PHPの脆弱性にどうつきあう? 4
  5. 5. 例えば、PHPを避ける 出典: IPA「セキュアプログラミング講座」 5
  6. 6. • 「PHPを避ける」という意見は下記による – PHP自体に脆弱性が多い – register_globalsのような脆弱性を生みやすい機構がある • しかし、いずれも解消されており、「PHPに脆弱性が多 い」というのは昔の話…神話のようなもの • PHPのバージョンアップの度にがっかりほっとしている • しかし、たまにすごい脆弱性が出るのも事実 – 例: PHP-CGI脆弱性(CVE-2012-1823) – どの言語でもあり得ることですけどね • 脆弱性対処の基本はPHP自体のバージョンアップだが… • 実は、それが一番大変 6 PHP自身の脆弱性対策の考え方
  7. 7. PHPの脆弱性を狙った攻撃 ~PHP-CGI脆弱性(CVE-2012-1823)~ 7
  8. 8. CVE-2012-1823とは • PHPをCGIとして動作させる場合に発生 – CGIとしてPHPを動かす環境はレンタルサーバーに多い – PHP5.4.2以前で影響あり • CGIの仕様として、クエリ文字列に= が含まれない場合、クエリ文字列が CGIプログラムのコマンド引数として渡される 例: http://example.jp/test.cgi?foo+bar+baz ↓ 以下のコマンドが実行される test.cgi foo bar baz • この仕様の悪用により、クエリ文字列からPHPのオプションを指定可能 • 例: phpinfo.php?-s の呼び出しにより、php-cgi –s (ソース表示) が実行 Copyright © 2012-2014 HASH Consulting Corp. 8
  9. 9. CVE-2012-1823によるリモートスクリプト実行 • この脆弱性により、外部からスクリプトを実行できる攻撃手法がある • PHPのオプションとして以下を指定 allow_url_include=On 外部からのincludeを有効にする auto_prepend_file=php://input 予めincludeするファイルとしてPOSTした内容を指定 続きはデモで Copyright © 2012-2014 HASH Consulting Corp. 9
  10. 10. PHPのリリースサイクル • Yearly release cycle – 3 years release life cycle – 2 years bug fixes only – 1 year security fixes only • 下図のように、PHP5.x(2番目の数字)を使い続けるのは、 2~3年が限度 https://wCoipkyir.igphht ©p .2n00e8t-/2r0f1c4 /HrAeSlHe Caosnesupltrinog cCeorsps. Aよll riりgh引ts re用served 10
  11. 11. PHP 5.3 のEnd of Lifeのアナウンス PHP5.3はPHP5.3.29 (2014年8月14日) が最終バージョンとなり、PHP5.3はサポート終了 http://php.php.net/net/archive/archive/2014.2014.php#php#id2014-id2014-08-14-08-1 よ14-り引1よ用 り引用11
  12. 12. PHPのバージョンアップにつきあうには? • サイトリリース前にバージョンアップ方針を決める • 基本的な選択肢 – PHPのバージョンアップにとことん付き合う – 影響を受ける脆弱性がある場合のみバージョンアップする – LinuxディストリビューションのパッケージとしてPHPを導入し て、パッチを適用する • PHP以外に、フレームワークやDB、ライブラリ等も • サポート計画を検討する – PHPをRedHat/CentOSのパッケージで導入すれば10年サポート – Redhat5/Centos5のPHP5.1.6もメンテナンスされているよ ※2017年3月31日まで – 途中でメジャーバージョンアップする計画を立てておく • 他のソフトウェアのサポートライフサイクルにも注意 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 12
  13. 13. ハウジング、IaaS、PaaS、SaaSと脆弱性対処 ハウジングIaaS/VPS PaaS SaaS Copyright © 2012-2014 HASH Consulting Corp. 13 アプリケーション アプリケーション 基盤(API) ミドルウェア (PHP) OS コンピュータ (BIOS等) アプリケーション アプリケーション 基盤(API) ミドルウェア (PHP) OS コンピュータ (HV等) アプリケーション アプリケーション 基盤(API) ミドルウェア (PHP) OS コンピュータ (HV等) アプリケーション アプリケーション 基盤(API) ミドルウェア (PHP) OS コンピュータ (HV等) 利用者が脆弱性対処クラウドが脆弱性対処
  14. 14. アプリケーションの脆弱性を対 策しよう 14
  15. 15. クロスサイト・リクエストフォージェリ(CSRF) 15
  16. 16. CSRFはなぜ危険か? • CSRFとは… – FORMのACTIONってクロスドメインで指定できるよね – だから、FORMを踏ませる罠が作れるよね – 投稿、パスワード変更、購入、設定変更… – 攻撃者はFORMの実行結果は見られないので、DB更新や削除など が問題となる • 最悪ケースの危険性は、SQLインジェクションやXSSほ どではない • 脆弱性のあるページの機能の悪用にとどまる • 脆弱性の発見が容易 • 脆弱性の悪用が容易 • 実際に悪用されている Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 16
  17. 17. CSRFによる成りすまし投稿 17 ③被害者のブラウザ経由で 掲示板に書き込み 掲示板の書き込みログ は被害者のIPアドレス Copyright © 2008-2014 HASH Consulting Corp. All rights reserved
  18. 18. 005: if (isset($_SESSION['id']) && $_SESSION['time'] + 3600 > time()) { 006: // ログインしている省略 014: } else { 015: // ログインしていない 016: header('Location: login.php'); exit(); 017: } 018: 019: // 投稿を記録する 020: if (!empty($_POST)) { 021: if ($_POST['message'] != '') { 022: $sql = sprintf('INSERT INTO posts SET member_id=%d, message="%s", reply_post_id=%d, created=NOW()', 023: mysql_real_escape_string($member['id']), 024: mysql_real_escape_string($_POST['message']), 025: mysql_real_escape_string($_POST['reply_post_id']) 026: ); 027: mysql_query($sql) or die(mysql_error()); 028: 029: header('Location: index.php'); exit(); 030: } 031: } 18 日本で一番売れているPHP教科書のサンプル CSRF脆弱性 対策していない 続きはデモで Copyright © 2008-2014 HASH Consulting Corp. All rights reserved
  19. 19. CSRF対策の方法は? • 色々な対策が知られている • トークンによるもの • 再認証 • Refererのチェック • Captcha • … • 実際は、トークン一択と考えて良い Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 19
  20. 20. トークンはどうやって生成する? • ワンタイムトークンである必要はない – セッション毎に固定で良い – いわゆるワンタイムトークンだと処理が複雑になる • セッション毎に一度「安全な乱数生成器」で生成する – openssl_random_pseud_bytes() ← PHP5.3以降オススメ – /dev/urandom から読み込み(UNIX/Linux) $rand = file_get_contents(‘/dev/urandom’, false, NULL, 0, 24); $token = bin2hex($rand); • type=hiddenなinputとセッションの両方に書いておい て、両者を比較する。違っていたらエラー Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 20
  21. 21. クロスサイト・スクリプティング(XSS) 21
  22. 22. XSSはなぜ危険か? • XSSは、 – 利用者(被害者)のブラウザ上で – 攻撃対象のドメイン(オリジン)で – 攻撃者が自由にJavaScriptを実行できる • これって、ウイルス? – ウイルスではないが、結果としてウイルスと同じような被害 – XSSを悪用したウイルス(ワーム)はいくつかある • ブラウザを乗っ取られたのと同じ – 影響範囲はXSS脆弱性のあるページと同じドメイン(オリジン) – 同一オリジン上はすべてのページが影響を受ける ※オリジン=ホスト名+スキーム+ポート番号 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 22
  23. 23. • 先ほどのCSRF対策済みの掲示板で、なりすまし書き込み をやってみよう • 実行するスクリプトは下記のもの Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 23 XSSのデモ <script> var token = document.getElementsByName('token')[0].value; var req = new XMLHttpRequest(); req.open('POST', 'index.php'); req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); data = 'message=ぼくはまちちゃん!こんにちはこんにちは!!&token=‘ + token; req.send(data); </script>
  24. 24. XSSの対策 • 文脈に応じてHTMLエスケープ – エスケープするタイミングは表示の直前 – htmlspecialcharsの引数に注意 • 第2引数は、文脈により変えるか、ENT_QUOTES固定 • 第3引数はPHP内部の文字エンコーディングを指定 PHP5.3までのデフォルトはISO-8859-1 PHP5.4, 5.5のデフォルトはUTF-8 PHP5.6からはデフォルトとしてdefault_charset • 属性値はダブルクオートで囲む • レスポンスヘッダで文字エンコーディングを指定 – header('Content-Type: text/html; charset=UTF-8'); • JavaScriptの動的生成を避ける – HTML上に値を書いてJavaScriptから参照 – JavaScriptのエスケープは人類には難しすぎる Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 24
  25. 25. htmlspecialcharsの第3引数問題 • 昔は第3引数は指定しなくても良いように思われていた – PHP5.2.4以前はほとんど何もしなかった – PHP5.2.5以降で、少しチェックが入った htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか http://www.tokumaru.org/d/20090930.html • PHP5.2.5での時点では、不正な文字エンコーディング によるXSSが可能(CVE-2009-4142) – 回避策は、入力値の文字エンコーディングチェック • PHP5.2.10にて厳密な文字エンコーディングチェック – Thx 2 Moriyoshi, iwamot – RHEL5、CentOS5の標準パッケージ(PHP5.1.6)ではバックポー トされている – RHEL6以降、CentOS6以降、Ubuntu10.04以降は問題なし Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 25
  26. 26. 壊れた文字エンコーディングによるXSS <?php $a = htmlspecialchars($_GET['a'], ENT_QUOTES, 'Shift_JIS'); $b = htmlspecialchars($_GET['b'], ENT_QUOTES, 'Shift_JIS'); ?><body> <INPUT name=a value="<?php echo $a; ?>"><br> <INPUT name=b value="<?php echo $b; ?>"><br> </body> a=%F1&b=onmouseover%3dalert(document.cookie);// を入力すると、生成されるHTMLは… 0xF1 と" が合体して1文字に… <body> <INPUT name=a value="■><br> <INPUT name=b value="onmouseover%3dalert(document.cookie);//"><br> </body> 次の行のvalue=までが属性値として認識される RHEL5のPHP5.1.6でも、2010/1/13のパッチにて対応済み Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 26
  27. 27. SQLインジェクション 27
  28. 28. SQLインジェクションはなぜ危険か? • 攻撃対象サーバーのデータベースについて、攻撃者が自 由にSQL呼び出しができる • データベースの中身の漏洩、改ざんが起こる • 脆弱性のあるテーブルだけでなく、データベース内のす べてのデータが漏洩できる。場合によっては改ざんも • 使い勝手の良い攻撃ツール(SQL注入工具:名目は診断ツ ール)が安価で流通している • SQL注入工具はExcel使うより簡単だよ Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 28
  29. 29. 日本で一番売れているPHP教科書のサンプル 29 // ここまでで、認証済みであるこの検査が済んでいる $id = $_REQUEST['id']; // 投稿を検査する $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id)); $record = mysql_query($sql) or die(mysql_error()); $table = mysql_fetch_assoc($record); if ($table[‘member_id’] == $_SESSION[‘id’]) { // 投稿者の確認 // 投稿した本人であれば、削除 mysql_query('DELETE FROM posts WHERE id=' . mysql_real_escape_string($id)) or die(mysql_error()); } ここにSQLインジェクション しかし、DELETE FROM文 なので表示はない Copyright © 2008-2014 HASH Consulting Corp. All rights reserved
  30. 30. エスケープしているのになぜSQLインジェクション? $id = ’88-1’; で説明。これはエスケープ後も88-1 $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id)); ↓ 生成されるSQL文は、88-1が%dの整数化で88になるので SELECT * FROM posts WHERE id=88 mysql_query(‘DELETE FROM posts WHERE id=’ . mysql_real_escape_string($id)); ↓ 生成されるSQL文は、エスケープ後も88-1 のままなので DELETE FROM posts WHERE id=88-1 ※チェックはid=88で、削除されるのはid=88-1 すなわち、87が削除 される Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 30
  31. 31. • SQLインジェクションにより実行されるSQL文の例 DELETE FROM posts WHERE id=88-(SELECT id FROM members WHERE id LIKE char(49) ESCAPE IF(SUBSTR((SELECT email FROM members LIMIT 1,1),1,1)>='M', 'a', 'ab'))) • WHERE句の中88-(SELECT … WHERE …) • 中のWHERE句は LIKE 述語にESCAPE句がある • ESCAPE句はIF関数により、membersの1行目の1文字目が ’M’以上の場合’a’、それ以外の場合’ab’ • SQL文の文法上、ESCAPE句は1文字以外だとエラー • この結果を繰り返すことによって、対象文字列を絞り込む →ブラインドSQLインジェクション 31 SQL文のエラーが起こるか否かで情報を盗む 続きはデモで Copyright © 2008-2014 HASH Consulting Corp. All rights reserved
  32. 32. SQLインジェクション対策はプレースホルダで • プレースホルダとは SELECT * FROM books WHERE id=? • 静的プレースホルダと動的プレースホルダ – 静的: サーバー側で値をバインドする(エスケープは必要な い) – 動的: 呼び出し側で値をエスケープしてバインドする • 接続時に文字エンコーディングを指定する $db = new PDO('mysql:host=myhost;dbname=mydb;charset=utf8', DBUSER, DBPASS); • 列の型を意識する Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 32
  33. 33. PDOの文字エンコーディング認識問題 • new PDOのタイミングで文字エンコーディングを指定し ないとSQLインジェクションの可能性あり • PHP5.3.6まで、文字エンコーディングを指定する簡単 な方法がなかった! • 脆弱なスクリプトの例 <?php $dbh = new PDO('mysql:host=localhost;dbname=test', USERNAME, PASSWORD); $dbh->query("SET NAMES sjis"); $sth = $dbh->prepare("select * from test WHERE name=?"); $sth->setFetchMode(PDO::FETCH_NUM); $name = ... $sth->execute(array($name)); while ($data = $sth->fetch()) { var_dump($data); } Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 33
  34. 34. PDO+Shift_JISによるSQLインジェクション $nameとして「ソ' OR 1=1#」とした場合の実行結果: 本来エスケープの必要のない「ソ」が「ソ」とエスケープされ てしまい、SQLインジェクション脆弱性となる Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 34
  35. 35. $db = new PDO('mysql:host=myhost;dbname=mydb;charset=utf8', DBUSER, DBPASS); // エミュレーションモードOFF = 静的プレースホルダ $db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); // プレースホルダを使ってSQLを準備 $prepare = $db->prepare('SELECT * FROM example WHERE id = :id and language = :lang'); // 型を指定してbind (キャストはPDOのバグ対策) $prepare->bindValue(':id', (int) $int, PDO::PARAM_INT); $prepare->bindValue(':lang', $str, PDO::PARAM_STR); $prepare->execute(); 35 サンプルコード(PHP5.3.6以降) http://blog.a-way-out.net/blog/2013/12/18/pdo-prepare-statement- numeric-literal-part2/ を参考せさせていただきました
  36. 36. PHP5.3.5以前ではこうする… • PDOの文字エンコーディング指定機能は、Linuxディストリビュー ションではバックポートされていない – 脆弱性ではないという扱いらしい • 問題になるディストリビューションの例 – RHEL5 / CentOS5 (PHP5.1.6) – RHEL6 / CentOS6 (PHP5.3.3) – Ubuntu10.04LTS (PHP5.3.2) • 古いPHPの場合は以下のようにするとよい $dbh = new PDO('mysql:host=localhost;dbname=DBNAME;charset=cp932', USERNAME, PASSSWORD, array( PDO::MYSQL_ATTR_READ_DEFAULT_FILE => '/etc/mysql/my.cnf', PDO::MYSQL_ATTR_READ_DEFAULT_GROUP => 'client', PDO::ATTR_EMULATE_PREPARES => false, )); [client] default-character-set=cp932 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 36
  37. 37. HTTPヘッダインジェクション 37
  38. 38. HTTPヘッダインジェクション https://www.ipa.go.jp/security/vuln/websecurity.html より引用38
  39. 39. HTTPヘッダインジェクションのあるプログラム例 header(‘Location: ‘ . $_GET[‘url’]); 正常系の呼び出し url=http://example.jp/ 生成されるレスポンスヘッダ Location: http://example.jp/ 攻撃となる呼び出し url=http://example.jp/%0dSet-Cookie:+PHPSESSID=ABC 生成されるレスポンスヘッダ Location: http://example.jp/ Set-Cookie: PHPSESSID=ABC 改行により、 第2のヘッダができた! Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 39
  40. 40. HTTPヘッダインジェクションが成立する条件 • 以下の両方に該当する場合 – アプリケーション側でレスポンスヘッダとして出力する文字列 中に改行(0x0D, 0x0A)がないことをアプリケーション側で確 認していない – HTTPヘッダインジェクションの脆弱性があるPHPのバージョン を使用している • PHP5.1.2で改行チェックが入ったが、0x0D(キャリッ ジリターン)のチエックがなかった • HTTPヘッダインジェクション脆弱性がないバージョンは 下記の通り – PHP5.3.10以降、PHP5.4.0以降 – RHEL5以降、CentOS5以降、Ubuntu10.04LTS以降は、最新のパ ッチが当たっていれば問題ない Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 40
  41. 41. セッション固定 41
  42. 42. セッションIDの固定化 https://www.ipa.go.jp/security/vuln/websecurity.html より引用42
  43. 43. • 攻撃者が、他のサイト利用者(被害者)のブラウザにセッションI Dを強制する方法がある – URL埋め込みのセッションID(携帯電話向けサイトに多い) – 地域型JPドメイン名、都道府県型JPドメイン名のサイト (Cookie Monster Bug) – HTTPヘッダインジェクション、XSSなど他の脆弱性 – 異なるサブドメイン上にXSS脆弱なサイトがある sub.example.jp にXSS脆弱性があると、 www.example.jp のセッションIDまでセット可能になる – SSLを使ったサイト • 参考:HTTPSを使ってもCookieの改変は防げないことを実験で試してみた http://blog.tokumaru.org/2013/09/cookie-manipulation-is-possible-even-on- ssl.html • 攻撃者がセットしたセッションIDのまま利用者がログイン状態にな ると、攻撃者がログイン済みセッションIDが分かる 43 セッションIDの固定化の原理 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved
  44. 44. • 影響 – なりすまし全般の影響 – 個人情報の漏洩 – 被害者のアカウントでの投稿、情報変更 – 被害者のアカウントでの退会処理 • 対策 – ログイン直後にセッションIDを変更する session_start(); session_regenerate_id(true); 44 セッションIDの固定化の影響・対策 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved
  45. 45. RHEL5/RHEL6のPHP脆弱性対応状況 脆弱性CVE PHP 対応日RHEL5 (PHP5.1.6) RHEL6 (PHP5.3.3) Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 45 setcookieの display_errosにおけ るXSS CVE-2008-5814 5.2.7 2008/12/4 2009/4/6 -- htmlspecialchars マ ルチバイトCVE-2009-4142 5.2.12 2009/12/17 2010/1/13 -- hashdos CVE-2011-4885 5.3.9 2012/1/10 2012/1/18 2012/1/11 hashdos修正にともな う脆弱性CVE-2012-0830 5.3.10 2012/2/2 2012/2/2 2012/2/2 header関数CR 問題CVE-2011-1398 5.3.10 2012/2/2 2013/12/11 2013/2/20 PHP-CGI CVE-2012-1823 5.4.3 2012/5/8 2012/5/7 2012/5/7
  46. 46. • アプリケーションの脆弱性を対策しよう – SQLインジェクション – クロスサイト・スクリプティング(XSS) – クロスサイト・リクエストフォージェリ(CSRF) – … • プラットフォームの脆弱性を対策しよう – PHP自身の脆弱性対策 – CentOS5のPHP5.1.6でもよいので、パッチが提供されているこ とがとても重要 • PHP5.1.6をdisるのはやめてさしあげて! – 構築したその環境、今後5年間パッチが提供されますか? – bashの脆弱性等も同様に対応#shellshock Copyright © 2008-2014 HASH Consulting Corp. All rights reserved まとめ 46

×