高木浩光＠自宅の日記

■ オレオレ証明書の区分 改訂版

はてなキーワードに「オレオレ証明書」の項目ができていた。 ここにある冒頭の「(特にPKI上不適切な場面で使われる)自己署名証明書。」 という定義は私の定義とは異なる。自己署名とは限らないし、 不適切な場面とも限らないからだ。 そのためその下にある第一種〜第五種の区分の記述と矛盾が生じている。

私の定義では、クライアント側で認証パスを辿れない（検証できない）証明書 のすべてをオレオレ証明書としている。それは、サーバ側の設定ミスかもしれ ないし、設定が正しくても今まさに通信路上で攻撃を受けているのかもしれな い。証明書の発行の意図に関係なく、クライアントから見れば等しく「オレオ レ」と言っているようにしか見えない。

攻撃を受けている場合を除いて、クライアント側でオレオレ証明書となる場合 の、その原因別の区分を9月3日の注釈で書 いていた。他に第六種もあったので追記して以下に再掲する。

第一種オレオレ証明書

不特定多数に利用させることを想定していて、ルート証明書もサーバ証 明書もインストールさせるつもりのないもの。

第二種オレオレ証明書

不特定多数に利用させることを想定していて、ルート証明書かサーバ証 明書をインストールするよう促しているが、インストール方法として安全な手 段が用意されていないもの。

第三種オレオレ証明書

不特定多数に利用させることを想定していて、ルート証明書かサーバ証 明書をインストールするよう促しており、安全なインストール方法が用意され ているもの。

第四種オレオレ証明書

特定の者だけに利用させることを想定しているもの。

第五種オレオレ証明書

正規の認証局から取得したサーバ証明書であるが、一部のクライアント でその認証局がルートとして登録されていないもの。

第六種オレオレ証明書

正規の認証局（中間認証局）から取得したサーバ証明書であるが、中間 認証局の証明書をサーバに設置していないため、クライアントが認証パスを検 証できないもの。

ここではSSLのケース（サーバとクライアント）で示したが、同様に、S/MIME や、コード署名、その他文書への署名等のPKIにおいても同様となる。

■ Phishing被害者の実例

まつもとゆきひろ さんがPayPalを騙るphishingに引っかかってしまったそうな。たいへんだ。

以前、phishingの話題でテレビ局の取材を受けたときに、「実際に被害に遭っ た方をご存じないですか？」と相談された（映像に使う必要がるのだろう）の だが、あいにく紹介できる人がなかった。もし次の機会があったら、 まつもとさんを紹介しよっと。 きっと臨場感たっぷりに状況を語ってくれるに違いない。

■ ISPのパスワードを破ってメールを奪回する子供向けゲーム

「どうしよう…あんなメール出さなければよかった…」 「なんとかメールを取り戻してみよう！」と、 4つの「ISP」のうちいずれか2か所の「パスワード」を素早くクラックして メールを奪回するという、子供向け教育ゲーム（警察庁ご謹製）。

■ 攻撃者視点ではなく開発者視点での解説を

8月に@ITに「機密情報に合法的に近づけるWebアプリケーションを守れ」という記事が 出ていた。 タイトルからして意味がわからない。「合法的に近づける」とは何だ？ 英文 の直訳か何かか？

その連載第2回「多様化するWebアプリケーションへの攻撃」が今日掲載されたのだが、問題を正しく理解し ないまま書かれた記事と言わざるを得ない。例えば次のように書かれている。

この例では、「userid=-20298745283」がクエリストリング にあたる。クエリストリングはURL内に含まれているため、誰でも見ることが できる。従って、ユーザーのちょっとした出来心やいたずら（例えば 「この数字の最後を1つだけずらせばどうなるかなー？」） によって、脆弱性が露見することも多い。

この例であれば、誰が見ても明らかなように、「userid」のパラメー タがユーザー管理に使用されており、数字を変えればほかのユーザー になりすませるのではないかと想定できるのだ。このクエリストリング内の情 報を任意に書き換え、Webサイト管理者にとって想定外の結果を引き起こすの が、パラメータタンパリングである。

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

いいかげんなことを言ってもらっては困る。URLに「userid=1234」と書かれて いるからといって、その値がセッション追跡（ユーザのログイン状態の管理） に使われているとは限らない。

たとえば、表示するページのIDを指定するパラメタとして処理されている場合 だってある。blogやSNSのWebアプリケーションなどがまさにそうだ。具体的に は、

http://d.hatena.ne.jp/?userid=HiromitsuTakagi

というURLがあるときに、「HiromitsuTakagi」以外のIDでログイン中の人（も しくはログインしていないゲスト）がこのページにアクセスした場合には、 「HiromitsuTakagi」の日記ページが普通に表示され、「HiromitsuTakagi」の IDでログインしている人がアクセスした場合には、編集権限付きの画面として 表示されるというのは、ごく普通のことだ。

URLパラメタにユーザIDらしきものがあるとき、直ちにそれが脆弱性であると 推定してよいのは、ログイン時にcookieが発行されていない場合である。にも かかわらず、記事の続きを見ると、

