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

1. 安全なPHPアプリケーションの作り方2014 2014年10月11日徳丸浩

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. • PHPの脆弱性にどうつきあう? – PHP自身の脆弱性対策の考え方 – PHPのリリースサイクル • アプリケーションの脆弱性を対策しよう – クロスサイト・リクエストフォージェリ(CSRF) – クロスサイト・スクリプティング(XSS) – SQLインジェクション – HTTPヘッダインジェクション – セッション固定 • まとめ Copyright © 2008-2014 HASH Consulting Corp. All rights reserved アジェンダ 3

4. PHPの脆弱性にどうつきあう? 4

5. 例えば、PHPを避ける出典: IPA「セキュアプログラミング講座」 5

6. • 「PHPを避ける」という意見は下記による – PHP自体に脆弱性が多い – register_globalsのような脆弱性を生みやすい機構がある • しかし、いずれも解消されており、「PHPに脆弱性が多い」というのは昔の話…神話のようなもの • PHPのバージョンアップの度にがっかりほっとしている • しかし、たまにすごい脆弱性が出るのも事実 – 例: PHP-CGI脆弱性(CVE-2012-1823) – どの言語でもあり得ることですけどね • 脆弱性対処の基本はPHP自体のバージョンアップだが… • 実は、それが一番大変 6 PHP自身の脆弱性対策の考え方

7. PHPの脆弱性を狙った攻撃～PHP-CGI脆弱性(CVE-2012-1823)～ 7

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. CVE-2012-1823によるリモートスクリプト実行 • この脆弱性により、外部からスクリプトを実行できる攻撃手法がある • PHPのオプションとして以下を指定 allow_url_include=On 外部からのincludeを有効にする auto_prepend_file=php://input 予めincludeするファイルとしてPOSTした内容を指定続きはデモで Copyright © 2012-2014 HASH Consulting Corp. 9

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. 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. 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. ハウジング、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

15. クロスサイト・リクエストフォージェリ(CSRF) 15

16. CSRFはなぜ危険か? • CSRFとは… – FORMのACTIONってクロスドメインで指定できるよね – だから、FORMを踏ませる罠が作れるよね – 投稿、パスワード変更、購入、設定変更… – 攻撃者はFORMの実行結果は見られないので、DB更新や削除などが問題となる • 最悪ケースの危険性は、SQLインジェクションやXSSほどではない • 脆弱性のあるページの機能の悪用にとどまる • 脆弱性の発見が容易 • 脆弱性の悪用が容易 • 実際に悪用されている Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 16

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

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. クロスサイト・スクリプティング(XSS) 21

22. XSSはなぜ危険か? • XSSは、 – 利用者（被害者）のブラウザ上で – 攻撃対象のドメイン（オリジン）で – 攻撃者が自由にJavaScriptを実行できる • これって、ウイルス? – ウイルスではないが、結果としてウイルスと同じような被害 – XSSを悪用したウイルス（ワーム）はいくつかある • ブラウザを乗っ取られたのと同じ – 影響範囲はXSS脆弱性のあるページと同じドメイン（オリジン） – 同一オリジン上はすべてのページが影響を受ける ※オリジン=ホスト名+スキーム+ポート番号 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 22

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. 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. 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. 壊れた文字エンコーディングによる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. SQLインジェクション 27

28. SQLインジェクションはなぜ危険か? • 攻撃対象サーバーのデータベースについて、攻撃者が自由にSQL呼び出しができる • データベースの中身の漏洩、改ざんが起こる • 脆弱性のあるテーブルだけでなく、データベース内のすべてのデータが漏洩できる。場合によっては改ざんも • 使い勝手の良い攻撃ツール（SQL注入工具:名目は診断ツール）が安価で流通している • SQL注入工具はExcel使うより簡単だよ Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 28

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. エスケープしているのになぜ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. • 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. 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. 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

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. 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. HTTPヘッダインジェクション 37

38. HTTPヘッダインジェクション https://www.ipa.go.jp/security/vuln/websecurity.html より引用38

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. 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

42. セッションIDの固定化 https://www.ipa.go.jp/security/vuln/websecurity.html より引用42

43. • 攻撃者が、他のサイト利用者（被害者）のブラウザにセッションＩＤを強制する方法がある – URL埋め込みのセッションＩＤ（携帯電話向けサイトに多い） – 地域型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. • 影響 – なりすまし全般の影響 – 個人情報の漏洩 – 被害者のアカウントでの投稿、情報変更 – 被害者のアカウントでの退会処理 • 対策 – ログイン直後にセッションIDを変更する session_start(); session_regenerate_id(true); 44 セッションIDの固定化の影響・対策 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved

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. • アプリケーションの脆弱性を対策しよう – 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

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

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

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

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

Similar to 安全なPHPアプリケーションの作り方2014(20)

More from Hiroshi Tokumaru

More from Hiroshi Tokumaru(16)

Recently uploaded

Recently uploaded(12)

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