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

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

徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – HASHコンサルティング株式会社 代表 – 独立行政法人情報処理推進機構 非常勤研究員 http://www.ipa.go.jp/security/ http://www.hash-c.co.jp/ – 著書「体系的に学ぶ 安全なWebアプリケーションの作り方」(2011年3月) – 技術士（情報工学部門） Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 2

• http://www.hash-c.co.jp/
• http://www.ipa.go.jp/security/

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

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

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

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

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

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

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

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://wiki.php.net/rfc/releaseprocess より引用 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 10

PHP 5.3 のEnd of Lifeのアナウンス PHP5.3はPHP5.3.29 (2014年8月14日) が最終バージョンとなり、PHP5.3はサポート終了 http://php.net/archive/2014.php#id2014-08-14-1より引用 http://php.net/archive/2014.php#id2014-08-14-1 より引用 11

• http://php.net/archive/2014.php#id2014-08-14-1

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

ハウジング、IaaS、PaaS、SaaSと脆弱性対処 ハウジング IaaS/VPS PaaS SaaS アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション 基盤(API) アプリケーション 基盤(API) アプリケーション 基盤(API) アプリケーション 基盤(API) ミドルウェア (PHP) ミドルウェア (PHP) ミドルウェア (PHP) ミドルウェア (PHP) OS OS OS OS コンピュータ (BIOS等) コンピュータ (HV等) コンピュータ (HV等) コンピュータ (HV等) 利用者が脆弱性対処 クラウドが脆弱性対処 Copyright © 2012-2014 HASH Consulting Corp. 13

アプリケーションの脆弱性を対 策しよう 14

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

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

CSRFによる成りすまし投稿 ③被害者のブラウザ経由で 掲示板に書き込み 掲示板の書き込みログ は被害者のIPアドレス Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 17

日本で一番売れているPHP教科書のサンプル
005: if (isset($_SESSION['id']) && $_SESSION['time'] + 3600 > time()) {
006:
// ログインしている 省略
014: } else {
015:
// ログインしていない
016:
header('Location: login.php'); exit();
017: }
CSRF脆弱性
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: }

Copyright © 2008-2014 HASH Consulting Corp. All rights reserved

18

CSRF対策の方法は? • 色々な対策が知られている • トークンによるもの • 再認証 • Refererのチェック • Captcha • … • 実際は、トークン一択と考えて良い Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 19

トークンはどうやって生成する? • ワンタイムトークンである必要はない – セッション毎に固定で良い – いわゆるワンタイムトークンだと処理が複雑になる • セッション毎に一度「安全な乱数生成器」で生成する – 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

クロスサイト・スクリプティング(XSS) 21

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

XSSのデモ
• 先ほどのCSRF対策済みの掲示板で、なりすまし書き込み
をやってみよう
• 実行するスクリプトは下記のもの
<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>

Copyright © 2008-2014 HASH Consulting Corp. All rights reserved

23

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

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

• http://www.tokumaru.org/d/20090930.html

壊れた文字エンコーディングによる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

SQLインジェクション 27

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

日本で一番売れているPHP教科書のサンプル
// ここまでで、認証済みであるこの検査が済んでいる
$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’]) { // 投稿者の確認
ここにSQLインジェクション
// 投稿した本人であれば、削除
mysql_query('DELETE FROM posts WHERE id=' . mysql_real_escape_string($id)) or
die(mysql_error());
}

しかし、DELETE FROM文
なので表示はない

Copyright © 2008-2014 HASH Consulting Corp. All rights reserved

29

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

SQL文のエラーが起こるか否かで情報を盗む • 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インジェクション 続きはデモで Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 31

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

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

PDO+Shift_JISによるSQLインジェクション $nameとして「ソ' OR 1=1#」とした場合の実行結果: 本来エスケープの必要のない「ソ」が「ソ\」とエスケープされ てしまい、SQLインジェクション脆弱性となる Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 34

サンプルコード（PHP5.3.6以降）
$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();
http://blog.a-way-out.net/blog/2013/12/18/pdo-preparestatement-numeric-literal-part2/ を参考せさせていただきました
35

• http://blog.a-way-out.net/blog/2013/12/18/pdo-prepare-

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

HTTPヘッダインジェクション 37

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

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

• http://example.jp/

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

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

セッションIDの固定化の原理 • 攻撃者が、他のサイト利用者（被害者）のブラウザにセッションＩ Ｄを強制する方法がある – 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-evenon-ssl.html • 攻撃者がセットしたセッションIDのまま利用者がログイン状態にな ると、攻撃者がログイン済みセッションIDが分かる Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 43

• http://blog.tokumaru.org/2013/09/cookie-manipulation-is-possible-even-

セッションIDの固定化の影響・対策 • 影響 – なりすまし全般の影響 – 個人情報の漏洩 – 被害者のアカウントでの投稿、情報変更 – 被害者のアカウントでの退会処理 • 対策 – ログイン直後にセッションIDを変更する session_start(); session_regenerate_id(true); Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 44

RHEL5/RHEL6のPHP脆弱性対応状況 PHP 対応日 RHEL5 RHEL6 (PHP5.1.6) (PHP5.3.3) setcookieの display_erros におけ CVE-2008-5814 るXSS 5.2.7 2008/12/4 2009/4/6 htmlspecialchars マ CVE-2009-4142 ルチバイト 5.2.12 2009/12/17 2010/1/13 -- hashdos 5.3.9 2012/1/18 2012/1/11 2012/2/2 脆弱性 CVE CVE-2011-4885 2012/1/10 -- hashdos 修正にともな CVE-2012-0830 う脆弱性 5.3.10 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 5.4.3 2012/5/7 CVE-2012-1823 2012/5/8 Copyright © 2008-2014 HASH Consulting Corp. All rights reserved 2012/5/7 45

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