この例におけるパラメータが、ユーザー認証が行われた後、ユーザーが送信するURLのクエリストリングに付与されており、何度ログオンし直しても同じ値であった場合、ほぼ間違いなく固定のユーザーIDとして使用されている。こういう場合、通常Webアプリケーションは、ログオンごとに動的に生成されるセッションCookieを併用した設計となっている。

このとき、攻撃者はセッションCookie生成のメカニズムを知ろうとするだろう。

とあり、cookieでセッション管理されている場合を想定しているようだ。わけ がわからない。

このとき、攻撃者はセッションCookie生成のメカニズムを知ろうとするだろう。 もっとも、クエリストリングに重要な情報を入れてしまうこと自体、以下の危 険性が指摘できる。

1. Webブラウザのキャッシュ
2. リファラ（Referer）
3. プロキシやファイアウォール

この話題を出すなら、「URLにユーザID」というストーリーではなく、URLにセッ ションIDの例で説明するのがよい。

記事の2ページ目も微妙におかしい。

まず、「Cookieポイズニング（Cookie Poisoning）」という用語がおかしい。 Cookieであろうが、POSTのhiddenパラメタであろうが、URLパラメタであろう が、それはパラメタの部位が異なるだけであって、ブラウザが勝手な値を送信 してくるという脆弱性の理屈は全く同一であり、それぞれを、poisoningだの、 manipulationだの、tamperingだのと呼び分けるのがくだらない。（いずれも manipulationで統一すればよい*1。）

そもそも、Cookie Poisoningとは本来別の意味で用いられる用語だった。たと えば、2000年2月に発表された CERT Advisory CA-2000-02 を見よ。次のよう に書かれている。

Attacks May Be Persistent Through Poisoned Cookies

Once malicious code is executing that appears to have come from the authentic web site, cookies may be modified to make the attack persistent. Specifically, if the vulnerable web site uses a field from the cookie in the dynamic generation of pages, the cookie may be modified by the attacker to include malicious code. Future visits to the affected web site (even from trusted links) will be compromised when the site requests the cookie and displays a page based on the field containing the code.

CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests

これはクロスサイトスクリプティング脆弱性について最初に発表された文献だ が、その様々な脅威を列挙する中で、この部分は、cookieをセットする JavaScriptが埋め込まれたときに、ユーザのブラウザに悪意あるcookieがセッ トされて、それが永続的に当該サイトへの攻撃となる場合があることを述べて いる。

このように、poisoningとは本来、被害者のコンピュータに攻撃者が毒を盛る ことを指す用語だろう。「DNS Cache Poisoning」だってそうだ。 自分のブラウザのcookieの値を変更して脆弱サイトに攻撃を仕掛ける行為を、 「Cookie Poisoning」と呼ぶのは臍で茶が沸いてしまう。

どうにもこう、攻撃者視点の人達（つまり「ハッカー」）は、問題の本質を理 解していないことが多い。「こうやればああなる（場合がある）」ということ をただ知っているだけなのだろう。おどろおどろしい言葉を無駄に使いたがる 傾向もある。

続いて、ページの最後に、

この後、sendボタンをクリックすればあらゆる商品を自分の好きな金額で購入することができる。ここでは商品1から3まですべて100円に書き換えている。

この攻撃からサイトを守るには以下の方法がある。

• 金額など、改ざんによる誤った処理がされる可能性のある内容をCookie として格納しないようサーバプログラムの仕組みを変える
• サーバなどでCookieを暗号化し、人間が判読できないようにする

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

とあるが、正統な解決方法である次が抜けている。

• アクションを実行する（注文を確定させる）最後のページで、再度デー タベースから商品番号で単価を検索して使用する。

そもそも、単価をcookieに入れるというこの種の作り方は、セッション追跡機 構のないWebアプリケーション構築手法をとらざるを得ない場合（ユーザ登録 機能がなく、単発で住所入力をして注文するタイプのサイト）によく使われ るものであって、注文画面の途中経過ページにおいて、必要な情報を前のペー ジから引き継いで画面表示させることで、ページ毎にデータベースを検索する というコストを削減するためにやっていることだ。だから、その前提があると きに、「cookieとして格納しないよう」というのは解決策ではない。

さらに記事の3ページも問題が多い。

クロスサイトスクリプティング（Cross Site Scripting）

（略）

この攻撃は性質上、広範囲に広がりやすい。非常に大きな 被害を出した複合型ワーム「Nimda」もクロスサイトスクリプティングを感染手段の1つとして採用していた。感染するとNimdaはHTMLファイルを書き 換え、JavaScriptと攻撃プ ログラムを挿入する。そしてほかのユーザーが、そのWeb サーバ上のページを 閲覧するだけでNimdaに感染してしまうのだ。

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

おいおい、Nimdaがクロスサイトスクリプティング脆弱性を突いて広がったな どというのは初耳だ。それは全く事実でない。

