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

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

2012年9月15日
徳丸浩

本日お話しする内容
• 鉄則1: PHP自体の脆弱性対処をしよう
• 鉄則2: Ajaxの脆弱性対処をしよう
• 鉄則3: 競合条件の脆弱性対処をしよう
• 鉄則4: htmlspecialcharsの使い方2012
• 鉄則5: escapashellcmdは使わないこと
• 鉄則6: SQLインジェクションの対処
• 鉄則7: クロスサイト･スクリプティングの対処
• 鉄則8: クロスサイト・リクエスト・フォージェリの対処
• 鉄則9: パスワードの保存はソルトつきハッシュ、できればスト
レッチングも
• 鉄則10: 他にもたくさんある脆弱性の対処
Copyright © 2012 HASH Consulting Corp. 2

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


鉄則1: PHP自体の脆弱性対処をしよう


PHPの脆弱性ってどれくらい危険なの?


JVN iPediaで検索してみよう

http://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja

6

2011年5月以降のPHP高危険度脆弱性

JVN iPediaより引用 7

#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

#2 JVNDB-2011-002218(CVE-2011-3268)
PHP の crypt 関数におけるバッファオーバーフローの脆弱性

概要
PHP の crypt 関数には、バッファオーバーフローの脆弱性が存在します。
本脆弱性は、CVE-2011-2483 とは異なる脆弱性です。

機密性への影響(C): 全面的
完全性への影響(I): 全面的
可用性への影響(A): 全面的

PHP 5.3.7 未満
通常あり得ない想定
攻撃者により、過度に長い salt 引数を介して、詳細不明な影響を受ける可能性があります。

9

#3 JVNDB-2011-002770(CVE-2011-3379)
PHP の is_a 関数における任意のコードを実行される脆弱性

概要
PHP の is_a 関数は、__autoload 関数の呼び出しを誘発するため、任意のコードを実行される
脆弱性が存在します。


PHP 5.3.7
PHP 5.3.8
????
第三者により、巧妙に細工された URL、および特定の PEAR パッケージおよびカスタムオート
ローダの安全でない動作を利用されることで、任意のコードを実行される可能性があります。

10

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)


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 がインクルードされる


CVE-2011-3379の影響を受ける条件(AND条件)
• __autoload関数によりクラスの自動ロード機能が定義されて
いる
• 直接・間接に、is_a関数に「攻撃者の入力した文字列」を渡
すことができる（PEARのFileクラスなど）
• 以下のいずれかにより任意スクリプトを指定できること
– アップロード機能などにより、サーバー上にPHPファイルを書き込み、
そのファイル名が推測できる
– allow_url_includeが有効になっている
• 影響を受ける環境はまれと推測される


#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 に対する修正が不十分だったことによる脆弱性です。


PHP 5.3.9

第三者により、大量の変数を含むリクエストを介して、任意のコードを実行される可能性がありま
す。

14

#番外 JVNDB-2011-003565(CVE-2011-4885)
PHP におけるサービス運用妨害 (CPU 資源の消費) の脆弱性(hashdos)

概要
PHP は、ハッシュ衝突を想定した制限を行わずにフォームパラメータのハッシュ値を算出するた
め、サービス運用妨害 (CPU 資源の消費) 状態となる脆弱性が存在します。

基本値: 5.0 (警告) [NVD値]
機密性への影響(C): なし
完全性への影響(I): なし

PHP 5.3.9 未満

第三者により、巧妙に細工されたパラメータを大量に送信されることで、サービス運用妨害
(CPU 資源の消費) 状態にされる可能性があります。

15

http://blog.tokumaru.org/2011/12/webdoshashdos.html

#5 JVNDB-2011-001388(CVE-2012-0831)
PHP における SQL インジェクション攻撃を行われる脆弱性

概要
PHP は、環境変数のインポート中の magic_quotes_gpc ディレクティブへの一時的変更を適切
に処理しないため、容易に SQL インジェクション攻撃を行われる脆弱性が存在します。

完全性への影響(I): 部分的アプリケーション側
でSQLインジェク
影響を受けるシステムション対策をしてい
PHP 5.3.10 未満れば問題ない
第三者により、main/php_variables.c、sapi/cgi/cgi_main.c、および
sapi/fpm/fpm/fpm_main.c に関連する巧妙に細工された要求を介して、容易に SQL インジェ
クション攻撃を行われる可能性があります。

