<前の日記(2003年07月10日) 次の日記(2003年07月13日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2617   昨日: 1295

2003年07月12日

アドレスバーをどうするか

日経IT Proの7月10日の記者の眼に、「Flashに感じる不安」というコラムが出ていた。その読者コメントを見ると、コラムの趣旨を正しく理解できていないシステムインテグレータのSEが少なくないことがわかる。

著者の尾崎氏は、日経システム構築5月号に「警鐘●危険なネット銀行を作るな」という記事を書かれた方だ。そこには、「サイトなりすましの死角」という節で、アドレスバーを隠すことのセキュリティ上の問題点が書かれている。

今回の記者の眼は、「Flashに感じる不安」というタイトルになっているが、指摘されている問題点は、アドレスバーを隠すことの一点に尽きる。その意味では、Flashそのものが本質なのではない。

このコラムが誤解を招いたのは、まず第一には以下の部分が原因だろう。

サイト運営者や開発者によれば,セッション管理で問題を発生させないために,URLを表示しないのだという。...

ところがFlashの場合,HTMLのページ単位ではなく,オブジェクト単位でサーバーと通信したり再描画したりできる。...

つまり,ページ単位でのセッション管理という概念が無い。... このため,その通信の最中に,利用者にブラウザの「戻る」ボタンを押されたり,勝手なURLを記述されたりしてページを移動されると,トランザクション処理が途中で失敗する可能性がある。

「トランザクション処理」が途中で失敗するのはHTMLでも同じだ。ブラウザウィンドウが通信の途中で閉じられたときの不整合の回避は、開発系メーリングリストでよく出てくる質問で、それはいずれにせよ必要な対策だ。

この部分は、「トランザクション処理」と書かなければ誤解を招かなかったかもしれない。記者の取材に対して「サイト運営者や開発者」がしたであろう説明は、おそらく、「戻る」ボタンが押されたりURLが変更されると、元のページに再び戻ったときに、Flashムービーが再スタート状態になってしまうことではなかろうか。

通常のWebアプリケーションの操作に慣れている消費者は、操作を間違えると「戻る」ボタンを押す癖がついているだろう。多くのWebアプリケーションでは、それで問題なく操作を続行することができる。しかし、アプリケーション全体が1個のFlashムービーとして作られている場合、途中で「戻る」ボタンを押すと、Flashムービーより前のページに戻ってしまい、「しまった」と気づいて「進む」ボタンを押しても、Flashは先頭から再生されてしまう。このことは、コラム中では以下のように書かれている。

ECサイトで住所や商品を途中まで入力したところで処理が失敗し,いきなりログイン画面に戻ってしまうと,利用者もやりきれないだろう。怒った利用者がそのサイトを立ち去る恐れもある。これを考えれば,アドレス/メニュー・バーを非表示にしたくなる開発者の意図が分からないでもない。

ちなみに、こうしたことはJavaアプレットでは起きない。起きないように作ることができる。「戻る」を押して、「進む」を押したとき、前の状態を継続できるように作ることができる。Flashではそれができないのだろうか。そういう意味では、これは Flashならではの問題と言えるかもしれない。

これに対して、読者コメントには次のような声があがっている。

「戻るボタンを押さないでください」とかいくら注意書きを大きい字や目立つ色で書いても、それを守ってくれるのは、一部の良くわかってる人だけで,一般ユーザは絶対押すし、「戻れないのはおかしい」とか「何にもしてないのに(!)おかしくなった」等のクレームが必ずくる。

まあそうなのだろう。だが、「戻る」ボタンを押せなくすることと、アドレスバーを隠すこととは別だ。「戻る」ボタンを消す、つまり、ツールバーを隠して、アドレスバーは隠さなければいい。具体的には、次のようなJavaScriptコードにすればよい。

window.open("http://...", "...", "location=yes,toolbar=no,status=yes, ...");

そうすると、サイト運営者は、

勝手なURLを記述されたりしてページを移動されると,

という懸念を主張するのだろう。だが、わざわざアドレスバーのURLを書き換えてページ移動した人が、「戻れないのはおかしい」とか「何にもしてないのに(!)おかしくなった」とかの文句を言うだろうか?

記者がそこまで突っ込めなかったのは残念だ。相手の主張をあっさり認めてしまっている。その結果、「Flashに感じる不安」と矛先が Flashに向いてしまい、論点がぼけている。

「銀行」、「Flash」と言えば、ソニー銀行が該当する。http://moneykit.net/ で右上角の「ログイン」の部分をクリックすると、アドレスバーなどが隠されたポップアップウィンドウが開く。ここでログインすると、Flashムービーで作られたアプリケーションが起動するようになっている。たしかにこのサイトでツールバーが表示されていると、「戻る」ボタンを押し、操作を途中でパーにしてしまう輩が続出するだろう。だが、それはアドレスバーを隠す理由にはならない。百歩譲って、URLを書き換えて文句を言う人がいるとしよう。では、ソニー銀行がステータスバーも隠している理由は何か。理由はないだろう。SSLの鍵マークすら消し、サーバー証明書の確認すらできないようにして平気な面をしているのは、なぜなのか?

結局のところ、サイト運営者や開発者の説明はその場しのぎの言い訳でしかない。セキュリティに無頓着に作ったものの、後でそれを指摘されても、直さない。直さないことを正当化することからまず考えるというわけだ。

ちなみに、アドレスバーを隠す行為を増やしていると考えられる、もうひとつの原因がある。それは、ウィンドウサイズを指定した window.open のデフォルト動作にある。以下のコードのように、ポップアップウィンドウを開くとき、ウィンドウのサイズは、3番目の引数に文字列として指定する

window.open("http://...","...","width=100,height=100")
このとき、デフォルトで、ツールバーも、アドレスバーも、ステータスバーも表示されない。これらを表示させるには、わざわざ次のように書いてやる必要がある。
"width=100,height=100,location=yes,toolbar=yes,status=yes,menubar=yes"
この方法を知らない(調べるのをサボる)開発者がいることも影響しているのではなかろうか。「ポップアップウィンドウとはアドレスバーを表示しないもの」という流行ができてしまったのは、ここに原因があるように思える。

さて、そのアドレスバーを隠すことの危険性だが、これは6月14日の日記「HTMLメールマガジンのもうひとつの危険性」でも述べた。

どうにもこう、アドレスバーを隠したポップアップウィンドウがやたらと不用意に使われているという実態がある。警察庁ですら警戒が足りないようで、警察庁の「@police」サイトの中央下に並んでいる「topics」というところの「重要」情報のリンクをクリックすると、アドレスバーを隠したポップアップウィンドウが現れる。この画面に見慣れている人は、「平成15年6月10日 警 察 庁」とさえ書かれていれば、本物と信じてしまう習慣が身についているかもしれない。このような「重要なお知らせ」を、ポップアップで出す意義がいったいどこにあるのだろうか。...

今回のコラムの読者コメントを見ると、URLを隠すことの問題点を理解していないものが少なくない。

フレームを使えば単なるHTMLだけでもURLを隠すことはできますし、本質的な問題ではないように思います。「セキュリティや安心感」は、そういう外観上の問題では全くありません。 ...

(30代,その他,研究・開発部門 )


Flashに限らず、根本的なHTTPの限界であると思います。この問題の回避策はサイトのデザイナーよりも、開発側が行うべきでしょう。セキュリティに不安のないシステムならURLを隠しても大丈夫では? ...

(30代,システム・インテグレーター,システムエンジニア )


URLが隠されていること、Flashだけで構成されていること、そんなところが問題だと思うのは、やはり「昔から」ブラウザに依存しているベテランだと思います。 ...

(20代,システム・インテグレーター,システムエンジニア )


URLどうこうというのはシステム屋っぽい発想だなと。一般の人がURLを頼りにしているというのは、本当だろうか? ... 私の皮膚感覚では、URLなど誰も見ていない。

(20代,その他,システム企画部門 ) 


たしかに、URLを見ていないユーザは多いだろう。しかし、URLを見ない限り、偽サイトに騙されることは防ぎようがないのだ。ユーザがそう心がけるように常識を作っていくしかない。

その一方でこんなコメントもあった。

ん?HTTPSの最初のページだけフレームもFlashもなくアドレスバーを表示した状態(ようするにURLをアピールした状態)で表示していれば問題ないのでは?ユーザはHTTPSの最初のページを開いたときにアドレスバーのURLを確認します。そこからのリンクをたどって表示されるものはフレーム、Java、Flashによらず信頼できることになります(サイトがちゃんとHTTPSから出ないようにできていればですが)。 ...

(40代,ハード・ソフトベンダー,経営者 )

これはその通りだ。ユーザが必ずそうするならば問題ない。しかし、アドレスバーを隠したポップアップウィンドウが流行していることの問題は、アドレスに無頓着なユーザを増やす悪影響があるという点だ。IT Proにコメントを書くようなシステムインテグレータのSEでさえ、その意味を理解していないのだから。

ところで、携帯電話のブラウザの場合、そもそもURLは画面上に表示されない。URLを確認する機能はメニューから呼び出せるようだが、ほとんど誰も使ってないだろう。これは画面が狭いことが原因なのだろうが、これでいいのだろうか。

PC用のWebブラウザにアドレスバーが付いているのは、飾りなのではない。アドレスバーのことを「URLを入力するところ」と理解している人が多いだろうと思うが、大昔の1994年ころのブラウザは、アドレスバーはURLを表示するだけで、書き換えることはできなかったものだ。つまり、WWWという仕組みを考え出した人達は、初めから、ユーザがURLを目視することの重要性を意識してこの機能を設けていたはずだ。

携帯電話の画面が狭いとはいえ、最下部にはアクセス中の状態を表示する部分がある。そこに、ドメインだけでも表示させることはできるのではなかろうか。

ベリサインのルート証明書配布

1か月半ほど前の話になるが、ソニー銀行から「ログインに関する重要なお知らせ」というメールが来た。要点はこうだ。

2003年5月27日以降、一部のブラウザーをお使いのお客さまがサービスサイトにログインしようとすると、「セキュリティの警告」メッセージが表示され、ログインが拒否される場合がございます。...

※Microsoft Internet Explorer5.01以降、またはNetscape4.7以降のブラウザーをお使いの場合、この問題は発生しません。...

インターネット上でDigital ID(電子証明書)の発行を行っている日本ベリサイン株式会社発行の最新の電子証明書に、上記のブラウザーが対応していないことが原因です。...

以下のいずれかの対応をお願いいたします。
(1)ご利用のブラウザーのバージョンアップ
(2)ご利用のブラウザーへの最新電子証明書のインストール

そして、次のように案内されていた。

なお、詳細・解決手段については日本ベリサイン社のホームページに掲載されています。大変お手数ではございますが、お客さまご自身でご確認いただき、ご対応くださいますようお願いいたします。
http://www.verisign.co.jp/server/cus/rootcert/for_ie4xuser.html

その日本ベリサインの説明ページを見てみると、「最新ルート証明書」というところに、「インストールページ」というリンクが用意されている。ここには、

お客様が自らの責任で独自にルート証明書をインストールすることに同意された上で、以下のボタンをクリックしてください。

と書かれており、これは、ルート証明書を手作業でインストールする行為が危険を伴うものであって、通常の行為ではないということを、「自らの責任で...」という文章によって暗に示したものだ。

しかしそのことにいったいどれだけの人が気づくだろうか。この「同意する」ボタンと説明は、責任を回避するためのものでしかない。もうちょっと、しっかりと、これは通常とるべき行為でないことを説明してはどうか。日本ベリサインは、PKI文化を安全に広める主導的立場にあるのだから、そうした説明も重要な仕事のひとつだろう。

で、この「同意ボタン」を押すと、ルート証明書がダウンロードされるわけだが、このリンク先は、https://www.verisign.com/...となっている。HTTPSでダウンロードさせるのはよいことだ。だが、これだけでは安全なものにはならない。

ルート証明書のダウンロードという(盗聴が問題にならない)場面でHTTPSを使うのは、通信路上での改竄を防止するためと、DNSスプーフィング攻撃などにより偽サイトにユーザが騙されることを防止するためなのだが、いくらこの「同意する」ボタンのリンク先だけを https://...にしても、元の画面(ポップアップしたウィンドウ)が http://であれば、そのウィンドウが偽の可能性があるのだから、安全になってはいない。

こういうとき、消費者がとるべき行動は、ウィンドウのアドレスバーで、「http:」の部分を「https:」に変更してアクセスしてみて、間違いなく本物にアクセスしていることを確認した上で、「同意する」ボタンを押すことだ。そうすれば、改竄やなりすましが起きていないことが保証される。

これは本来、消費者が自らの責任で安全確認をすべきことなのだが、そうは言ってもなかなかそれは認識されていない。であれば、より安全にするため、日本ベリサインや、ソニー銀行は、次のようにすることができたはずではなかろうか。

日本ベリサインにできたはずのこと
「インストールページ」で開くポップアップウィンドウのURLを https://にしておく。そして、ユーザへの説明として、「このウィンドウのURLがhttps://www.verisign.co.jp/... であることを確認し、この画面が間違いなく日本ベリサインのものであることを確認してください」などといった説明をする。

たとえこのようにしても、ユーザが見ている画面がはじめから偽サイトであれば、この説明も現れないわけで、騙されてしまうかもしれない。しかし、偽サイトへの誘導という攻撃にさらされていない大多数のユーザには、こうした説明が教育的効果をもたらす点で意義がある。

ソニー銀行にできたはずのこと
お知らせメールで、URLを次のように、https://にしておき、はじめから安全な通信となるようにする。
https://www.verisign.co.jp/server/cus/rootcert/for_ie4xuser.html

検索

<前の日記(2003年07月10日) 次の日記(2003年07月13日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2003年07月10日) 次の日記(2003年07月13日)> 最新 編集