これは二重に間違っている。まず第一に、Nimdaワームに感染したWebページと いうのは、ページコンテンツが改竄されたことによって発生した。改竄される 原因は、IISの脆弱性を突かれた場合と、サイト内部のネットワークでNimda感 染が広がってローカルにファイルが改竄されたものだった。これらはいずれも、 クロスサイトスクリプティング脆弱性と関係がない。第二に、そもそもNimda 騒動の原因は、JavaScriptを使用せずとも攻撃できるところに本質があった。 Nimdaは、.eml形式のファイルに攻撃コードを仕込んで、それをWebサイトに置 き、そこへのインラインリンクを設けておくことにより、そこを閲覧した者が 感染してしまうというものだった（半年前の脆弱性パッチを適用していなかっ たブラウザは）。たしかにJavaScriptも使われてはいたが、これは、感染して いく様子を見えにくくするために、画面外にポップアップウィンドウを出して そこで実行させるという攻撃者のちょっとした工夫にすぎず、それは問題の本 質ではない。

クロスサイトスクリプティング脆弱性の脅威を大袈裟に表現したいあまりに、 「この攻撃は性質上、広範囲に広がりやすい」などと言おうとして無理が生じ たのだろう。説明すべきは、cookieを盗まれると何が起きるかという点なのに、 その説明がない。

続く4ページ目はもっとひどい。

バッファオーバーフロー（Buffer Overflow）

（略）

Webアプリケーションにおけるバッファオーバーフローの脆弱性は、以下のよ うなページで発生しやすい。

<form action=http://test.fubar.jp/search.cgi method="get" name="search">
<input type="text" name="search" value="" size="45"></td>
<form>

このソースでは、検索フィールド「search」に入力できる文字列は45文字まで に制限されているので、Webブラウザ上から46文字以上のタイプをしても入力 されない。しかし、このHTMLをダウンロードし、以下のように書き換える。

<form action=http://test.fubar.jp/search.cgi method="get" name="search">
<input type="text" name="search" value="" size="1099511627776"></td>
<form>

これによって同じ検索フィールドに1GBの文字を入力することができ、バッファ オーバーフロー攻撃が可能になる。これはクライアント側のWebブラウザのチェッ ク機構に依存して、HTML上でデータ長の制限を行っているために発生し得る問 題点である。チェック機構をクライアント側に依存してはならない。

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

おいおい、size属性は画面表示上の入力欄の大きさを示すだけだよ。 maxlengthの間違いなのだろうが、「maxlength="1099511627776"」というのは あまりに滑稽だ。なぜなら、この属性は指定しなければデフォルト値は無限大 だからだ。

「ダウンロードして書き換える」などということも問題の本質では全くない。 バッファオーバーフロー攻撃を仕掛けるなら、直接HTTPポートにTCP接続して、 POSTでどんなデータでも送ればよい。

「1GB」というのも滑稽だ。バッファオーバーフローはなにも「巨大なデータ を送る」ことに本質があるわけではない。実際、Slammerワームはたった376 バイトのデータでバッファオーバーフロー攻撃を実現するものだった。

ようするに、なんとなくの感覚的イメージで脅威を伝えようとしているのだろ う。

バッファオーバーフロー攻撃からサイトを守るには以下の方法が有効である。

• Apacheにおける「LimitRequestBody」などを設定し、Webサーバであらかじめ 受け入れる送信データ量の制限を設定しておく

• 特定のサイズ以上のデータが送られてきたらクライアントにエラーを返すよう なコーディングを行う

という説明には危険性さえある。Slammerのように 376バイトで突けるバッファ オーバーフロー脆弱性があったらどうするのだ？ バッファサイズはなにも1024 バイト以上あるとは限らない。32バイトとかのバッファで境界を無視したプロ グラミングをしている例はいくらでもあるだろう。

SQLインジェクションもクライアントから送られる入力データを入念に検証していないWebアプリケーションにおいて発生する。攻撃者はメタキャラクタを入力データに挿入し、Webアプリケーションを経由して不正なクエリをデータベースに送信する。

べつに、「入念」とかそういう問題じゃない。インジェクション系の脆弱性は、 変数の出力時に、文脈を無視した文字列連結のコーディングをしているところ に原因があるのであって、セキュリティ以前に、正常系として、任意の入力に 対して正しく動作するプログラミングをしていれば、普通に解決するはず（だ が、できていない実態がある）というところに問題の本質がある。

SQLインジェクションも特殊文字を悪用することによって行われるので、ユーザー名やパスワードの文字種制限やサニタイジングが有効である。

パスワードに「'」を使わせないつもりなのか？ パスワードには強度確保のた めに記号を入れるのが常識なのに？

「サニタイジング」という便利な言葉は、問題の本質から目を背け、場当たり 的な対処方法という安易な説明を誘発してしまうので、有害だ。

これについては、「 サニタイズ言うなキャンペーン」実施中ということについて 説明しないといけないと思っているが、時間がないのでまだ書いていない。

この記事は冒頭で、次のように書かれいてた。

