徳丸本に載っていないWebアプリケーションセキュリティ

7.7K Views

April 21, 12

#security #Web Application Security #PHP Conference #Cache Leakage #Clickjacking #Ajax Security

スライド概要

PHPカンファレンス北海道にて
2012/04/21

徳丸浩

@ockeghem

スライド一覧

徳丸本の中の人 OWASP Japanアドバイザリーボード EGセキュアソリューションズ取締役CTO IPA非常勤職員 YouTubeチャンネル: 徳丸浩のウェブセキュリティ講座 https://j.mp/web-sec-study

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

（ダウンロード不可）

関連スライド

SPAセキュリティ超入門

security php javascript

徳丸浩 808.6K

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

security

徳丸浩 397K

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

security php

徳丸浩 61.7K

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

security

徳丸浩 47.4K

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

security

徳丸浩 33.2K

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

security aws

徳丸浩 32.6K

各ページのテキスト

PHPカンファレンス北海道徳丸本に載っていない Webアプリケーションセキュリティ 2012年4月21日徳丸浩

徳丸浩の自己紹介 • 経歴 – 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/ Copyright © 2012 HASH Consulting Corp. 3

Webアプリケーションとキャッシュ • フレームワークのキャッシュ機能 • リバースプロキシ • フォワードプロキシ • ブラウザのキャッシュ機能 • キャッシュは、Webアプリケーションの負荷を軽減し、応答を高速化するために用いられる • サイト運営側が設置するキャッシュと、閲覧側（ISP等を含む）が設置するものがある Copyright © 2012 HASH Consulting Corp. 6

Demoの構成ブラウザ PROXY squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern (Release|Package(.gz)*)$ 0 20% refresh_pattern . 1440 20% 4320 override-lastmod OpenPNE 3.4.12.1 PHP/MySQL Ubuntu 10.04LTS 2880 ※デモ環境では、WebサーバーとProxyサーバーは同一VM上で稼働 Copyright © 2012 HASH Consulting Corp. 8

10.

11.

そもそもこれは脆弱性なのか? • PROXY設定の問題ではないのか? – PROXY設定の問題とは言い切れない – squidの標準的な機能の範囲である – PROXY設定の基準が明確にあるわけではない • RFC2616 13.4 Response Cacheability – (原文)A response received with a status code of 200, 203, 206, 300, 301 or 410 MAY be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control directive prohibits caching. – (日本語訳)200, 203, 206, 300, 301, 410 のステータスコードと共に受信されたレスポンスは、cache-control 指示子がキャッシングを禁止していなければ、キャッシュによって保存され、以降のリクエストへの応答に使用され、期限メカニズムに従う事ができる。 http://tools.ietf.org/html/rfc2616#section-13.4 http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616#Sec13.1.3 より引用 Copyright © 2012 HASH Consulting Corp. 11

12.

ブラウザのキャッシュはどうか • ブラウザのキャッシュも同様だが • そもそも、ブラウザを共有することが問題 • Windows95,98,MEの時代ならともかく、2012年の時点では、端末は共有しても、ユーザは別にすべし。そうすれば問題は発生しない • つまり、「はてなブックマークでのデモ事例」は許容可能 • とはいえ、Webサイト提供者としては対策することが望ましい Copyright © 2012 HASH Consulting Corp. 12

13.

対策 • HTTPレスポンスヘッダで「キャッシュを禁止するヘッダ」を応答することが根本対策 • セキュアプログラミング講座には… 1. Cache-Control: private Webサーバから返されるコンテンツがただ一人のユーザのためのものであることを示す。このコンテンツは、複数のユーザが共有されるキャッシュに記録されるべきではないことを表している。ただし、これは、一人のユーザのみが利用するキャッシュ（ブラウザのキャッシュ等）への記録を禁じるものではない。Cache-Control: private のみが指定されている場合、何らかのキャッシュへの記録が行われるおそれがある。 2. Cache-Control: no-store このヘッダは、Webサーバから返されてくるコンテンツをキャッシュに記録するな、という指示である。 3. Cache-Control: no-cache 一見「キャッシュを使うな」のように見えるこのヘッダが実際に意味するところは少々ニュアンスが異なる。このヘッダの意味は、いちどキャッシュに記録されたコンテンツは、現在でも有効か否かを本来のWebサーバに問い合わせて確認がとれない限り再利用してはならない、という意味である。 4. Cache-Control: must-revalidate このヘッダは、キャッシュに記録されているコンテンツが現在も有効であるか否かをWeb サーバに必ず問い合わせよ、という指示である。 http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/405.html より引用 13

http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/405.html

14.

対策（続き） • HTTP/1.0対策として – Pragma: no-cache – 非標準の方法であり、確実なものではない • その他の手法 – 「現場の知恵」としてURL（クエリ文字列）にランダムな数字を付加することが行われる • 例: http://example.jp/private.php?rand=8314329428479210 – HTTPSにする • 通常のPROXYはHTTPSのメッセージをキャッシュしない（できない） • リバースPROXY、ブラウザはキャッシュする可能性があるので過信しないこと – テストする • 別ユーザ or 非ログイン状態で、同じURLをアクセスする Copyright © 2012 HASH Consulting Corp. 14

15.

16.

17.

18.

クリックジャッキングの対策 • クリックジャッキングの影響はクロスサイト・リクエストフォージェリ(CSRF)と同等 – ユーザの意識とは無関係に、ユーザの権限で操作が行われる • クリックジャッキングされると困るページには、X-FRAMEOPTIONSヘッダを指定する（徳丸本P63） – frame/iframeを禁止して良い場合 header('X-FRAME-OPTIONS', 'DENY'); – frame/iframeを禁止できないが単一ホストの場合 header('X-FRAME-OPTIONS', 'SAMEORIGIN'); • CSRF対策のトークン発行しているページが対象となる • メタ要素によるX-FRAME-OPTIONS指定は無効です。徳丸本第3刷までの記述は間違いです(_ _) Copyright © 2012 HASH Consulting Corp. 18

19.

20.

21.

22.

23.

24.

この本です 24

25.

26.

27.

28.

29.

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

29

30.

31.

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

32.

33.

34.

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

Copyright © 2012 HASH Consulting Corp.

34

35.

36.

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

Copyright © 2012 HASH Consulting Corp.

36

37.

38.

39.

40.

41.

42.

43.

44.

http://example.jp/json.php

45.

46.

47.

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

47

48.

49.

50.

51.

[beta]

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

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

Copyright © 2012 HASH Consulting Corp.

51

52.

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

53.

54.

55.

56.

[beta]

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

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

Copyright © 2012 HASH Consulting Corp.

56

57.

58.

59.

60.

61.

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

62.

63.

64.

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

65.

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

66.

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

67.

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

67

68.

69.

70.

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

71.

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

71

72.

73.

トランザクションを難しくする要因 • NoSQL • Memcached • データベースのパーティショニング、シャーディング • データベースのレプリケーション • LDAP、ファイル等トランザクション非対応のストレージ • … • 完全なロールバックが難しい場合でも、排他制御だけなら比較的容易に実装できる場合がある Copyright © 2012 HASH Consulting Corp. 73

74.

75.

徳丸本に載っていないWebアプリケーションセキュリティ

徳丸 浩

関連スライド

SPAセキュリティ超入門

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

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

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

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

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

各ページのテキスト

徳丸浩