IE9のUIとhttpsの小さな不整合
IE9のUIで気になることがあり、歯切れの悪い記事を書きます。
アドレスバーと検索欄を統合したせいで、httpsのURLなのにパス以降が漏れちゃう場合がある、という話です。
小さな懸念
IE9の新機能の一つとして「アドレス バーでの検索」( http://windows.microsoft.com/ja-JP/internet-explorer/help/ie-9/whats-new-in-internet-explorer-9#section_6 )があります。
これは、
アドレス バーに検索の候補を表示するオプションもありますが、入力した内容を検索プロバイダーに公開したくない場合もあるため、既定では無効になっています。と説明されている通り、オプトインで検索候補を表示するように設定すると、意図しない情報漏洩の懸念があるわけです。
具体的に言うと、ユーザが「URLを入力したつもり」の場合でも入力内容が送出されるのが問題です。（「検索語を入力したつもり」の場合は入力終了後に送出される前提なので問題にならないでしょう。）
問題無い？
「URLぐらい漏れてもいいじゃん」という見解もあるかもしれませんが、たとえばhttpsのURLの場合に嫌な感じなのですよ。本来SSLでは次のことが約束されるはずなのです。*1 *2
- 経路上でURLのパス以降が秘匿される
- サイト外にリファラを送出しない
WinInetに入ってるHTTPヘッダっぽい文字列
はせがわようすけさんの記事「1分でわかる「X-ナントカ」HTTPレスポンスヘッダ」（ http://d.hatena.ne.jp/hasegawayosuke/20110107/p1 ）を読んで、IE9（
正確に言えばWinInet.dll）がバイナリに持っているヘッダっぽい文字列を探してみました。
環境
- Windows7 Ult. / InternetExplorer 9 beta
- WinInet.dll ファイルバージョン:9.0.7930.16406
記録までに以下に載せておきます。（当てずっぽなので、また、ちゃんとチェックしてないので、間違いがあるかもしれません。）
Accept
Accept-Charset
Accept-Encoding
Accept-Language
Accept-Ranges
Age
Allow
Authentication-Info
Authorization
Cache-Control
Connection
Content-Base
Content-Description
Content-Disposition
Content-Encoding
Content-Id
Content-Language
Content-Length
Content-Location
Content-Md5
Content-Range
Content-Transfer-Encoding
Content-Type
Cookie
Cost
Date
Default-Style
Derived-From
Etag
Expect
Expires
Forwarded
From
Host
If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Last-Modified
Link
Location
Max-Forwards
Message-id
Mime-Version
Ms-Echo-Reply
Ms-Echo-Request
Orig-Uri
P3P
PassportConfig
PassportURLs
Pragma
Proxy-Authenticate
Proxy-Authorization
Proxy-Connection
Proxy-Support
Public
Range
Referer
Refresh
Retry-After
Server
Set-Cookie
Title
Transfer-Encoding
Translate
Unless-Modified-Since
Upgrade
Uri
User-Agent
Vary
Via
WWW-Authenticate
Warning
X-Content-Type-Options
X-Frame-Options
X-P2P-PeerDist
X-UA-Compatible
X-XSS-Protection
以上
Adobe Flash Player の最新バージョン情報が古くてひどい
2010年6月で時が止まってる
AdobeのFlash Player のバージョンテストページってありますよね。
■Adobe - サポート - Adobe Flash Player のバージョンテスト
http://www.adobe.com/jp/support/flashplayer/ts/documents/tn_15507.htm
10,1,85,3がインストールされてます。最新版っていくつだっけ？確認するためにページの下の方を見ると。
次の表に、最新の Flash Player バージョンに関する情報を示します。
Windows Internet Explorer 10.1.53.64
（略）
更新日 : 2010年6月15日
これはひどい。6月時点で情報が止まってる。。。8月と9月にアップデートがあったはずなのに、無視されてます。
誰も見てないページなのでは？
ひょっとしたら、古くて誰も見ないようなページが残ってるだけで、実害は無いのかも。（好ましくはありませんが。）
というわけで、「flash バージョン」とか「flash version」でググってみました。
このバージョンテストページページがトップに出てきましたよ。
権威
■情報処理推進機構：情報セキュリティ： Adobe Flash Player および Flash を扱う製品の脆弱性について
http://www.ipa.go.jp/security/ciadr/vul/20100921-adobe.html
2010年 9月21日掲載のIPAの脆弱性情報でもこのページにリンクされてます。
自社
そもそも、Adobe自身がこのページをまだ使っています。
■Adobe : Flash Playerサポートセンター - Flash Playerヘルプ＆サポート
http://www.adobe.com/jp/support/flashplayer/
リンクされてますね。つまり、現役バリバリの生きたページだってこと。
危険性
Adobeの意向を想像すると、多分、代わりにこっち（ http://www.adobe.com/jp/software/flash/about/ ）を見てくれってことなんだと思うけど、旧ページに何の案内も無いので分かる訳がない。今の状況ではユーザが古い情報を見て、結果的に脆弱性を放置してマルウェアの被害に遭う可能性がある。
オチ？
ま、韓国よりはマシかもしれません。
http://www.adobe.com/kr/support/flashplayer/ts/documents/tn_15507.htm
（ハングル読めないからよく分からないけど、2006年から放置中っぽい。）
以上
Internet Explorer 8 にはアドオンの「Upgrade Advisor」機能があるらしい
知らなかったのですが、Internet Explorer 8 には「Upgrade Advisor」という機能が備わっていて、起動時に「アドオンのバージョンが古いですよ」というチェックをしてくれるんですね。
Add-on Guidelines and Requirements in Action – Upgrade Advisor - IEBlog ( http://blogs.msdn.com/b/ie/archive/2010/08/11/add-on-guidelines-and-requirements-in-action-upgrade-advisor.aspx )
IEBlogの記事によると、大雑把に言って、ツールバーなどを対象にしたUIのガイドラインに沿ったバージョンをお勧めするのに使われているらしいです。
そんなことより、Firefoxみたいに、FlashとかAdobe ReaderとかJavaとかの脆弱性を悪用されてるプラグインをアップデートさせるのに使ってくれよ、と思ったのは私だけでないはず。（ひょっとしたらそのように使われてるのかもしれませんが、記述が見つからなかったので。）
以上
かんたんログインの代替案を考えてみたりした
携帯Webのことはあまり知りませんが、「かんたんログイン」代替案を考えてみました。
- あくまでもヨタ話レベルです。
- 実際に実装・運用されているものもあるかもしれません。
- 認証しか考えてません。セッションの維持は定番の方法があると思いますので。
要はクライアントストレージでしょ
cookieが使えないので、その代替を考えます。キーをどこに保存するかという問題なのですが、実運用を考えると、交換のタイミングとかも考えないといけない。
メール
サイトから、秘密のID付きURLを記したメールを登録メールアドレスに配信しておきます。メールを開いてリンクをクリックすればID/パスワードの代わりに。
メールって平文では？みたいな話もあるけど、携帯ネットワークで送られてくるメールは多少安全だったりしないかな？（知らないのだけど。）
画像
画像ファイルをHTMLのファイルアップロードでパスワードの代わりに送ればいいじゃん！と思ったけど、input type=fileに対応してる携帯が少ないそうだ。残念。
保存はできるのにね。
ブックマーク
秘密のID付きURLのページをブックマークしてもらって、それを開けばID/パスワードの代わりに。これは実装ありそう。
ちまちまパスワード打つのが面倒なんでしょ
携帯でID/パスワード方式が嫌われる理由は、携帯のキーでID/パスワードを入力しづらいからというのが一つの原因。（利用者層や利用シーンの違いもあると思うけど。）というわけで。
日本語
ID/パスワードに日本語使わせよう。自分もそうなんだけど、携帯でアルファベットを打とうとすると、とたんにぎこちない初心者みたいになる。
声
電話なんだからログインする際に電話をかけて合い言葉を言うようにしたらいいんじゃないか。コンピュータテレフォニー的な何か。
周りに聞こえるとか電車の中とか難あるけど。音声通話とネットのアクセスをどうやって対応づけるのか微妙だけど。
顔
最近はテレビ電話もできるから、顔認証でどうだ。
画像
HTMLのファイルアップロードに対応してる機種が少なくても、メールで画像を送るのは出来るはず。それが俺のパスワードだ。
最後の方、ぐだぐだになってしまいましたが、「ID/パスワード方式じゃなかったら即かんたんログイン」、というのはちょっと待って、代替案もあるかもしれない。って話です。
なお、認証方式の自前設計実装は慎重に。では。
そのiPhoneのブックマークレットは安全ですか
以前、京都に本社のあるH社サイトの脆弱性を報告した（http://d.hatena.ne.jp/kogawam/20100223/1266942303 ）という記事を書いたのですが、その後始末を。
概要
iPhone向けはてなブックマークレットは、シナリオによっては悪意のあるコードを仕込まれる可能性があった、という話です。
詳細
iPhone向けはてなブックマークレット導入ページあるじゃないですか。
http://b.hatena.ne.jp/help/touch/bookmarklet?javascript:（以下略）
あのページは「?」以下に引き渡されるブックマークレットコードが渡されたまま通ってたんですね。
だから、ユーザがページに書いてある指示に従って「?」以下のJavaScriptコードをブックマーク登録＆実行すると、悪意のあるJavaScriptコードが発動する可能性があった。
具体的に言うと、例えば、どこかのページからこういうリンクを踏んで、ブックマークレット導入ページに飛んで来た場合です。
↓はてブのiPhoneブックマークレットです。とても便利でちょうおすすめです！
http://b.hatena.ne.jp/help/touch/bookmarklet?javascript:alert('こんにちは！');
この場合ブックマークレットを実行したら、こうなりますね。
任意のJavaScriptを仕込めるでしょうから、もっと悪いこともできますよね。効果としてはXSSと同じじゃないかと思います。
McAfeeのサイトから知らないドメインに飛ばされてフィッシングかと疑うの巻
先週「McAfeeがパスワードを生で持っている件」（ http://d.hatena.ne.jp/kogawam/20100314/1268583017 ）というエントリを書いてこう締めました。
なお、本件とは関係なくマカフィー製品は現在使ってないので、アカウントとかクレジットカード情報は消去してもらおうと思います。というわけで、消去しようとしたらマカフィーサイトのドメインがバラバラというテイタラクだったので、記録します。
世界的なセキュリティ会社として有名なマカフィーですが、ウェブサイトのドメインが統一されておらず、利用者にフィッシングの疑いを抱かせる状態のようだ。（もしくは改ざんされている。）確認したのは、アカウント削除の手順を指示通りに実施したら、知らないドメインに連れて行かれること。
確認手順は以下のとおり。
ログインして、プロフィール編集画面を開きます。（httpsでmcafee.comドメインですね。）
すると下の方に「お客様の登録情報の削除をご希望される場合は、マカフィー・カスタマーオペレーションセンターまでお問い合わせください」というリンクがあるので、そこをクリックします。
次に個人情報に関する説明が表示されるので、「同意する」をクリックすると、
問い合わせフォームにたどりつくので、ここに用件を入力して送信するという次第です。*1
そうそう、個人情報を入力する前にはブラウザのURL欄を確認するのが鉄則ですね。
あれー。nac-support.com って何それ？*2
mcafee.com は信用していいと分かってるけど、nac-support.com を信用していいのかどうか、判断がつきませんでした。
折しも、高木浩光氏が「音楽著作権団体らの杜撰なアンケートがフィッシング被害を助長する」（ http://takagi-hiromitsu.jp/diary/20100320.html#p01 ）というエントリを書いてるのですが、似たようなことをセキュリティ専門会社もやってました、という話。
