---
title: WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱
tags:  #security  
author: [徳丸 浩](https://www.docswell.com/user/ockeghem)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/5GE5Q89874.jpg?width=480
description: WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱 by 徳丸 浩
published: May 24, 10
canonical: https://www.docswell.com/s/ockeghem/KM6XL5-was-forum-2010
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/5GE5Q89874.jpg)

ケータイ2.0が開けてしまった
パンドラの箱
2010年5月22日
HASHコンサルティング株式会社
徳丸 浩


# Page. 2

![Page Image](https://bcdn.docswell.com/page/V972PK2V7R.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/5DJY5NYQJM.jpg)

今日はケータイの「かんたんログイン」
のお話です
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/2V7NNXP278.jpg)

ケータイWebアプリの構成
キャリア基地局
ゲートウェイ
iモード
EZweb
Yahoo! ケータイ
コンテンツ提供事業者
Webサーバ DBサーバ
ワイヤレス網
インターネット
端末
(Hand Set)
DB
言語変換
認証
SSL処理
Cookie保持
・・・
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GYJ9R83DE3.jpg)

「かんたんログイン」とは
端末固有IDのみを
キーとして認証する
端末固有IDあれこれ
キャリア
名称
HTTPヘッダ
NTTドコモ
FOMA端末識別番号
User-Agent
iモードＩＤ
X-DCMGUID
Au
EZ番号
X-UP-SUBNO
ソフトバンク
端末シリアル番号
User-Agent
ユーザーＩＤ
X-JPHONE-UID
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/5GJ8W8M5ED.jpg)

かんたんログイン画面の例(1)
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/MLJLNR337R.jpg)

かんたんログイン画面の例(2)
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/547MXRDMEW.jpg)

かんたんログイン画面の例(3)
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/ZP7RNR4LE9.jpg)

「かんたんログイン」がなりたつための条件




端末固有IDは、同一端末であれば、すべてのサイトに同じ値が送
出される。すなわち、端末固有IDは秘密情報ではない
秘密情報でない、固定のIDで認証するためには、端末固有IDは
書き換えができないという前提が必要
端末固有IDはHTTPヘッダに乗ってくる値なので、通常は任意に
書き換えができる。携帯電話を使っている時は変更できないと考
えられているが…
まとめると、かんたんログインはケータイの以下の条件によって支
えられている


ケータイ網が閉じたネットワークである
ケータイ端末の機能が低く、HTTPヘッダを書き換える機能がない
今日のテーマはこちら
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/NPJXNRZ67X.jpg)

iモードブラウザ2.0の登場
2009年5月19日づけNTTドコモ社の報道発表より
おや?
http://www.nttdocomo.co.jp/info/news_release/page/090519_00.html より引用
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/63JKNR8GJD.jpg)

ケータイJavaScriptで端末固有ＩＤを書き換える条件

以下の三条件がそろえば、端末固有IDの書き換え、すなわち「か
んたんログイン」なりすましができるが・・
a.
b.
c.



携帯電話のJavaScriptでXMLHttpRequestオブジェクトが利用でき
る
XMLHttpRequestにてsetRequestHeaderメソッドが利用できる
setRequestHeaderメソッドにてUserAgentなどのリクエストヘッダが
書き換えできる
10月末のJavaScript再有効化の際に、 setRequestHeaderメソッ
ドが無効化された模様。すなわち、上記b、cが成立しなくなった。
元々のNTTドコモのサイトではJavaスクリプトの仕様書に
setRequestHeaderもちゃんと載っていたのだが…現時点では削
除されている
XMLHttpRequest自体にも制限が加わり、JavaScriptが置かれた
コンテンツのディレクトリかサブディレクトリのみがアクセス可能
参照: http://www.tokumaru.org/d/20090805.html#p01
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4LE3V825J5.jpg)

きっかけはmpw.jp管理人様の日記
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/V8ED8MZYEG.jpg)

http://mpw.jp/blog/2009/11/188.html より引用
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4V7P8RD278.jpg)

mpw.jp管理人様指摘の方法はDNSリバインディング