前回の内容に対して、周囲からいくつか質問をもらった。「こんなこと書いていいのか？」というものである。つまり、誰もが簡単に攻撃を行えることを示すことによって、かえって被害を増加させるのではないか、という懸念を持たれたわけだ。今回の記事では、より多くの攻撃手法を説明していくため、本論に移る前にこういった質問に回答しておきたい。

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

そりゃそうだろう。それは、記事が攻撃者視点で書かれているからだ。加えて、 正統で妥当な解決方法がないかのような書きっぷりだからだ。素人は問題の本 質が見えないままショックを受けてしまう。

この種の批判を浴びた攻撃者視点の人はこう弁明するに違いない。「攻撃方法 を知らずして対策ができますか？」と。それはその通りであるが（必要ではあ るが）、そのような態度に胡坐をかいていてはいけない（十分ではない）。よ り適切な説明方法があるのだということを理解してもらいたい。

もっとも、この記事は「Webアプリケーションファイアウォール」の宣伝であ るためこのような書き方になるのかもしれない。つまり、技術を理解する立場 にない対策担当者が相手であるために、怖いということさえ伝わればよいとい うのかもしれない。しかし、素人も直感的に何かおかしいということに気付く ものだ。いつまでも攻撃者視点でばかり煽っていると、業界全体の信用を損ね ることになりかねない。

ひと昔前なら攻撃者視点での解説にも意義があった。しかし、対策の必要性自 体は既に理解が広まった（が対策の方法が普及していない）現在では、もうそ ういうのはいらない。

私も時間がある限り書けるものは書いていくつもりだが、開発者視点で解説で きる執筆者がもっと増えてほしいと思う。セキュアな開発をちゃんとやってい る開発者はたくさんいるはずだ*2。

さてこの連載の次回は以下の内容になるのだそうだ。それはそれで重要な解説 なのでたいへん楽しみだ。本当にWebアプリケーションファイアウォールで対 策になるのかどうかが明らかになるかもしれない。

次回から、これらWebアプリケーションの脆弱性をセキュアプログラミングではなく、WAFのような外部機器にて防御していく手法について説明していく。

Web アプリケーションファイアウォールの必要性 第2回 多様化するWebアプリケーションへの攻撃, F5ネットワークスジャパン, @IT

■ ウイルスバスター2006はトレンドマイクロの定義で言うところのスパイウェアである

星澤さんがウイルスバスター2006のスパイウェア疑惑について、11月2日から書いていらしたが、18日になってもト レンドマイクロから回答が得られないとお困りのご様子だったので、21日 の午前、私も聞 いてみることにした。

一般的に、ユーザからの問い合わせが多くなる商品を販売している会社では、 この種の重要事項の問い合わせ（たとえば脆弱性の指摘など）が、ユーザの一 般的な質問に紛れ込んでしまい、判断のできる肝心な担当者へ情報が伝わらな いということが起きがちなものだ。そこで、大代表に電話をし、個人情報保護 担当者と電話で話したいと伝えた。 （トレン ドマイクロの個人情報保護方針にはメールアドレスしか書いてない。） すると「システムの都合でここから個人情報保護担当者には電話をつなげない」 と言われるわけだが、その対応は想定の範囲内なので、「折り返しお電話いた だければと思います」と主張したところ、しばらく後に、個人情報保護担当の 方から自宅にお電話いただくことができた。

いろいろ質問したところ、正確に回答するためにメールで回答したいとのこと だった。そして、今日、メールでの回答が到着した。

以下は、私がした質問の内容と、それに対応する回答（先方のご希望に沿って 正確を期すため、回答の部分は原文のまま変えずに引用する）である。

質問: 送信しているデータはURLの全体なのか一部なのか？

回答: トレンドマイクロのサーバ（以下弊社サーバ）にはパラメータも含めた全ての 情報を送信します。ユーザが意図的にメールアドレスなどをＵＲＬに入れた場 合やセキュリティ上問題のあるWebベースのアプリケーション（URLにパスワー ドや重要な情報がそのままの形で出てしまうようなサイト）にアクセスした場 合、FORMの隠しフィールドやリンクにこれらの情報が埋め込まれたページが表 示され、ユーザーが明示的に入力しなくても、ＵＲＬリンクのクリックやＦＯ ＲＭの入力を行ったときに、それらの付随する（明示的に入力されていない） データも結果として送信されることはあります。ただし、弊社サーバに保存さ れるのはＵＲＬだけで、パラメータは保存されません。

質問: 送信しているデータは、復号可能な暗号化を施したものか、それとも 一方向性関数でハッシュしたものか？

回答: （秘密鍵で複合化（原文ママ）するタイプの）暗号化処理をしています。

質問: 暗号アルゴリズムは何か？ 鍵長は何ビットか？ （https サイトの ように、ユーザの情報を送信する暗号化通信では、鍵長が何ビットであるかが 表示されるようになっているのだから、自動的にユーザの行動情報を送信する ウイルスバスターも、鍵長をユーザが知ることができるようになっているべき ではないか？）