17

勝手に訂正: 「PHP における SQL インジェクション攻
撃を行われる脆弱性 (JVNDB-2012-001388)」

http://co3k.org/blog/25 より引用 18

#6 JVNDB-2012-002235(CVE-2012-1823)
PHP-CGI の query string の処理に脆弱性

概要
PHP には、CGI として使用される設定において query string をコマンドラインオプションとして認識してしま
う脆弱性が存在します。


PHP version 5.4.2 より前のバージョン
PHP version 5.3.12 より前のバージョン

PHP の開発者によると、本脆弱性の修正を含む更なるリリースを予定しているとのことです。
そのため、影響を受けるシステムに関する情報が今後変更される可能性があります。

遠隔の第三者によって、php スクリプトの内容を取得されたり、サービス運用妨害 (DoS) 攻撃を受けたり、
ウェブサーバの権限で任意のコードを実行されたりする可能性があります。

19

#7 JVNDB-2012-002392(CVE-2012-2311)
PHP の sapi/cgi/cgi_main.c における任意のコードを実行される脆弱性
概要
PHP の sapi/cgi/cgi_main.c は、CGI スクリプトとして設定される際、%3D 文字列を含み =
(等号) 文字を含まないクエリ文字列を適切に処理しないため、任意のコードを実行される脆弱
性が存在します。
本脆弱性は、CVE-2012-1823 に対する修正が不十分だったことによる脆弱性です。


PHP 5.4.3 未満の 5.4.x
PHP 5.3.13 未満

第三者により、クエリ文字列内にコマンドラインオプションを配置することで、任意のコードを実行
される可能性があります。

20

CVE-2012-2311のPoC

allow_url_include=On
auto_prepend_file=php://input

<?php readfile(‘/etc/passwd’); ?>


飽きてきたので、この辺で…


とりあえずのまとめ
• PHPの高危険度脆弱性は多いが、影響を受ける局面が限ら
れるものが多い
• アプリケーションが、当該脆弱性の影響を受けるか、外部か
らは判別しにくい
• アプリケーションやフレームワークの脆弱性の原因となった
場合、外部からの攻撃が容易となる
• IPA、JPCERT/CC、セキュリティ専門家の情報をウォッチし、
「騒ぎ出したら」急いで対処の準備をすること


脆弱性対処のアプローチ
• 正当的な方法
– 脆弱性情報が出る毎に影響を評価し、対処方法を決める
– 影響が大きく、回避策がある場合は、まず回避策を適用する
– パッチ、PHP新バージョンのアプリケーションに対する影響をテスト
する
– 本番環境にパッチ適用、バージョンアップ
• Linuxディストリビューションのパッチに任せる
– 基本的に、ディストリビューションのパッチが出るのを待って適用す
る
– テスト環境でパッチの影響を調べる
（えいやっ! で当ててしまうのもあり）
– 高危険度で攻撃が容易、かつパッチが間に合わない脆弱性につい
ては、回避策を適用する


鉄則2: Ajaxの脆弱性対処をしよう


とある入門書のサンプル

26
よくわかるJavaScriptの教科書、たにぐちまこと著、2012 P228より引用

動かしてみる

28

JSON作成をPHPに

生成されるJSON