DNSの内容を短時間の間に書き換える手法は、DNSリバインディ
ングとして知られている
従来は、ローカルネットワーク内のサーバーを攻撃する手法として
知られていた
ケータイ向けサイトはインターネット上にあるが、IPアドレス制限か
ら、ローカルネットワークと類似の性格を持つ
mpw.jp管理人様指摘の手法は、HTMLソースを読み出すものだ
が、かんたんログイン突破にも応用可能
これはまずい
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/L2JVNR1XEQ.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 192.0.2.2
攻撃者はワナを
準備して誘導
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/Z5EGKM2R7L.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 192.0.2.2
ユーザが
ワナを閲覧
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/V4JQNRPYJP.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 115.146.17.185
攻撃者は
DNSを操作
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/DK74G8YZJ1.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 115.146.17.185
ケータイJavaScript
10秒後に
evil.example.jp
を閲覧開始
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/PLJ1D26DEG.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 115.146.17.185
evil.example.jpの
IPアドレスを要求
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/8GJWYRW872.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 115.146.17.185
115.146.17.185
を返す
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/W4EZXR5973.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 115.146.17.185
iモードIDが送出
X-DCMGUID:xxxXXX9
http://evil.example.jp/
userinfo.php?guid=ON
にアクセス
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/KY764R9DJV.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 115.146.17.185
個人情報を返す
氏名、メールアドレス、
住所、電話番号
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/5G75Q8N8J4.jpg)

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp
115.146.17.185
攻撃対象
evil.example.jp
192.0.2.2
ワナ
example.jpのDNS
evil 115.146.17.185
個人情報をワナの
サーバーに返す
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/V9J2PK5VJR.jpg)

徳丸浩の熱い日







2009年11月22日 mpw.jp管理人様のブログを読む
すぐに、DNSリバインディングにより、かんたんログインが突破さ
れる可能性に気づく
検証専用に新たにドメインを購入して、調査を開始。かんたんログ
インが突破されることを確認
携帯電話事業者設備では対策が困難であり、一方Webサイト側
には効果的な対策が存在することが分かる
そのため、事業者に通知ないし届け出するよりも、一般に公開して
サイト運営者に対策を呼びかけることを決定。
ただし、翌11月23日は祝日（勤労感謝の日）のため、迅速な対応
がとれないと判断し、11月24日まで発表を見合わせた
11月24日HASHコンサルティング株式会社ホームページにて、ア
ドバイザリを公開
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/5DEY5NKQEM.jpg)

25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/2VJNNXR2J8.jpg)

DNSリバインディング対策はケータイ事業者側ではできない



本来はケータイブラウザあるいはゲートウェイで対策するべきもの
ではあるが…
ケータイブラウザはゲートウェイ（PROXY）経由のアクセスなので、
ブラウザでは名前解決をしていない。すなわち、ブラウザでは対策
（DNS Pinning）できない
ゲートウェイはマルチユーザが対象なので、文脈を意識した
Pinningは不可能で、いつかはIPアドレスを切り替えなければなら
ない
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/GYE9R8MD73.jpg)








キャリアのDNSが最低1時間DNSキャッシュする想定では、以下
のような攻撃が可能となる
攻撃者はワナサイトを用意する
攻撃者は自ら携帯電話でワナサイトをアクセスする
ワナサイトのIPアドレスをターゲットサイトのIPに切り替えておく
58分後に、ワナサイトのURLをまいて誘導する
被害者がワナサイトを閲覧した直後に、DNSサーバーのキャッ
シュ保持が無効となる
被害者のブラウザ上でDNSリバインディングを悪用したリクエスト
が発行されるが、既に標的サイトのIPアドレスが有効となり、攻撃
が成立する
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/5GE8W8L57D.jpg)

ゲートウェイIPの変遷
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/MLELNRL3JR.jpg)

Webサイト側でのDNSリバインディング対策



iモードブラウザ2.0のXMLHttpRequestでは、setRequestHeader
メソッドが無効化されているので、リクエストヘッダのHostフィール
ドはワナサイトのドメインになっている
したがって、かんたんログインの際に、Hostフィールドをチェックす
ればよい
簡単に実装するには、名前ベースのバーチャルホストにすればよ
い
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/54JMXRMM7W.jpg)

twtr.jpの事例
http://www.tokumaru.org/d/20100222.html#p01
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/ZPJRNRVL79.jpg)

http://takagi-hiromitsu.jp/diary/20100228.html#p01 より引用
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/NPEXNRW6JX.jpg)

ケータイ2.0がパンドラの箱を開けてしまった
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/63EKNRVGED.jpg)

続いてソフトバンクも…
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/4L73V8M5E5.jpg)

ソフトバンクでもJavaScriptに対応
http://k-tai.impress.co.jp/docs/news/20100518_367787.html より引用
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/V87D8M6Y7G.jpg)