回答: これ以上の情報は弊社として社外秘扱いの情報としておりますため回答 できません。あしからずご了承ください。

質問: ウイルスバスターはトレンドマイクロの定義で言うところの「スパイウ エア」に該当するのではないか？

回答: [URLフィルタ機能]ならびに[フィッシング詐欺対策ツールバー]の実装 に関して、お客様に対して十分な説明が無かったことに関しましては、弊社と いたしましても謙虚に受け止め、今後、弊社ホームページならびに製品ヘルプ 等へ本仕様に関する情報を明記を行い、お客様に対して情報開示を行っていき たいと考えております。

（これは回答になっていないので、「はい」または「いいえ」で回答するよう、 再度問い合わせ中。）

さて、トレンドマイクロの用語集に掲載されている、スパイウェアの項目を見てみる。

スパイウェア

「スパイウェア」は不正プログラムには分類されないグレーゾーンのプログラムです。ユーザのコンピュータの動きや個人情報を監視し、この種の情報をユーザの許可またはユーザに知らせることなしに送信するアプリケーションであり、動きとしては情報漏洩型ハッキングツー ルに似ていますが、一般的なソフトウェア会社によって作成されてい る、セキュリティポリシーが開示されている、セキュリティに致命 的な情報を流さない、などの条件により特に不正なものとは断定でき ないものです。逆に言うと「スパイウェア」と呼ばれているものは 特に致命的な情報を漏らすことはない、とも言えます。致命的な情報を漏らす ものはハッキングツールに分類され、当然検出の対象となります。

ウイルス対策基礎知識 - 用語集, トレンドマイクロ株式会社

まさに、ウイルスバスター2006は「スパイウェア」である。

スパイウェアという言葉の定義が広すぎるあまりに、事業者間で紛争が起きて いることは、英語圏からのニュースで伝えられてきたところだ。他社製品を スパイ呼ばわりするわけだから、紛争が起きても不思議でない。

だが、ウイルス対策ソフトベンダーは、そうした紛争のリスクを承知の上で、 意識的にあえて「スパイウェア」を広い意味で定義してきたのだと思われる。

なぜなら、上の定義で「ハッキングツールに分類」されるようなマルウェアの 場合、ユーザのコンピュータに本当に仕込まれていることは、そう多くはない だろう。そうすると、（狭い意味の）「スパイウェア」対策ソフトをせっかく 開発して販売しても、何も検出されないことがほとんどであっては、ユーザが そのソフトのありがた味を感じることができない。つまり、できるだけ広い範 囲で検出するようにしないとビジネスにならない。

実際どうだろうか。初めてスパイウェア対策ソフトを動かしてみたときに、何十個ものスパイウェアが検出されたと*1 思ったら、単にcookieの検出だったなんて ことを経験した人は多いだろう。cookieのようなものまで「スパイウェア」 ということにしてしまうことは、対策ソフトベンダーにとってはビジネス上必 要なことだったのだろう。

そういう経緯のあるウイルス対策ソフトが、自分自身が「スパイウェア」の挙 動をしているのである。

ソニーBMGの音楽CDがrootkitまがいのものをインストールするという騒動でも 明らかになったように、「何をやってはいけないのか」という常識が、セキュ リティコミュニティにはあっても、一般企業の全部にまでは浸透してないとい うことがある。そうした「常識」は必ずしも法律で定めらるわけではないのだ から、批判を繰り返すことによって、一般企業へも理解を広めていくしかない だろう。

同様に、「ユーザに知らせることなしにユーザのコンピュータの動きを送信す る」というこの種の挙動は、これまでにも何度かの騒動を経て、やってはいけ ないことだという常識が、少なくともセキュリティコミュニティにはできあがっ ていた。

企業が他社製品をスパイ呼ばわりしていいのか？ とも思えるところ、これは セキュリティ業界では常識なので、スパイ呼ばわりしてよいというわけである。トレンドマイクロの「スパイウェア」の定義のように、 「ユーザに知らせることなしにユーザのコンピュータの動きを送信する」アプ リケーションのことをスパイウェア呼ばわりするのは、許されているわけだ。

したがって、ウイルスバスター2006をスパイウェア呼ばわりすることを、トレ ンドマイクロは止めることができない。

ちなみに、現時点でも、トレンドマイクロホームページの「ニュースとお知らせ」に、 この件のアナウンスが出ていない。

（つづく）

■ ウイルスバスター2006は存在しないサーバ名もトレンドマイクロに送信する

25日の日記に書いたように、 ウイルスバスター2006のフィッシング対策機能（Internet Explorerのツール バーとして搭載された機能）は、ユーザがアクセスしようとした任意のサイト について、アクセスする前の段階で、トレンドマイクロのサーバにそのURLの 全部を送信して、「評価」をもらった後、IEのアクセスを続けさせるかを判断 するようになっているそうだ。