[{"image":"img¥/1.jpg","image_big":"i
mg¥/1_big.jpg","caption":"¥u30ad¥u30e
3¥u30d7¥u30b7¥u30e7¥u30f31"}]

30

データにJavaScriptを入れてみる

生成されるJSON

[{"image":"img¥/1.jpg","image_big":"i
mg¥/1_big.jpg","caption":"¥u30ad¥u30e
3¥u30d7¥u30b7¥u30e7¥u30f31<script>ale
rt(1)<¥/script>"}]

32

脆弱性の原因と対策
• htmlメソッドによりHTMLテキストを設定しているにも関わら
ず、データをHTMLエスケープしていない
• ただし、元文献は固定テキストなので、必ずしも脆弱性とは
言えない
• HTMLエスケープするタイミングは、以下の候補がある
– ブラウザでレンダリングする箇所
– JSONを組み立てる段階で、あらかじめHTMLエスケープしておく


次の話題

evalインジェクション


JSON解釈をevalでやってみる

36

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

データに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

脆弱性の原因と対策
• JSON/JavaScriptとしての適切なエスケープを怠っているこ
とが根本原因
• 根本単位策：JSON生成を自前でしないで、信頼できるライブ
ラリを用いる
• 保険的対策（強く推奨）:evalでJSONを解釈しない。


次の話題

json.phpを直接ブラウズしてみる


データを少しいじりましょう


さまざまなブラウザでの結果


で、IE9は?


大丈夫なのか


でも、だめ

http://example.jp/json.php/a.html


http://d.hatena.ne.jp/hasegawayosuke/20110106/p1 より引用

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)>"}]

IE9だとOK(IE8以上)


IE7だとだめ


対策
• 必須対策（全ブラウザ共通）
– レスポンスがブラウザによりtext/htmlと解釈されないようにする
X-Content-Type-Options: nosniff
Content-Type: application/json; charset=utf8

• IE6,7対策
– IE7以前をサポートしない
– ブラウザからの直接リクエストを受け付けない
– 「<」、「>」などもエスケープする


Json_encodeのパラメータを追加

生成されるJSON
[{"image":"img¥/1.jpg","image_big":"img¥/1_bi
g.jpg","caption":"¥u30ad¥u30e3¥u30d7¥u30b7¥u3
0e7¥u30f31¥u003Cbody onload=alert(1)¥u003E"}]


今度は大丈夫


次の話題はJSONハイジャック


Firefox3などで発現。現在の主要ブラ
ウザでは対策されている


JSONハイジャックとは
• JSONを罠サイトからscript要素で読み出す
• 利用者のブラウザからは、正規のCookieが送信されるので、
認証ずみの状態でJSONが取得できる
• なんらかの手法で、このJSONの中味を読むのがJSONハイ
ジャック

これは罠サイト
<script>
ここにJSONを読み出す仕掛けを置く
// script要素で読み出したJSON
[{"name":"Yamada", "mail":"yama@example.jp"}]
</script>


サンプルスクリプト（罠）


結果


Firefox11.0だと問題なし


Androidの標準ブラウザでハイジャック成功

Xperia ARC(SO-01C)
Android 2.3.4 でキャプチャ

Galaxy Nexus
Android 4.0.3では取得できず


対策
• script要素からのリクエストにはレスポンスを返さないように
する
– XMLHttpRequestからのリクエストに特別なヘッダを入れておき、
JSON提供側でチェックするなど
Jqueryの以下のヘッダを使っても良いかも
X-Requested-With: XMLHttpRequest
– POSTにのみ応答（個人的には好みません）
• JSONデータを、JavaScriptとして実行できない形にする
– 1行目に for(;;) ; を置く（個人的には好みません）
– JSONデータをJavaScriptとして実行できない形にする（同上）
• JSONハイジャック可能なブラウザを使わない（利用者側でと
れる対策）


鉄則3: 競合条件の脆弱性対処をしよう


ドリランドカード増殖祭りはこうしておこ
った…かも?


67
https://help.gree.jp/app/answers/detail/a_id/3231 より引用

こんな感じだった?

必要なもの携帯もしくはPCを二台 gleeアカウント二つ
二台の機器でそれぞれのgleeアカウントでログインしてドリランド起
動後お互いでトレードさせる
トレード(受け取りはしない)が終わったら片方の機器はログアウトし
て二つの機器のアカウントを同じにする
それぞれトレード品受け取り画面にして受け取るボタン同時押し

カード毎にID振って無いのかよ。。。。
馬鹿じゃねぇの？
>>277
ちゃんとふってあるけど、トレード時にトレードされる側とする側で
ちゃんとアイテムIDが変わる仕様だったw

68
http://jin115.com/archives/51849925.html より引用

こんな感じだった?
DBからトレード元のカードのデータを読み取る
新しいIDをつけてトレード先に保存する
トレード元のデータを削除する

http://bakera.jp/ebi/topic/4722 より引用 69

作ってみた
// トレードするカードの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 ");

※デモスクリプトはプレースホルダをちゃんと使っています!


DEMO


中ではこうなった


対策
• トランザクションを使う
– PDOの場合は、begeinTransaction ～ commit / rollbackの間
• ロック（排他制御）
– SELECT … FOR UPDATE など
• 上記の両方が必須
– トランザクションを使うだけでは排他制御にならない場合が多い
厳密にはDB依存およびモードに依存
• 「クリティカルセクション」に注意
– このスクリプトの場合は、SELECT ～ DELETE FROMまではクリテ
ィカルセクションであり、同一カードIDについては並行動作してはい
けない
• ちゃんとRDBを基礎から勉強しよう


トランザクションと行ロックで対策
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) {
// ……

※上記は概要でありデモスクリプトはプレースホルダをちゃんと使っています!

中ではこうなる


鉄則4:
htmlspecialcharsの使い方2012


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引数明示した方がよ
い


鉄則5:
escapashellcmdは使わないこと


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を使う


鉄則6: SQLインジェクションの対処


SQLインジェクション
• SQLインジェクションとは、
WHERE句に or ’a’=’a’ を追加する攻撃…ではない
• 多くの場合、SQL文の後半を自由に改変できる
– WHERE句の改変
– UNION SELECTの追加
– …
• DB内の任意テーブルの情報を取得可能
– 大規模な情報漏洩につながる
• MS SQLやPostgreSQLの場合、第2、第3のSQL文を追加
できる（複文の実行）
– 複文が実行できる場合、データの改変、追加、削除が可能


SQLインジェクション対策
• プレースホルダを用いてSQL文を呼び出す…の一択
– エスケープはややこしすぎる
• DB接続の際に文字エンコーディングを指定すること
• （できれば）静的プレースホルダを用いること
• 安全なSQLの呼び出し方を良く読むこと（無料です）


鉄則7: クロスサイト･スクリプティングの
対処


クロスサイトスクリプティング(XSS)とは
• XSSは、ブラウザ上でalertを表示する攻撃…ではない
• 攻撃者が、一般利用者のブラウザ上で、勝手なJavaScriptを
実行できる脆弱性 / 攻撃手法
• それって、ウイルス?
– XSS自体はウイルスではないが、XSS脆弱性を悪用してウイルス
の一種（ワーム）を作ることはできる
– 不正確だが「ウイルスのように凶悪なもの」という理解はあり
• 対策は、HTMLのエスケープ
– これが複雑


HTMLの構成要素


HTMLエスケープの概要
場所説明エスケープの概要
要素内容（通常のタグと文字参照が解釈さ
「<」と「&」を文字参照に
テキスト）れる「<」で終端
文字参照が解釈される属性値を「”」で囲み、「”」と
属性値
引用符で終端「&」を文字参照に
URLの形式を検査してから
属性値(URL) 同上
属性値としてのエスケープ
JavaScriptとしてエスケープ
イベントハンドラ内
同上してから属性値としてのエス
の文字列リテラル
ケープ
JavaScriptとしてのエスケー
script要素内の文タグも文字参照も解釈さ
プおよび「</」が出現しないよ
字列リテラルれない。「</」により終端
う考慮


鉄則8: クロスサイト・リクエスト・フォージ
ェリの対処


クロスサイト・リクエスト・フォージェリの対処
• クロスサイト・リクエスト・フォージェリ(CSRF)とは
– Webアプリケーションの「機能」を勝手に実行させられる
– サーバー側の作用（更新、送金、投稿、削除…）に限られる
• 勝手に実行させられるのは、「サーバー側に元々ある機能」
– SQLインジェクションは任意のSQLが実行可能
– XSSは任意のJavaScriptが実行可能…という点で異なる
• でも、XSSとCSRFは、なんか、似ている


反射型XSSとCSRFの比較

徳丸本P147より引用


クリックジャッキング攻撃
• 機能を勝手に実行させられるという点でCSRFと類似
• ターゲットの画面をiframe上で「透明に」表示する
• その下にダミーの画面を表示させる。ユーザにはダミーの画
面が透けて見える
• 利用者がダミーの画面上のボタンを押すと、実際には全面の
ターゲット画面のボタンが押される

本当の画面（前面、透明）ダミーの画面（後面）


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…">


鉄則9: パスワードの保存はソルトつき
ハッシュ、できればストレッチングも


どうして暗号化ではなくてハッシュなの?
• 暗号化の場合、鍵の管理が難しい
• アプリケーションは鍵を使わなければならないが、攻撃者には鍵を見せ
たくない
• PSNの事件では、権限昇格されたことになっているので、暗号鍵も盗ま
れていると想定せざるを得ない
• ハッシュだと鍵を使わないので、鍵管理のわずらわしさがない
• パスワードをサイト管理者にも知られたくないというニーズも
– 暗号化されたパスワードだと、サイト管理者やヘルプデスク担当者がパスワードを
知り得るのが嫌だ
– ヘルプデスクに見せないようにするには、サポート用画面の機能次第で可
– 管理者の悪事は総合的な対策が必要で、パスワードの問題だけではない
• PCI-DSS2.0 8.4項には「8.4 強力な暗号化を使用して、すべてのシス
テムコンポーネントでの伝送および保存中のすべてのパスワードを読
み取り不能にする」とあり、ハッシュを求めてはいない


ハッシュで保存されたパスワードは本当に安全なの?
• 一般的に、（暗号論的）ハッシュ値から平文を「復元する」ことはできな
い
– 「password」のMD5ハッシュ: 5f4dcc3b5aa765d61d8327deb882cf99
• しかし、パスワードの場合は特別な事情がある
• 例：4桁の暗証番号をハッシュ値で保存している場合
– 全ての可能性は1万通りしかないのだから、総当たりで確認すれば、平文の暗証
番号はすぐに判明する
• 原理は8桁パスワードでも同じ
• ハッシュ保存の場合、アルゴリズムは攻撃者が知っている前提で安全
な設計とする
– 平文パスワード以外は、すべて「ばれている」想定を置く
• 攻撃者にとって未知であることが保証された情報があれば、それを鍵と
して暗号化すればよい。現実にはそのような保証がないから暗号化を
用いない


Saltってなに?
• ソルト（Salt）とは、ハッシュの元データ（パスワード）に追加する文字列
• 見かけのパスワードの長さを長くする
– 公開されたレインボーテーブルは10文字までのパスワードに対応しているので、
パスワードとソルトを合わせて20文字以上にしておけば、当面は大丈夫
• ユーザ毎にソルトを変えることで、パスワードが同じでも、異なるハッシ
ュ値が得られる
• ソルトの要件
– ある程度の長さを確保すること
– ユーザ毎に異なるものにすること
• ソルトには乱数を用いることが多いが、乱数が必須というわけではない
（暗号論的に安全な乱数である必要はもちろんない）
• ソルトは秘密情報ではない。ソルトは、通常ハッシュ値と一緒に保存す
る


Stretchingってなに?
• ストレッチング（Stretching）とは、ハッシュの計算を繰り返すこと
• ハッシュの計算を遅くすることにより、辞書攻撃や総当たり攻撃に対抗
する
• 1万回ストレッチすると、「 GPU で 7 時間である」が7万時間になる計算
– 7万時間 = 2916日 = 約8年
• 「悪い」パスワードまで救えるわけではない
– 「password」というパスワードをつけていたら、100万回ストレッチしてもすぐに解
読されてしまう
• 十分長いパスワードをつけてもらえば、ストレッチングは必要ない
– 1文字パスワードを長くすることは、約100回のストレッチングに相当する。パスワ
ードを2文字長くしてもらえば…
– でも、中々難しいのでストレッチングの値打ちがある
• ストレッチングはメリットとデメリットがあるので、導入の有無と回数をよ
く検討すること

鉄則10: 他にもたくさんある
脆弱性の対処


徳丸本に載っている主な脆弱性
4.3.1 クロスサイト・スクリプティング
4.4.1 SQLインジェクション
4.5.1 クロスサイト・リクエストフォージェリ（CSRF）
4.6.2 推測可能なセッションID
4.6.3 URL埋め込みのセッションID
4.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 競合状態の脆弱性

結論
徳丸本を買ってよく読め

ご清聴ありがとうございました


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

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

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(12)

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

Similar to 徳丸本に学ぶ安全なPHPアプリ開発の鉄則2012(20)

More from Hiroshi Tokumaru

More from Hiroshi Tokumaru(17)

Recently uploaded

Recently uploaded(11)