徳丸本に学ぶ安全な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

3.

徳丸浩の自己紹介 • 経歴 – 1985年京セラ株式会社入社 – 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • その他 – 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開「大学時代のPascal演習がCabezonでした」という方にお目にかかることも • 現在 – HASHコンサルティング株式会社代表 – 京セラコミュニケーションシステム株式会社技術顧問 – 独立行政法人情報処理推進機構非常勤研究員 Copyright © 2012 HASH Consulting Corp. http://www.hash-c.co.jp/ http://www.kccs.co.jp/security/ http://www.ipa.go.jp/security/ 3

4.

5.

6.

JVN iPediaで検索してみよう http://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja 6

7.

2011年5月以降のPHP高危険度脆弱性 JVN iPediaより引用 7

8.

#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

9.

#2 JVNDB-2011-002218(CVE-2011-3268) PHP の crypt 関数におけるバッファオーバーフローの脆弱性概要 PHP の crypt 関数には、バッファオーバーフローの脆弱性が存在します。本脆弱性は、CVE-2011-2483 とは異なる脆弱性です。 CVSS による深刻度 (CVSS とは?) 基本値: 10.0 (危険) [NVD値] 攻撃元区分: ネットワーク攻撃条件の複雑さ: 低攻撃前の認証要否: 不要機密性への影響(C): 全面的完全性への影響(I): 全面的可用性への影響(A): 全面的影響を受けるシステム PHP 5.3.7 未満通常あり得ない想定想定される影響攻撃者により、過度に長い salt 引数を介して、詳細不明な影響を受ける可能性があります。 9

10.

#3 JVNDB-2011-002770(CVE-2011-3379) PHP の is_a 関数における任意のコードを実行される脆弱性概要 PHP の is_a 関数は、__autoload 関数の呼び出しを誘発するため、任意のコードを実行される脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク攻撃条件の複雑さ: 低攻撃前の認証要否: 不要機密性への影響(C): 部分的完全性への影響(I): 部分的可用性への影響(A): 部分的影響を受けるシステム PHP 5.3.7 PHP 5.3.8 ???? 想定される影響第三者により、巧妙に細工された URL、および特定の PEAR パッケージおよびカスタムオートローダの安全でない動作を利用されることで、任意のコードを実行される可能性があります。 10

11.

[beta]

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)

Copyright © 2012 HASH Consulting Corp.

11

12.

[beta]

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 がインクルードされる
Copyright © 2012 HASH Consulting Corp.

12

13.

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

14.

#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 に対する修正が不十分だったことによる脆弱性です。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク攻撃条件の複雑さ: 低攻撃前の認証要否: 不要機密性への影響(C): 部分的完全性への影響(I): 部分的可用性への影響(A): 部分的影響を受けるシステム PHP 5.3.9 想定される影響第三者により、大量の変数を含むリクエストを介して、任意のコードを実行される可能性があります。 14

15.

#番外 JVNDB-2011-003565(CVE-2011-4885) PHP におけるサービス運用妨害 (CPU 資源の消費) の脆弱性(hashdos) 概要 PHP は、ハッシュ衝突を想定した制限を行わずにフォームパラメータのハッシュ値を算出するため、サービス運用妨害 (CPU 資源の消費) 状態となる脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 5.0 (警告) [NVD値] 攻撃元区分: ネットワーク攻撃条件の複雑さ: 低攻撃前の認証要否: 不要機密性への影響(C): なし完全性への影響(I): なし可用性への影響(A): 部分的影響を受けるシステム PHP 5.3.9 未満想定される影響第三者により、巧妙に細工されたパラメータを大量に送信されることで、サービス運用妨害 (CPU 資源の消費) 状態にされる可能性があります。 15

16.

17.

#5 JVNDB-2011-001388(CVE-2012-0831) PHP における SQL インジェクション攻撃を行われる脆弱性概要 PHP は、環境変数のインポート中の magic_quotes_gpc ディレクティブへの一時的変更を適切に処理しないため、容易に SQL インジェクション攻撃を行われる脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク攻撃条件の複雑さ: 低攻撃前の認証要否: 不要機密性への影響(C): 部分的完全性への影響(I): 部分的可用性への影響(A): 部分的影響を受けるシステム PHP 5.3.10 未満アプリケーション側でSQLインジェクション対策をしていれば問題ない想定される影響第三者により、main/php_variables.c、sapi/cgi/cgi_main.c、および sapi/fpm/fpm/fpm_main.c に関連する巧妙に細工された要求を介して、容易に SQL インジェクション攻撃を行われる可能性があります。 17

18.

勝手に訂正: 「PHP における SQL インジェクション攻撃を行われる脆弱性 (JVNDB-2012-001388)」 http://co3k.org/blog/25 より引用 18

19.

#6 JVNDB-2012-002235(CVE-2012-1823) PHP-CGI の query string の処理に脆弱性概要 PHP には、CGI として使用される設定において query string をコマンドラインオプションとして認識してしまう脆弱性が存在します。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク攻撃条件の複雑さ: 低攻撃前の認証要否: 不要機密性への影響(C): 部分的完全性への影響(I): 部分的可用性への影響(A): 部分的影響を受けるシステム PHP version 5.4.2 より前のバージョン PHP version 5.3.12 より前のバージョン PHP の開発者によると、本脆弱性の修正を含む更なるリリースを予定しているとのことです。そのため、影響を受けるシステムに関する情報が今後変更される可能性があります。想定される影響遠隔の第三者によって、php スクリプトの内容を取得されたり、サービス運用妨害 (DoS) 攻撃を受けたり、ウェブサーバの権限で任意のコードを実行されたりする可能性があります。 19

20.