しかし、DNSで名前解決できないホスト名を指定したURLにアクセスしようとし たときにも、そのURL文字列がトレンドマイクロに送信されてしまう。 つまり、例外なくどんなURLでも送信されるようだ。

たとえば「http:/a/」という文字列をIEのアドレスバーに入力してエンターキー を押すと、ウイルスバスターが自動的にTCPポート80番でトレンドマイクロの サーバに接続し、以下のリクエストを送信して、次のレスポンスを返してくる （一部略）。

GET /P/48/B16B1603A25DA22E70AF6AD32A72DBC690B90CC3FF4C273E HTTP/1.1
User-Agent: TMI_SCM
Host: tis14-JP.url.trendmicro.com:80

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 260

256/94DB4EB7541411D522CFCE6EAE761750（略）

他のURLを試してみると、同じURLについて何度か繰り返しても同一となったの だが、次のようになった（見やすいように16文字ごとに空白を空けておいた）。

http:/a/
/P/48/B16B1603A25DA22E 70AF6AD32A72DBC6 90B90CC3FF4C273E
http://a/a
/P/48/B16B1603A25DA22E 70AF6AD32A72DBC6 4AD754147734006B
http://a/aa
/P/48/B16B1603A25DA22E 70AF6AD32A72DBC6 8C86279EEB6964B9
http://a/aaa
/P/48/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A
http://a/aaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A AAB1A39A842F683C
http://a/aaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A BDD6EC88255B73C9
http://a/aaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 6630550CE60C84AE
http://a/aaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A CB62188C3FF1DBEB
http://a/aaaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A FE30CE3DE34C9530
http://a/aaaaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 1AAFA52B91C1750F
http://a/aaaaaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 5A671E1CDCDEF86D
http://a/aaaaaaaaaaa
/P/64/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3
http://a/aaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 AAB1A39A842F683C
http://a/aaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 BDD6EC88255B73C9
http://a/aaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 6630550CE60C84AE
http://a/aaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 CB62188C3FF1DBEB
http://a/aaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 FE30CE3DE34C9530
http://a/aaaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 1AAFA52B91C1750F
http://a/aaaaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 5A671E1CDCDEF86D
http://a/aaaaaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 2A079EAEB1330AE3
http://a/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
/P/160/B16B1603A25DA22E 70AF6AD32A72DBC6 D1AB49418B00911A 2A079EAEB1330AE3 2A079EAEB1330AE3 
2A079EAEB1330AE3 2A079EAEB1330AE3 2A079EAEB1330AE3 2A079EAEB1330AE3 2A079EAEB1330AE3

http://b/aaaaaaaaaaaaaaaaaaa
/P/80/B16B1603A25DA22E FF7483DA766AA203 D1AB49418B00911A 2A079EAEB1330AE3 2A079EAEB1330AE3

これがまともな暗号処理なのかどうか心配なところだが、 トレンドマイクロの個人情報保護担当者に暗号アルゴリズムは何かと尋ねても、

質問: 暗号アルゴリズムは何か？ 鍵長は何ビットか？ （略）

回答: これ以上の情報は弊社として社外秘扱いの情報としておりますため回答できません。あしからずご了承ください。

25日の日記

とのことだったので、なんとも言えない。

自衛のためにユーザは、自分のコンピュータのこのような挙動を調べて、信用で きるかどうかを自分で判断するしかない。なぜ自衛する必要があるかというと、 ユーザは https:// のサイトにアクセスする場合があるからだ。

■ ウイルスバスター2006はHTTPSサイトのURLもトレンドマイクロに送信する

https:// のページにアクセスした場合にはどうなるかというと、なんと、 同様に以下のリクエストが送信される。しかも、SSLなしの HTTP で。

GET /P/96/B16B1603A25DA22E4DF7B231A59FA7D1D686FB64DB15EAE3607FA285A32FCD1DFD70A1D378A470F328AD165D7F7E4C9E HTTP/1.1
User-Agent: TMI_SCM
Host: tis14-JP.url.trendmicro.com:80

HTTP/1.1 200 OK
Content-Length: 292

256/94DB4EB7541411D522CFCE6EAE761750（略）

これはいかがなものか。

ログイン機能を持つサイトでURLに

http://exmaple.com/foo.cgi?sessionid=dc9f86389fa5ecc137c256

しかし、送信されるURLデータは独自に暗号化されているので、これは脆弱性 にはあたらないのだろう。これを脆弱性だとしてIPAに届け出ても、「URL自体 を暗号化しているので、パケット盗聴されてもセッションIDを盗まれることは ありません」ということになることは目に見えている。

しかも、25日の日記に書いたように、 トレンドマイクロの個人情報保護担当者は、次のように主張する。

回答: トレンドマイクロのサーバ（以下弊社サーバ）にはパラメータも含めた全ての情報を送信します。ユーザが意図的にメールアドレスなどをＵＲＬに入れた場合やセキュリティ上問題のあるWebベースのアプリケーション（URLにパスワードや重要な情報がそのままの形で出てしまうようなサイト）にアクセスした場合、FORMの隠しフィールドやリンクにこれらの情報が埋め込まれたページが表示され、ユーザーが明示的に入力しなくても、ＵＲＬリンクのクリックやＦＯＲＭの入力を行ったときに、それらの付随する（明示的に入力されていない）データも結果として送信されることはあります。ただし、弊社サーバに保存される のはＵＲＬだけで、パラメータは保存されません。