本当に2010年夏モデルからなのか?


実はかなり以前からソフトバンク端末の一部のモデルで
JavaScriptに対応していた
ノキア 702NK(2004年12月発売)では簡単なJavaScriptに対応


804SS(2006年3月)、910T(2006年10月)、910SH(2006年11月)
では、NetFront 3.3によるJavaScript対応



XMLHttpRequestやIFRAME、DOMには対応していない
XMLHttpRequestには対応していない
IFRAME、DOMに対応…攻撃に利用できる可能性*1
922SH(2008年3月)では、NetFront 3.4にてAjaxに対応


XMLHttpRequestのサポート
setRequetHeaderのサポート (!)
実は2006年から、パンドラの箱は開いていた
注 *1: 804SSはIFRAMEに対応していない
35


# Page. 36

![Page Image](https://bcdn.docswell.com/page/4VJP8RY2J8.jpg)

setRequestHeaderはどのヘッダを改変してよいか?
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest より引用・追記
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/L2EVNRGX7Q.jpg)

setRequestHeaderはどのヘッダを改変してよいか?
37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/Z57GKM8RJL.jpg)

これはまずい
(((( ;ﾟд ﾟ))))ｱﾜﾜ
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/V4EQNR9YEP.jpg)

徳丸浩の熱い日2








2009年11月24日朝 『iモードIDを用いた「かんたんログイン」の
DNS Rebinding脆弱性』を発表する
この日の午前中は商談のため外出していた
はてなダイアリーのコメント欄にてナカニシさんという方から、ソフト
バンク端末(932SHで検証)でXMLHttpRequestが動くことを教え
ていただく…外出先にて確認…大変だ
原宿のソフトバンクショップで確認しようとするが、うまくいかず
自宅に移動
地元（横浜市）のソフトバンクショップにて確認するがうまくいかず
ナカニシさんのコメントを信じて932SHを購入する
端末のセキュリティ設定で「Ajax規制」という項があり、デフォルト
は「許可しない」となっていることを確認。「許可する」に変更すると、
XMLHttpRequestが利用可能であることを実機にて確認。
39


# Page. 40

![Page Image](https://bcdn.docswell.com/page/DKJ4G8XZE1.jpg)

徳丸浩の熱い日2（続き）






ソフトバンク端末のXMLHttpRequestでは、setRequestHeaderが
有効であることを確認
setRequestHeaderでHostフィールドを改変できる…だめじゃん
サイト側での即効性のある対策が思いつかなかったため、公開を
保留し、ソフトバンク社に連絡をとることを決意
同日、ツテにより同事象をメール連絡。
ソフトバンクモバイル側の担当者がアサインされる
12月某日、ソフトバンクにて打ち合わせ





問題点と対策案の説明
DNSキャッシュの最短保持時間を延ばすと攻撃を緩和できる
Hostフィールドの改変防止が根本対策
「当面の間は」公表を見合わせることを約束
・・・あまり時間が掛かるようだと、公開する場合もあり得る
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/PLE1D2ND7G.jpg)

その後4ヶ月弱が経過
41


# Page. 42