#7 JVNDB-2012-002392(CVE-2012-2311) PHP の sapi/cgi/cgi_main.c における任意のコードを実行される脆弱性概要 PHP の sapi/cgi/cgi_main.c は、CGI スクリプトとして設定される際、%3D 文字列を含み = (等号) 文字を含まないクエリ文字列を適切に処理しないため、任意のコードを実行される脆弱性が存在します。本脆弱性は、CVE-2012-1823 に対する修正が不十分だったことによる脆弱性です。 CVSS による深刻度 (CVSS とは?) 基本値: 7.5 (危険) [NVD値] 攻撃元区分: ネットワーク攻撃条件の複雑さ: 低攻撃前の認証要否: 不要機密性への影響(C): 部分的完全性への影響(I): 部分的可用性への影響(A): 部分的影響を受けるシステム PHP 5.4.3 未満の 5.4.x PHP 5.3.13 未満想定される影響第三者により、クエリ文字列内にコマンドラインオプションを配置することで、任意のコードを実行される可能性があります。 20

21.

22.

23.

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

24.

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

25.

26.

とある入門書のサンプルよくわかるJavaScriptの教科書、たにぐちまこと著、2012 P228より引用 26

27.

この本です 27

28.

動かしてみる 28

29.

結果 29

30.

JSON作成をPHPに生成されるJSON [{"image":"img¥/1.jpg","image_big":"i mg¥/1_big.jpg","caption":"¥u30ad¥u30e 3¥u30d7¥u30b7¥u30e7¥u30f31"}] 30

31.

結果 31

32.

[beta]

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

33.

結果 33

34.

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

35.

36.

JSON解釈をevalでやってみる 36

37.

[beta]

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

38.

結果 38

39.

[beta]

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

40.

結果 40

41.

42.

43.

44.

45.

46.

47.

http://example.jp/json.php

48.

49.

50.

[beta]

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)>"}]
Copyright © 2012 HASH Consulting Corp.

50

51.

52.

53.

53

54.

[beta]

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

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

Copyright © 2012 HASH Consulting Corp.

54

55.

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"}] Copyright © 2012 HASH Consulting Corp. 55

56.

57.

58.

59.

[beta]

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

• なんらかの手法で、このJSONの中味を読むのがJSONハイ
ジャック
これは罠サイト
<script>
ここにJSONを読み出す仕掛けを置く
// script要素で読み出したJSON
[{"name":"Yamada", "mail":"[email protected]"}]
</script>

Copyright © 2012 HASH Consulting Corp.

59

60.

61.

62.

63.

64.

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

65.

66.

67.

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

68.

こんな感じだった? 必要なもの携帯もしくはPCを二台 gleeアカウント二つ二台の機器でそれぞれのgleeアカウントでログインしてドリランド起動後お互いでトレードさせるトレード(受け取りはしない)が終わったら片方の機器はログアウトして二つの機器のアカウントを同じにするそれぞれトレード品受け取り画面にして受け取るボタン同時押しカード毎にID振って無いのかよ。。。。馬鹿じゃねぇの？ >>277 ちゃんとふってあるけど、トレード時にトレードされる側とする側でちゃんとアイテムIDが変わる仕様だったw http://jin115.com/archives/51849925.html より引用 68

69.

こんな感じだった? DBからトレード元のカードのデータを読み取る 新しいIDをつけてトレード先に保存する トレード元のデータを削除する http://bakera.jp/ebi/topic/4722 より引用 69

70.

[beta]

作ってみた
// トレードするカードの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 ");
※デモスクリプトはプレースホルダをちゃんと使っています!

Copyright © 2012 HASH Consulting Corp.

70

71.

72.

73.

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

74.

[beta]

トランザクションと行ロックで対策
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) {
// ……
※上記は概要でありデモスクリプトはプレースホルダをちゃんと使っています!
Copyright © 2012 HASH Consulting Corp.

74

75.

76.

77.

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引数明示した方がよい Copyright © 2012 HASH Consulting Corp. 77

78.

79.

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を使う Copyright © 2012 HASH Consulting Corp. 79

80.

81.

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

82.

83.

84.

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

85.

86.

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

87.

88.

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

89.

90.

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

91.

[beta]

CSRF/クリックジャッキングの対策
• CSRF対策はトークンによる方法に統一しよう
– 「ワンタイムトークン」である必要はない

• クリックジャッキングされると困るページには、X-FRAME-OPTIONSヘッダを指定す
る（徳丸本P63）
– frame/iframeを禁止して良い場合
header('X-FRAME-OPTIONS', 'DENY');
– frame/iframeを禁止できないが単一ホストの場合
header('X-FRAME-OPTIONS', 'SAMEORIGIN');

• CSRF対策のトークン発行しているページが対象となる
入力画面
メールアドレス

[email protected]

実行画面
メールアドレスアドレスを
変更しました

変更
header('X-FRAME-OPTIONS', 'DENY');
…
<input type="hidden" name="token"
value="a89daf89af0…">

セッション等に保存したtokeとhiddenの
token値を比較)

Copyright © 2012 HASH Consulting Corp.

91

92.

93.

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

94.

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

95.

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

96.

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

97.

98.

徳丸本に載っている主な脆弱性 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 競合状態の脆弱性 Copyright © 2012 HASH Consulting Corp. 98

99.

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

徳丸浩

関連スライド

SPAセキュリティ超入門

SPAセキュリティ入門～PHP Conference Japan 2021

ウェブセキュリティのありがちな誤解を解説する

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

各ページのテキスト

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

徳丸 浩

関連スライド

SPAセキュリティ超入門

SPAセキュリティ入門～PHP Conference Japan 2021

ウェブセキュリティのありがちな誤解を解説する

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

各ページのテキスト

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

徳丸浩