25日の日記

つまり、まずい情報が送出されるのは「セキュリティ上問題のあるWebアプリ ケーション」の場合だという。これでは、届出をしてもそのように言われてし まうだろう。

ウイルスバスター2006を使っていて、cookieを切ってWebアプリケーションに ログインするユーザは、トレンドマイクロの暗号方式が安全だと信用できな いならば、この機能を無効にして自衛するしかない。

ユーザの大切な情報を送信することも起き得るのだから、正しい暗号を正しく 使って、どんな暗号なのかをユーザに開示するべきだろう。

■ Googleツールバーは「?」以降を送信しないしHTTPSのときも送信しない

Googleツールバーで「PageRank」機能を有効に設定しようとすると、

という注意をうながすアラートボックスが現れることを知っている人は多いだ ろう。

PageRank機能は、ユーザが表示したページの「ランク」をツールバーに表示す るために、どのページを開いたのかの情報を toolbarqueries.google.co.jp へHTTPで送信している。そのため、プライバシーの注意が勧告されるわけだ。

この機能を有効にしている場合、どのようなデータがGoogleへ送信されている かというと、以下のように、URL中の「?」以降の文字列を削除した情報が送信 されるようになっている。

たとえば、

http://slashdot.jp/pollBooth.pl?qid=251&aid=-1

GET /search?client=navclient-auto&iqrn=sB2B&ie=UTF-8&oe=UTF-8&features=Rank:&q=info:http%3A%2F%2Fslashdot%2Ejp%2FpollBooth%2Epl%3F&ch=773439207827 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; GoogleToolbar 3.0.125.1-big; Windows XP 5.1)
Host: toolbarqueries.google.co.jp

となる。「http://slashdot.jp/pollBooth.pl」までしか送信されていない。 （「ch=」の部分の意味は不明。）

また、https:// のページにアクセスした場合はどうなるかというと、 その場合は何も送信されず、ページランクは無しとなる。

■ SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも

24日のIT Proの記者の眼に「なぜSSL利用をケチるのか」という記事が出ていた。筆者の阿蘇氏には勤務先でWebアプリケーションセキュリティについて取材を受けたことがある。この記事の主張はこうだ。

Webサイトはログイン画面からSSLを使い，利用者はログイン時に鍵マークを確認するのが常識。

阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日

正しい。より正確には「ログイン時」というのは、パスワードを入力する前にということだろう。ただ、その根拠としてこの記事は、フィッシング対策としてサイトが本物かを確かめるためという点だけを挙げているが、その根拠はやや弱い。

SSLをパスワード送信先の画面からではなく、入力画面から使わなくてはならない理由のもうひとつの重大な理由は、パケット改竄可能な状況での盗聴が可能になってしまうからだ。このことについては、だいぶ前から講演で述べてきた。たとえば、2003年9月の「安全なWebサイト設計の注意点」のスライド4から始まるそのビデオで説明している。

なかなかわかってもらいにくい話なので、そのような画面構成になっていたある公共料金の明細閲覧サイトに対して、今年8月にメールで問い合わせをしてみた。以下はそのやりとりである。

質問一回目: ○○○○○のログイン画面が　https:// になっていません。暗号化に不備があるのではないでしょうか？

回答: ○○○○○ログイン後のホームページは、セキュリティを強化したページになっております。そのため、○○○○○○のIDとパスワードも、保護されて送信されております。ご安心下さいませ。

質問二回目: ログイン後のページが https:// になっていることは、パスワード送信前の段階で、どのようにして確認できるのでしょうか？

回答: ○○○○○○のホームページ http://○○○.○○.com/○○○○○○/ の一番下にございます、『プライバシーを保護します』という項目にて、『ホームページに掲載する情報は暗号化して送受信されます。(SSL技術使用)』というご説明を掲載させていただいております。わかりづらくて申し訳ございませんでした。

質問三回目: いくらそのように文章で書かれていても、今私が見ているログイン画面が本当に、送信先が　https://　になっているかどうかは、どうやって確認できるのでしょうか？たとえば、通信路上でパケット改竄されていれば、今見ている画面のリンク先（パスワードの通信先）は、https:// ではなく　http://　に改竄されているかもしれないわけですが。

回答: Internet Explorerをご利用の場合は、ページ上部のメニューの『ツール』⇒『インターネットオプション』をお選びいただき、『セキュリティ』の項目で『保護付き/保護なしのサイト間を移動する場合に警告する』にチェックを入れていただければ、保護されているサイトに接続される際にメッセージが表示されます。

また、改竄につきましてご心配を頂いておりますが、弊社では、リンク先等を改竄されないようホームページを構成いたしております。ご安心してご利用いただければと存じます。

