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

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

徳丸浩の自己紹介
• 経歴
– 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

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

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

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

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

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した内容を指定
続きはデモで

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

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

PHPのバージョンアップにつきあうには?
• サイトリリース前にバージョンアップ方針を決める
• 基本的な選択肢
– PHPのバージョンアップにとことん付き合う
– 影響を受ける脆弱性がある場合のみバージョンアップする
– LinuxディストリビューションのパッケージとしてPHPを導入し
て、パッチを適用する
• PHP以外に、フレームワークやDB、ライブラリ等も
• サポート計画を検討する
– PHPをRedHat/CentOSのパッケージで導入すれば10年サポート
– Redhat5/Centos5のPHP5.1.6もメンテナンスされているよ
※2017年3月31日まで
– 途中でメジャーバージョンアップする計画を立てておく
• 他のソフトウェアのサポートライフサイクルにも注意

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

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

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

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

CSRFによる成りすまし投稿
17
③被害者のブラウザ経由で
掲示板に書き込み
掲示板の書き込みログ
は被害者のIPアドレス

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脆弱性
対策していない
続きはデモで

CSRF対策の方法は?
• 色々な対策が知られている
• トークンによるもの
• 再認証
• Refererのチェック
• Captcha
• …
• 実際は、トークン一択と考えて良い

トークンはどうやって生成する?
• ワンタイムトークンである必要はない
– セッション毎に固定で良い
– いわゆるワンタイムトークンだと処理が複雑になる
• セッション毎に一度「安全な乱数生成器」で生成する
– 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とセッションの両方に書いておい
て、両者を比較する。違っていたらエラー

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

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

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

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のエスケープは人類には難しすぎる

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以降は問題なし

壊れた文字エンコーディングによる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のパッチにて対応済み

SQLインジェクション
27

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

日本で一番売れている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文
なので表示はない

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

• 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文のエラーが起こるか否かで情報を盗む
続きはデモで

SQLインジェクション対策はプレースホルダで
• プレースホルダとは
SELECT * FROM books WHERE id=?
• 静的プレースホルダと動的プレースホルダ
– 静的: サーバー側で値をバインドする（エスケープは必要な
い）
– 動的: 呼び出し側で値をエスケープしてバインドする
• 接続時に文字エンコーディングを指定する
$db = new PDO('mysql:host=myhost;dbname=mydb;charset=utf8',
DBUSER, DBPASS);
• 列の型を意識する

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);
}

PDO+Shift_JISによるSQLインジェクション
$nameとして「ソ' OR 1=1#」とした場合の実行結果:
本来エスケープの必要のない「ソ」が「ソ」とエスケープされ
てしまい、SQLインジェクション脆弱性となる

$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/ を参考せさせていただきました

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

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のヘッダができた!

HTTPヘッダインジェクションが成立する条件
• 以下の両方に該当する場合
– アプリケーション側でレスポンスヘッダとして出力する文字列
中に改行（0x0D, 0x0A）がないことをアプリケーション側で確
認していない
– HTTPヘッダインジェクションの脆弱性があるPHPのバージョン
を使用している
• PHP5.1.2で改行チェックが入ったが、0x0D（キャリッ
ジリターン）のチエックがなかった
• HTTPヘッダインジェクション脆弱性がないバージョンは
下記の通り
– PHP5.3.10以降、PHP5.4.0以降
– RHEL5以降、CentOS5以降、Ubuntu10.04LTS以降は、最新のパ
ッチが当たっていれば問題ない

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

• 攻撃者が、他のサイト利用者（被害者）のブラウザにセッションＩ
Ｄを強制する方法がある
– 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の固定化の原理

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

RHEL5/RHEL6のPHP脆弱性対応状況
脆弱性CVE PHP 対応日RHEL5
(PHP5.1.6)
RHEL6
(PHP5.3.3)
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

• アプリケーションの脆弱性を対策しよう
– SQLインジェクション
– クロスサイト・スクリプティング(XSS)
– クロスサイト・リクエストフォージェリ(CSRF)
– …
• プラットフォームの脆弱性を対策しよう
– PHP自身の脆弱性対策
– CentOS5のPHP5.1.6でもよいので、パッチが提供されているこ
とがとても重要
• PHP5.1.6をdisるのはやめてさしあげて!
– 構築したその環境、今後5年間パッチが提供されますか?
– bashの脆弱性等も同様に対応#shellshock
まとめ
46

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

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

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

More from Hiroshi Tokumaru (16)

Recently uploaded (6)

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