![Page Image](https://bcdn.docswell.com/page/8GEWYR48J2.jpg)

3月末の某日

ソフトバンク端末にて対策がとられていないか確認



端末のアップデートが動いていないのでダメとは分かっていた
・・・やっぱりダメだった
しかし、DNSの挙動に変化が・・・
42


# Page. 43

![Page Image](https://bcdn.docswell.com/page/W47ZXR29J3.jpg)

ゲートウェイIPアドレスの変遷(ソフトバンク)
DNSのキャッシュを5分間保持
ゲートウェイが切り替わるとダメ
43


# Page. 44

![Page Image](https://bcdn.docswell.com/page/KYJ64RVDEV.jpg)

このままでは攻撃者が気づいてしまう





WASFのタイミング（つまり本日）で、ソフトバンク端末の件は当初
伏せておく積もりだった
しかし、発見・通報から半年経って何のアナウンスもされていない
対策を打つべき機種があまりにも多く、迅速な対応は望めないだ
ろう
Webサイト運営者・開発者はこの問題を知らないが、一人でも気
づいた人が悪用するとまずい
Ajaxが有効な機種は、シャープ製に限られ、デフォルトではAjax無
効になっていると思われた


影響範囲は狭いのではないか
であれば、広く公開して、注意喚起した方がよいのではないか
44


# Page. 45

![Page Image](https://bcdn.docswell.com/page/5GJ5Q8D8E4.jpg)

徳丸浩の熱い日3


他の端末はどうなのか。デフォルトでAjaxが許可された端末は、
本当にないのか
約90種類の端末のマニュアルをダウンロードして調査




費用はかかるが、実機をまとめて検証することを決意



シャープ製のみ「Ajax規制」という項目があり、デフォルトで「禁止」と
なっているものが多かった
マニュアルにデフォルトの記入がないものもあり、挙動は不明
シャープ以外はAjax規制という設定がなく、許可・禁止が不明
費用や時間などを考慮して、60台を3時間で検証することに
5月某日をターゲットに端末および検証ルームを予約
決行 その結果
45


# Page. 46

![Page Image](https://bcdn.docswell.com/page/4LE3V8MGJ5.jpg)

940Pの結果
よしよし
46


# Page. 47

![Page Image](https://bcdn.docswell.com/page/V8ED8M6NEG.jpg)

940SCの結果
940SCを含む4機種が
デフォルト設定でAjaxが有効
Σ(ﾟдﾟlll)ｶﾞｰﾝ
47


# Page. 48

![Page Image](https://bcdn.docswell.com/page/4V7P8RYN78.jpg)

Ajax有効な機種のサマリ
•ただし、SHARPの最新機種943SHのみは、Refererが送出されるが、改変はできない
•△はデフォルトでAjax無効、オプションにより有効化可能（SHARP端末は多いので抜粋）
•上記以外のPanasonic、Toshiba等はAjax無効
48


# Page. 49

![Page Image](https://bcdn.docswell.com/page/L2JVNRGYEQ.jpg)

ソフトバンクの端末は統制がとれていない印象



2010年夏モデル以降が「正式な」JavaScript対応だとすると、これま
でのJavaScript対応機種は、端末メーカーの独自機能なのか
NECとCASIOは、ソフトバンク端末に慣れていなかった。NECは1年
半ぶりのソフトバンク端末、CASIOは初めてのソフトバンク端末
NEC、CASIOとも、Ajax対応した次の機種ではAjaxを殺している


SHARPは新機能の実装にどん欲な一方、慎重な一面も






なにか問題に気づいたのではないか
Ajax機能をon/offでき、デフォルトではoffにしたこと
Refererを無効化していたのは、問題点に気づいていたからでは?
最新の943SHで、Refererを有効化したのは、NetFront3.5で問題が解
消していることを確認したからでは？
メーカー間の情報共有がなされていない印象
iモードブラウザ2.0の教訓も活かされていない
ソフトバンクおよびACCESS社はなにをしていたのか?
49


# Page. 50

![Page Image](https://bcdn.docswell.com/page/Z5EGKM8W7L.jpg)

ブラウザ開発社の責任
インターネットエクスプローラーも昔はセキュリティ上
の問題が多かったが、いち早く自動アップデートの
機能を備え、XSSフィルタを実装するなど、セキュリ
ティ面の貢献も大きい。ACCESS社にも、シェア8割
に見合う責任を果たしていただきたい
http://it.nikkei.co.jp/mobile/special/i-mode10th.aspx?n=MMITi3000023022009 より引用
50


# Page. 51

![Page Image](https://bcdn.docswell.com/page/V4JQNR9QJP.jpg)

幸い、Ajax該当機種はシェアが低く、影響を受けるユーザは少ない
SoftBankの利用統計
アクセスシェア上位20端末
2010年3月の統計
920P
この2機種以外は
すべてSHARP
911T
http://myrt.auriq.com/mobile/jp/statistics/2010/03.php より引用
51


# Page. 52

![Page Image](https://bcdn.docswell.com/page/DK74G8XYJ1.jpg)

ソフトバンク端末向けの対策は?


Ajaxが有効になっている端末については、アプリケーション側にて
即効性のある対策がない
ユーザにブラウザのセキュリティ設定を促す




もしサイト運営者にやる気があれば・・・



Ajax規制のある機種（シャープ製）については、Ajaxを禁止する
Ajax規制のない機種については、スクリプトを無効にする
現在チェックサイトを準備中
チェックサイト作りました http://www.hash-c.co.jp/ajax/chkajax.cgi
現在有効なすべての機種について網羅的な調査をして、デフォルトで
Ajaxが有効な機種を調べ、該当機種ではかんたんログインを無効に
する
・・・しかし、シェアの高いシャープ端末は、ユーザがAjaxを有効にした
瞬間に、脆弱性が生まれる
いっそ、ソフトバンク端末では、かんたんログインを無効にするとい
う考え方もあり
52


# Page. 53

![Page Image](https://bcdn.docswell.com/page/PLJ1D2NNEG.jpg)

能動的攻撃の可能性(再)
53


# Page. 54

![Page Image](https://bcdn.docswell.com/page/8GJWY2MM72.jpg)

ケータイJavaScriptによる能動的攻撃の可能性




iモードブラウザ2.0はsetRequestHeader()が無効化されているの
で、User-AgentやX-DCM-GUIDの変更は不可能と思われる
ソフトバンク端末では、 setRequestHeader()関数自体は無効化さ
れていないが、User-AgentやX-JPHONE-UIDの変更は禁止され
ている
・・・
抜け道はないのか？
54


# Page. 55

![Page Image](https://bcdn.docswell.com/page/W4EZXDQM73.jpg)

2種類のトリックによる端末固有IDの改変が可能

トリック１：End-EndのSSLを使う



キャリアゲートウェイのチェックをすり抜ける
ソフトバンクにはゲートウェイ型のSSLもあるが、こちらはゲートウェイ
のチェックが有効
トリック２：ハイフン「-」の代わりにアンダースコア「_」を用いる

リクエストヘッダ中のハイフンは、アプリケーションが利用する際にア
ンダースコアに変更される仕様を悪用
55


# Page. 56

![Page Image](https://bcdn.docswell.com/page/KY764165JV.jpg)

SSLを利用したリクエストヘッダ改変スクリプトの例
var requester = new XMLHttpRequest();
requester.open('GET', 'https://example.com/login.php', true);
requester.onreadystatechange = function() {
if (requester.readyState == 4) {
onloaded(requester);
}
};
requester.setRequestHeader("Host", "twtr.com");
requester.setRequestHeader("User_Agent",
"SoftBank/1.0/943SH/SHJ001/SN359XXXXXXXXXXX0 " +
" Browser/NetFront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1");
requester.setRequestHeader(
"X_JPHONE_UID", "a3XXXXXXXXXXXXXP");
requester.send(null);
56


# Page. 57

![Page Image](https://bcdn.docswell.com/page/5G75Q46GJ4.jpg)

アプリケーションが受け取ったリクエストの例（一部）
HTTP_USER_AGENT=DoCoMo/2.1 P07A3(c500;TB;W24H15)Fake
SERVER_NAME=twitter.com
SERVER_PORT=443
HTTP_COOKIE=aaa=bbbx
REMOTE_ADDR=123.108.237.4
SERVER_PROTOCOL=HTTP/1.1
HTTP_X_JPHONE_UID=fakejphoneuid
HTTP_X_DCMGUID=fakedcmguid
HTTP_X_UP_SUBNO=fakesubno
HTTP_HOST=twitter.com
※URLと証明書のドメインが異なるので警告が出るが、処理は続行可能
57


# Page. 58

![Page Image](https://bcdn.docswell.com/page/V9J2PVMDJR.jpg)

ＳＳＬを悪用した能動型なりすまし攻撃への対策

SSLではかんたんログインを受け付けない


必須はソフトバンクのみ禁止だが、全キャリア禁止することが無難
キャリア判定は、User-Agentではなく、IPアドレスで行う
58


# Page. 59

![Page Image](https://bcdn.docswell.com/page/5DEY53XMEM.jpg)

まとめ


かんたんログインに対して、ケータイJavaScriptによる攻略手法が
わかってきた
かんたんログインに際しての必須対策







これで完璧かどうかは誰にも分からない



キャリアゲートウェイのIPアドレスとのみ通信を制限する
キャリアの判定にもIPアドレスを用いる
Hostヘッダのチェック（あるいは名前ベースのバーチャルホスト）
ソフトバンク端末については、Ajax規制あるいはスクリプトの禁止
SSLでは、かんたんログインは行わない
・・・
とくに、ソフトバンク端末のように機種依存性が多いと、全ての端末に
ついて検証しないと確かなことは言えない
それでも、まだ、かんたんログイン続けますか？
ケータイセキュリティについてオープンに議論できる場の必要性
59


# Page. 60

![Page Image](https://bcdn.docswell.com/page/2VJNNV13J8.jpg)

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