質問四回目: それは、パスワードの送信を開始させた後に表示されるメッセージですね。しかもそれは、正常な場合（https:// でのパスワード送信となっていた場合）に出るメッセージであって、異常な場合（引き続き http:// のままでアクセスする（パスワードを送信する）場合）には、出ないメッセージではありませんか？つまり、あなたの言うように設定していても、パスワードの送信を開始した後、そのメッセージが出なくて異常に気付いても、後の祭なのではないですか？

私は前回、「通信路上でパケット改竄されていれば」と書きました。通信路上でのパケット改竄を防ぐには SSL を使用して https:// にするしかありません。しかし、○○○○○○のパスワード入力画面は http:// であり、通信路上での改竄防止措置がとられていません。「改竄されないよう構成しています」というのは、明らかな嘘偽りです。

回答: ○○○○○○では、パケット改竄などの不正アクセスの防止等に日々努めております。誠に申し訳ございませんが、何卒ご理解頂きますようお願い申し上げます。

質問五回目: 通信路上でのパケット改竄をどうやって御社が防ぐのですか？御社のコンピュータから私の家のコンピュータまでの通信路上で、パケットが改竄されることを、どうやって御社が防いでいるというのかを教えてください。

回答: 高木様のおっしゃる通り、ログイン画面では、httpsによる暗号化が望ましいと思います。 ○○○○○○では、SSLを利用したログイン画面
https://○○○.○○.com/○○○○○○/login.html
も設けておりますが、現状の○○○○○○トップページ
http://○○○.○○.com/○○○○○○/
からは、暗号化されたログインページにアクセスすることができなくなっております*1。

そのため、今後はトップページより、暗号化されたログインページへのアクセスをご選択いただけるような形に変更するよう対応していきたいと思います。

このような質問をするなどして、ご自身で考えて頂かない限り、運用中のサイトの管理責任者にこの問題を理解していただくことは難しい。

その後このサイトの画面構成は改善され、トップページのパスワード入力欄は撤去され、「ログイン」ボタンを押すと https:// のページにジャンプするようになり、そこにパスワード入力欄が現れるという構成になった。

■ クレジットカード業界は最もWebセキュリティを理解していない業界

阿蘇氏の「 なぜSSL利用をケチるのか」には、次の記述がある。

今や重要な情報を扱うWebサイトは，SSLを使うのが常識。しかし，ログイン後はSSLを使うのに，ログイン画面の表示にはSSLを使用していない Webサイトが意外に多い。銀行のサイトではさすがに減っているが，Webメールやクレジットカード会社などにはまだある。そのようなサイトに限って，「ログイン時にSSLを使うのでIDやパスワードは暗号化されます」とわざわざ注意書きがあったりする。

阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日

銀行のインターネットバンキングでは、以前から、パスワード入力画面は、サイトのトップページにはなく、ボタンを押して進んで現れる専用画面に設置されていて、入力画面からして https:// になっているというところがほとんどだった。

それに対しクレジットカード会社は、どういうわけか、そのような構成ではなく、カード会社トップページにパスワード入力欄を設けており、画面は SSLを使わずに http:// のままとなっているところがやたら目につく。

クレジットカード産業協会の会員企業一覧から、いくつかのメジャーなカード会社のサイトについて調べてみた。

• イオンクレジットサービス ○
• オリエントコーポレーション ×
• オーエムシーカード ×
• オリックス・クレジット ×
• クレディセゾン ×
• さくらカード ○
• ジェーシービー ○
• ジャックス ×
• ジャルカード ○
• セントラルファイナンス ○
• ソニーファイナンス ×
• ディーシーカード ×
• 東急カード ×
• 東日本旅客鉄道 ×
• ファミマクレジット △ （ユーザIDのみが http:// で入力）
• 三井住友カード ×
• UFJニコス （UFJカード） ×
• UFJニコス （ニコスカード） ×
• UCS ×
• ユーシーカード ○
• ライフ ×

このように、21のクレジットカードのうち、ID、パスワード入力画面がSSLになっていないところは 15サイト、つまり7割を超える。

どうしてこんなことになっているのだろうか。銀行とは対照的である。作っている業者が閉じた世界の業界に限定されているのか、それとも、同業他社のサイトを真似て作るために、どこかが始めたものが伝染してしまっているのか。

銀行業界では、昨年秋のフィッシング詐欺報道の機会に、一斉にアドレスバーを隠さない画面構成に改善するということがあった。業界内での情報伝達がある程度できているのだろう。

クレジットカード業界は、フィッシングやスパイウェアの報道に対して、高額なセキュリティ対策製品を購入するという方向に出た。ろくに対策にならない、それどころか誤ってユーザを安心させるような、つまらない「対策ソフト」がこぞって導入されたことは、業界通にはよく知られているところだ。

どうやら、クレジットカード業界は、Webセキュリティに関する正しい情報が伝達されない状況にあるらしい。これはクレジット産業協会の認識不足に原因があるのではなかろうか。