最新 追記

高木浩光@自宅の日記

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

2005年07月01日

国会図書館のWebアーカイブ計画で技術的に考える余地

5月1日の風間さんの日記で私のことについて言及されていた。コメントを書こうと思いつつ、 2か月も経ってしまった。

某研究会で発表した時に「Webから勝手に情報を収集して,こういう高度な解析をおこなうのはけしからん!」とクレームをつけられて,さらに(略)

とあるが、収集したものを解析する話と、収集したものを再公開することとは 別だろう。収集したものを解析する行為に対して「けしからん」と偉い人が言っ たそうだが、驕り逞しいどこかの傲慢教授とかだろうか。

続く段落に、

高木浩光氏に相談した時には,「確かに,著作権的にはグレーな面もあると思う」というコメントを頂いた.

とあるのだが、これは収集したものを再公開することについてのものだ。

さて、これは、国会図書館によるWebアーカイブ計画についての話である。 Webロボットによって収集したものを自動的に公開するという計画だ。 この計画について、それから2か月が経過した6月30日には次のように報道され た。

  • 国会図書館、情報保存はお堅いサイト限定 反対多く転換, 朝日新聞, 2005年6月30日

    「全部集めて、全部公開する」という当初の方針に、法務省や音楽、出版、ソフトウエア関連団体から反対が相次いだため。特に個人のサイトには著作権やプライバシーを侵害しているものだけでなく、児童ポルノや犯罪教唆の情報まで含まれるものがある。

これは残念なことになったと考える人が多いだろう。私もそう思う。他にもっ とやりかたがあったはずだ。5月の風間さんの日記のときからいろいろ考えていた。 きっと国会図書館でもいろいろ検討されているんだろうと思っていたが、 国会図書館の「 インターネット情報の収集・利用に関する制度化の考え方(改訂版)」や「『インターネット 情報の収集・利用に関する制度化の考え方』に関する意見募集の結果について」 を読むと、私が期待していたようなことが検討された様子は見えない。少なく とも外から見える範囲では。

まず、Webの普及によって、従来なら出版物として発信されていたであろう情 報のいくらかがWebだけで発信されるようになり、国会図書館に記録される情 報が減る傾向にあるであろうことは由々しきことであり、Webの国によるアー カイブの必要性は理解できる。

しかし、従来、出版物のすべてを法に基づいて収集してきたことを、そのまま 同様にWebに適用しようとするのは誤りである。その理由はいくつかある。

第一に、従来の出版物は、出版に費用がかかることもあって、著者らが「出版」 という行為をひとつの区切りとして意識するものであったのに対し、Webの場 合には、完成していない文章でも随時掲載することが可能であり、「出版」と いう概念に対応する区切りというものが必ずしも存在しないという点で、性質 が同じではない。実際、(昔は)Webサーバのコンピュータで公開中のファイ ルを直接編集しながら HTMLを記述したこともあった。(もっとも、最近では、 いつ誰にコピーされて不正に再公開されるかわからないご時勢なので、そうい うことはほとんど行われないようになっているだろうが。)

第二に、Webという媒体は、出版のためだけでなく、通信のための一時蓄積の 場として使われることもある。たとえばチャットルームや、一部のタイプの掲 示板などである。一定時間後に消えていくことを前提に作成され、使用されて いるという、通信の場とみなすことができよう。コピーされて無断で再公開さ れることが著作権法上問題があるという前提から成り立って普及している、 Webの利用方法である。もし、いつ国会図書館にその瞬間のチャット内容を持っ ていかれ、再公開されるかわからないとなれば、こうした利用方法は消滅する ことになる。Googleが「キャッシュ」などと自称している無断コピー再公開の 仕組みは、違法である可能性もあって、現在は単に過渡期なのだと思う。

第三に、個人情報などを誤って公開してしまっていたページが、コピーされて 再公開されることになれば、削除を依頼しなくてはならないサイトがまたひと つ増えることになる。2003年8月には「Googleキャッシュで鳥取県個人情報流出の2次被害」という事故が起きていた。

しかし、この第二と第三の問題については、次のように解決できるのではない かと考えていた。

収集ロボットが、同じURLのページに対して複数回アクセスするようにする。 たとえば、1週間おきくらいの間隔で4回アクセスするようにする。この4回の アクセスで得られたそれぞれのページ内容に変化がない場合、それは「出版」 であるとみなすことにし、再公開する。変化のあったものは、通信用の一時蓄 積か、意図しない公開であったと推察して、蓄積しないことにする。1か月経 たなければ掲載されないことになり最新性が損なわれることになるし、いくら かの割合のページが収録されないことになるが、国会図書館の目的からすれば、 これで十分だと思われる。(1週間×4という期間の調整は必要であろうが。)

ところで、POSTメソッドによるアクセスについて国会図書館はどう処理するつ もりなのだろうか。おそらく、POSTによるアクセスはしないのだろうと予想す るが、国会図書館が掲げる「趣旨・目的」からすれば、POSTを除外する理由は ないことになる。実際、アクセス制限の意図というわけでもないのに、POSTで しか進まないようになっている(GETアクセスもできるが、そこへのリンクが POSTによるものしか存在しない)ページもある。

Web検索サイトのほとんど(おそらく全て)は、POSTアクセスによるページ収 集は行っていないようだ。明確な規定はないものの、POSTによるページは、 検索される対象にしないという合意が確立しているように思われる。同様に、 cookieを一旦セットしないとアクセスできないようにされているページ(アク セス制限の目的ではなく、直リンクを禁止するなどの目的によるもの)も検索 の対象としないことが合意されているように思う。

この際、国会図書館も、こうした技術的線引きを明確に打ち出してはどうだろ うか。

パスワード管理された制限アクセス情報・有償情報などは、自動収集(収集ロ ボットによる収集)の対象にはなりません。

インターネット情報の収集・利用に関する制度化の考え方(改訂版), 国立国会図書館, 2005年6月17日

という説明はあるが、それとは別に技術的線引きが存在し得る。先に挙げた 第一の問題点も、技術的線引きによって解決するかもしれない。

国会図書館の「考え方」には、収集拒否の申し出が可能と書かれているが、そ の点については、Googleなどが採用しているMETAタグなどによる機械的な拒否 の表明の機能も取り入れるべきであろう。収集され再公開されてから拒否を申 し出なくてはならないというのは、理不尽である。

しかし、METAタグ等による拒否、つまりオプトアウト方式で表明させること自 体、国がやることとしてはいかがなものか。

そもそも、Googleなどが、著作権侵害で告訴されるリスクを承知のうえで、オ プトアウト方式で強制的に世界のWebコンテンツのコピーを「キャッシュ」と 称して再公開しているのは、オプトイン方式ではビジネスが成り立たないため に他ならない。駆け出しのころのGoogleが、「検索して欲しければ、これこれ のタグを記入してください」と主張したところで、誰もそれに従ってはくれな い。著名になり、信頼も得られた今でこそ、「オプトイン表示のないページは ○月○日以降Google村八分とします」と方針転換しても、世界中の人々がそれ に従ってくれる可能性があるものの、一民間企業によるサービスの立ち上げで は、鶏と卵の関係にある。

それに対して国会図書館はどうだろうか。最初から信頼はある。それどころか、 国立国会図書館法によって国民に強制させることさえできる。

つまり、従来の国立国会図書館法によって納本を義務付けてきたのに相当する 「出版物」をWebコンテンツとして公開する者は、施行令などで指定された METAタグなどを記述しなくてはならないと、改正国立国会図書館法で規定すれ ばよい。それを無視する行為は違法ということになり、従来と違わない。

どんな基準で「出版物」に該当することになるのかが曖昧となるかもしれない が、先に述べたような、1か月間固定して公表され続けたものといった基準も 考えられるし、始まってから社会通念が形成されていくかもしれない。

今回の国会図書館の改定方針で、go.jp や ac.jp などのWebページに限定して、 オプトアウト方式で強制的に無断コピー再公開するつもりらしい。そういうや り方で始めてしまうと、一般のページに将来拡大させるのを難しくしてしまう かもしれない。「あんなふうにやられたくない」と。

どのみち、go.jp や ac.jp などだけに限定したのでは、本来の目的を達成で きないのであり、まずはできることから始めるので十分だというのであれば、 いっそ、オプトイン方式で初めてはどうだろうか。すべての .jp サイトを 対象として。そして、将来、「出版物」コンテンツにオプトインの表示を法律 で義務付ければよい。

本日のリンク元 TrackBacks(4)

2005年07月02日

謎のYahoo! JAPAN偽サイト(のようなもの)は著作権法違反と言えるか

フィッシング詐欺犯*1著作権法違反の容疑で逮捕された事件が記憶に新しかった6月20日のこと、「フィッシング詐欺サイト情報」の サイトに興味深い事例が掲載されていた。

・yahoo.co.jpの偽サイト? ttp://www.livedor.jp/

アドレス202.229.198.216は本物のwww.yahoo.co.jpと同じなので表示されてい るコンテンツ自体も本物です。直接本物のサイトにつながるのでログインの情 報などは詐取できませんがいたずらにしては時節柄ちょっと問題ありかな。 (略)

本件は通報されたものです。yahoo.co.jpへの通報もしていただいたそうです。 ありがとうございました。

通報なさった方から来たメール(23:22)によると利用規約に照らし厳格に対処するという返事が来たそうです。 (略)

フィッシング詐欺サイト情報, June 20, 2005

私も見に行ったところ、図1のような画面となっていた。

図1: http://www.livedor.jp/ の6月20日の時点での様子

これはようするに、www.livedor.jp をDNSに問い合わせると、IPアドレス 「202.229.198.216」が応答されるようになっていて、202.229.198.216は 本物のYahoo! JAPANのwww.yahoo.co.jpのIPアドレスのひとつ*2であった。 そのため、HTTPでここにアクセスすると本物のYahoo! JAPANのコンテンツが 表示されるというものだった。

これは、閲覧者のブラウザは最初から直接本物のサイトとHTTP通信することに なるので、閲覧者が入力する情報を livedor.jp開設者が盗むといったことは できない。フィッシング行為等には該当しないというわけだ。

では、著作権法的にはどうだろうか。まず、livedor.jpの開設者は、Yahoo! JAPANのコンテンツを複製してはいない。自動公衆送信しているわけでもない。 だが、閲覧者の視点で見れば、livedor.jpの開設者がYahoo! JAPANの コンテンツをパクっている場合と同じに見える。

これはいわば「FRAMEリンク」の問題と似ている。「FRAMEリンク」とは、自分 のページに、<FRAMESET>タグや<IFRAME>タグを用いて他人のコン テンツを埋め込む行為を指す。「Webのリンクは、リンク先の同意確認なしに 自由にやってよい」という常識の下であっても「FRAMEリンク」は除外される という禁じ手である。

しかし、「FRAMEリンク」の場合は、画面中の一部のフレームは自分のコンテ ンツとして、もう一方のフレームをあたかも自分の著作物であるかのように 見せかけるというところに主な問題があるわけだが、画面全域を他人のコンテ ンツに差し替えてしまう「FRAMEリンク」というのは、その行為をする価値が ないと思われるので、あまり問題とされてこなかったように思われる。

今回のwww.livedor.jp も、画面全域の「FRAMEリンク」と同様、それをする 価値や意義がほとんどないのであり、目的が不明だ。

ただ、昨年4月26日の日記「太古の昔、 アドレスバーが入力欄でなかったのを知ってるかい?」にも書いたように、 World Wide Webというものが、アドレスバーとコンテンツが一体となってひと つのシステムなのであって、両者は不可分なのだという考えに立てば、 アドレスバーのURL表示は著作者名の表示にあたるわけで、その意味ではやは り、自分のドメイン名をアドレスバーに表示させながら他人の著作物を見せる というのは、著作者の氏名表示権を侵害しているとか、同一性保持権を侵害し ている……などと言えるのかもしれない。

ちなみに、これが携帯電話のWebブラウザの場合となると、アドレスバーがな いため、URLによる著作者の表示がそもそもない。 どんなドメイン名で Yahoo! JAPANのコンテンツを表示させてもかまわない という、奇妙な事態になってしまう*3

で、フィッシング詐欺サイト情報のページに追記があったように、Yahoo! JAPANが何かアクショ ンを起こしたらしく、この状態は解消された(www.livedor.jp についてDNSが Yahoo! JAPANの所有するIPアドレスを返さないようになった)ようなのだが、 いったいどういう根拠でYahoo! JAPANはそれを要請したのだろうかと興味深い。

もうひとつ謎なのは、livedor.jp は何の意味があってこのようなDNS設定をし ていたのかだ。

その後、Google検索して調べた*4ところ、同様のサイトがたくさんあることが わかった。列挙すると以下のとおりである。

これらはいずれも、u-hip.jp というドメインのサブドメインにあるページ となっている。u-hip.jpのトップページ さえもそうなっている。

u-hip.jpとは何なのだろうかと調べてみたところ、かつて無料の レンタルサーバ事業が行われていたところらしい。

◆2003/03/13 サーバー閉鎖のお知らせ◆

先に、今後の予定としてお知らせいたしましたことですが、長い間ご利用いた だきましたワイネットジャパンの無料提供サーバーである《創造の館U-HIP》 は平成15年4月15日を持ちまして閉鎖させていただくことに致しました。

U-HIP『創造の館』では、様々なジャンルの独創的なクリエイターサイトを紹 介し、クリエイターの創作活動の向上やビジネスチャンスを広げるお手伝いを 行なっています。

2003年2月当時の http://www.u-hip.jp/ の内容

廃止になったサービスにおいて、なぜか、自ドメイン名に対するすべてのDNS 問い合わせに対して、Yahoo! JAPAN所有のアドレスを返すようになっているよ うだ。これは、誰の意思によってそうなっているのだろうか?

設定ミスとか事故とかの可能性もあるが、何も返さないという設定の代わりに、 どこか適当なサイトを返すつもりで、インターネットの代表的サイトとして Yahoo! が採用されているということなのかもしれない。かつて、「18歳以上 ですか?」の問いに「いいえ」が選択されると、Yahoo! に飛ばすというのが 業界標準となっていたように。

性善説というより契約の問題

ITmediaの高橋睦美記者のblogに、先日の消防庁とVISAジャパンのドメイン乗っ取り危機 の件について感想が載っていた。

で、つくづくとDNSの仕組みを再考するに、これって本当に性善説の世界の 仕組みですよね。

情報漏えい対策の必要性が叫ばれる中、「性善説だけではやっていけない」な んて論調もありますが(これについても議論の余地はあるが)、そもそもイン ターネットの仕組みってほんとに性善説ベース。これだけでかい仕組みが根本 的なところで他人への信頼に基づいてるってすごいー! と、いまさら変なと ころで感動してます。

ドメイン名乗っ取りの危険性に関して補足(汗, mtakahasのバッファあふれ, 2005年6月29日

他人への信頼に基づいているというのは、インターネットに限らず、リアル 社会においても同じだ。生活のありとあらゆる場面が、他人への信頼に依存し ているわけで、社会的な信頼の仕組みは既存のものがある。

インターネットのセキュリティに関わる仕組みにおいて、技術というのは、そ うした他人への依存の影響をどれだけ減らせるかを提供しているにすぎない。 最後に残る部分は、契約によって担保するか、法律による担保を期待するしか ない。

それに対して、「性善説の世界」というのは、単に、そうした契約や法的検 討をすっとばしているか、もしくは、安全でない技術を選択しているという話 だろう。

DNS設定不備の件を契約の問題という視点で理解するには、総務省の注意喚起 が簡潔でわかりやすい*5

廃業する際に確実に通知するなり代替策を講ずるよう、契約時に約束してもらっ ておく必要があるのではないか。実態はどうなっているのだろうか。

*1 「詐欺」と表現するのは法的には間違いなのだろう。 報道ではすべて「フィッシング」と表現されていた。しかし、「フィッシング」 だけではどうにもすわりが悪い。

*2 負荷分散のために www.yahoo.co.jp には多数のIPアドレスが割り当てられている。

*3 やっぱり、携帯電話のそれは インターネットではない。 インターネットのことを知りもしないsophisticatedでない電話屋連中が 乱暴にでっち上げた糞規格は早く捨てよう。

*4 Yahoo! JAPANのトップページに書かれ ている文字列で検索した。

*5 「運用代行業者」という表現だと、指すものが ずれる気はするが。

本日のリンク元 TrackBacks(3)

2005年07月03日

クロスサイトリクエストフォージェリ(CSRF)対策がいまいち進まなかったのはなぜか

4月27日の日記「クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法」で、

「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。

と書いた。あれから2か月以上が経ってしまったが、今書いておく。 端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」 と考えられてきたためではないか。

荒らし対策をするしないは運営者の自由

あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して 欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって 生じ得る危険性の種類によって異なる。

たとえば、IPA の脆弱性届出状況の統計資料の付表には、脆弱性の種類として「価格等の 改ざん」という項目があり、深刻度が「低」とされている。 そして、昨年10月に公表された資料には、

ウェブアプリケーションの脆弱性については、修正を完了したものが10 件、 脆弱性を運用で回避したものが4 件、ウェブサイト運営者 により脆弱性はないと判断されたものが5 件あります。

とある。運用で回避とされたものがどのようなものかわからないが、 「価格等の改ざん」の脆弱性であれば、たしかに運用で回避できることもある。

「価格等の改ざん」とは、「Hidden Field Manipulation」とか「Parameter Tampering」と呼ばれるものの一種にあたるのだが、hiddenなパラメータを をブラウザ側で操作するというのは、なにも価格情報だけではなく、 ユーザ名やセッションIDを書き換えるのだって、そのパラメータが hidden フィールドに配置されていれば、hidden field manipulationということにな るのであって、そのパラメータの内容が何なのかによって、それが脆弱性にな るのか、どんな危険性をもたらすのかは大きく異なってくる。

価格改ざんの脆弱性とは、比較的小規模なネットショップに存在する。小規模 サイト用の簡易ショッピングカートシステムでは、サーバ側でセッション管理 をせず、前のページから次のページへの情報の伝達をすべて、hiddenフィール ドに載せて、サーバとブラウザ間を行ったり来たりさせる仕組みになっている ものがある。商品のページに商品コードと単価が掲載されており、そこをクリッ クすると、カートに商品番号と、注文数、そして単価が格納される。これが HTMLのhiddenパラメータに載せられて、次のページである商品発送先住所入力 画面の見えないところに埋め込まれ、注文確定ボタンを押すと、それらのデー タがサーバ側で注文として記録処理されるという仕組みである。このとき、最 後のページで、単価を差し替えて送信してしまえば、価格を偽って(安く)買 い物ができてしまうという問題である。

これはいわば、バーコードのなかった何十年前のスーパーマーケットで、商品 に貼られた単価シールを別の商品のものに張り替えてレジに持っていくという、 詐欺行為に相当するものだろう。

これはたしかにセキュリティ脆弱性ではあるが、これによって被害を受けるの は、サイト運営者のみである。

もちろん、システム構築者の立場や、脆弱性監査を行う者の立場からすれば、 この脆弱性はチェックが欠かせないものに違いない。だが、第三者がこの脆弱 性を発見して、サイトに直せと要求するのは滑稽ではなかろうか。

第三者による脆弱性の指摘に不快感を示す者がしばしば持ち出す喩えとして、 「『お宅の玄関、鍵が開いていますよ』と言うようなものだ」という話があり (つまり、善意の押し付けであるという主張があり)、それに対して、「そう いう喩えは不適切だ」とする主張も見られるのだが、価格改ざんの脆弱性を第 三者が指摘するというのはまさに「お宅の玄関、鍵が開いてますよ」と言う レベルのものだ。

IPAへの脆弱性届出は、そういった押し付けのための制度ではない。そのこと は、制度の根拠となっている経済産業省の告示の中でも次のように書かれてい る。

IV. 本基準の適用範囲

本基準は、以下に掲げるものの脆弱性であって、その脆弱性に起因する被害が 不特定多数の者に影響を及ぼし得るものに適用する。

ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示 第235号

価格改ざんは「不特定多数の者に影響を及ぼし得るもの」にあたらないだろう。 運営者が「運用で回避」と言って直さないというのは自由である。 IPAはその届出に対し、制度の趣旨の適用範囲外であるとして、不受理として も差し支えなかったのではないかとさえ思う。

それと同様に、たとえば誰でも書ける掲示板において、荒らし行為を防ぎきれ ていない「脆弱性」があるとして、それを外部から「おたく、まだ荒らされる 可能性がありますよ」と言って、「脆弱性の指摘だ」と称するのは滑稽である。

IPAへの届出で期待されているのは、サイトの利用者に被害が及ぶ種類の脆弱 性である。特に、プライバシー情報が漏えいするものは、取り返しがつかない という点で特に重要性が高くなる。この場合は、「お宅の玄関、鍵が開いてま すよ」ではなく、「御社の顧客名簿が外から見えそうなのですが」ということ に相当する。

これらの違いを区別することは重要である。

クロスサイトスクリプティング(XSS)脆弱性は、HTMLタグの「<」と「>」な どをエスケープするところに要点があるが、それと同じことが、掲示板荒らし 対策として考えられていた時代もあった。つまり、タグを書き込めない仕様と なっている掲示板において、タグを書き込めてしまう方法が残っていると、 巨大な文字サイズをFONTタグで指定して荒らすとか、音の鳴るタグを埋め込ん で荒らすといった行為が横行していた。荒らす者の勝手な言い分として、「お たくのセキュリティが甘いからですよ」などと主張することもあったようだ。

そのような種類の問題では、外部から直すべきだと主張する妥当性は低い。 しかしそれが、cookieの漏えいがひき起こされてセッションハイジャック攻撃 に遭うとか、ページ内容を差し替えられてフィッシングに騙されやすくなるといっ た問題として理解されるようになって初めて、対策の必要な脆弱性として認識 されるようになったわけである。

CSRF攻撃の脅威は荒らし行為だけか

CSRFも、荒らし対策された掲示板への攻撃手法として使われる。たとえば、 荒らし書き込みをしていた人物が、発信元IPアドレスで書き込みを禁止された 場合などに、CSRFを使って他人のブラウザに荒らし書き込みをさせることで荒 らし行為を成功させるということがある。こうした攻撃は2ちゃんねる掲示板 などでも一時期は頻発し、Referer:フィールドのチェックといった方法で対策 されたという経緯がある。

4月27日 の日記で参照した@ITの記 事でも、CSRF対策が荒らし対策と混同されている様子がうかがえる。 記事中の対策方法を挙げている部分で、CAPTCHA方式が持ち出されているが、 CAPTCHAは、機械による自動処理を防止するための仕組みであり、荒らし行為 を防ぐための最後の砦なのであって、CSRF対策に必要なものというわけでは ない。

掲示板以外、たとえばネットショップのWebアプリケーションにおいて、CSRF の脅威があるかどうか、そしてそれはどんな脅威なのかというと、まず、 おそらく、登録している個人情報を変更させられてしまうといったものが多い のではないかと思われる。ユーザがそのサイトにログイン中のときに罠のペー ジにアクセスしてしまうと、個人情報変更ページに差し替えデータとともに POSTアクセスさせられるといったものだ。

他には、商品注文画面を連続的にアクセスさせられることによって注文を自動 確定させられるといった被害や、アカウントを削除させられるという被害も考 えられる。

しかしこれも、荒らし行為の延長に過ぎないとみなすこともできる。そうした 操作は、運営者によってキャンセルすることが可能な場合が多いと思われるか らだ。ユーザが異変に気付くことができるならば、事態が発覚してサイト運営 者が対応を余儀なくされるという点で、運営者に対する業務妨害行為だとみる こともできるだろう。業務妨害にあたるような攻撃は防ぎきれないのであって、 どこまで技術的に対策するかは、運営者の自由だといえる*1

だが、CSRFの脅威は、そうした荒らし行為の部類のものに限られるわけではな い。

たとえば、4月19日の「水無月ばけらのえび日記」などにも書かれているように、 パスワード変更機能で旧パスワードの同時入力がないと、CSRFによってパスワー ドを強制的に任意の文字列に変更されてしまうという脅威があることになる。 変更したパスワードで不正アクセスされれば、それによって起きる被害は、 ユーザに降りかかってくる。

他にも、ログイン中のWeb操作で変更が可能な設定項目によって、公開か非公 開かを変更できるようなシステムの場合、非公開にしていたはずのコンテンツ を、CSRF攻撃によっていつのまにか公開に設定変更させられていたという被害 が考えられる。この被害はユーザにとって取り返しのつかない事態となり得る ので、サービス提供者にそうした被害につながるCSRFへの対策を求めることの 妥当性は、高いものとなる。

4月にCSRFを有名にさせた「ぼくはまちちゃん」事件の舞台となった mixiのよ うに、SNSとかblogのWebアプリケーションは、まさにそうした設定項目を持つ ことが多く、その点で、最近になって脅威の高いCSRF脆弱性が増していると言 うことができる。

CSRF対策が遅れる理由

センスある開発技術者の立場からすれば、「あんな対策も必要、こんな対策も 必要」と言われることは、プログラミング美学に反すると感じられることもあ る。

XSSやSQLなどのインジェクション系の脆弱性は、脆弱性であるという以前に、 本来正しいコーディングをしていればそういう穴にはならないのだから、 美学に反するものではない。バッファーオーバーフローもそうだ。 センスある開発技術者にとっては「対策」不要というのが美学だ。

その点、CSRF対策が必要というのは、どうにも気持ち悪いものとなる。 画面の遷移をすべてチェックするというのであればまだわかるが、 一部の画面に姑息な手段で対策を仕掛けないといけないとなると、なんだか 美しくないように感じられる。

対策方法はできるだけシンプルであるのが美しい。CAPTCHAなどという大掛か りなものまで持ち出されたら、「なんか違うんじゃないか?」とか、 「えーそこまでしないといかんの??」という反応になるだろう。

対策が美しくないのだとしても、ユーザに重大な脅威をもたらすCSRF攻撃の 弱点があるならば、対策はしなくてはならない。しかたがない。 だが、ユーザに致命的な被害が及ばない種類の脅威、つまり「荒らし対策」の ような種類のものについてまで、「直せ」と外部から言われたら、開発技術者 は反発してしまうかもしれない。

@IT の記事は、

Webサイトの運営者はエンドユーザーに期待せず、十分にCSRF対策を行っていただきたい。また、読者の皆さんがCSRF攻撃が可能になっているWebサイトを発見した場合には、Webサイトの管理者なり、IPAなりに適切に報告して欲しい。

と締めくくられていたが、こんなふうに書かれると、荒らし攻撃の部類に入る ものまで、IPAに届け出られるのではないかと心配になった。

サイト運営者に修正を促すような脆弱性報告をするときは、その脆弱性によっ てもたらされる脅威の重大性を示した上で報告するべきである。

(追記する予定)
(7月10日追記)

これまでの経緯

過去に国内でCSRFに相当する脆弱性のことが話題になっていたかといえば、 2001年7月に「セキュリティホールmemo」メーリングリストに投稿された[memo:846] が思い起こされる。このときは「セッション管理の脆弱性」という名称で呼ば れた。その名称は適切でないと思った記憶がある。セッション管理上の何にど ういう原因があるのかを示唆しない名称であるし、しばしば別の種類の脆弱性 を指す言葉として用いられることもある言葉だ*2

このとき、あまり反応がなかったのを覚えている。メーリングリストでのフォ ローアップも[memo:851] の一件しかなかった。「セキュリティホールmemo」での取り扱いも次のように そっけないものだった。

セッション管理の脆弱性
([memo:846], Tue, 17 Jul 2001 18:40:51 +0900)

HTTP を通じたセッション管理における脆弱性と回避方法の考察。 Referer リクエストヘッダの除去 にもこの記事の記述を追加しました。

セキュリティホールmemo, 2001年7月18日

当時の私の感想は、「こういう脆弱性は無数にある」「やばいな」「やばいか もしれないが深刻さは相対的に小さめだ」というものだったような記憶がある。 その後も、無線LANルータを買うたびに設定画面とかが危ないのではないかと たびたび心配になることもあったが、攻撃者の動機が少ないであろうことや、 攻撃が成功するには、別途必要な情報がある(たとえばルータのIPアドレス) 場合が多かったり、被害者のログイン中にしか成功しないことなどから、問題 点を製品開発者に伝えても直してもらえないだろう(おそらく、「設定を終え たらブラウザを終了してください」という注意文が公表されるだけで終わる) と予想していた。

他に重要な脆弱性があって、そっちの啓発をしなくてはならない状況において、 開発者に「直さない」という判断をさせるような問題を同時に扱ってしまうと、 脆弱性問題全体の啓発に支障が出かねないということを考えた記憶もある。

しかし時が過ぎるとともに、こうした受動的攻撃(被害者に罠を踏ませること で発動する攻撃)が予想を超えて現実のものとなっていった。転機となったの はその2か月後のNimdaワームの蔓延あたりだろうか。さらには、ここ2年ほど で、phishingが大きな被害を出したことから、受動的攻撃を無差別メール経由 で発動させることが有効な攻撃として十分に成立することが明らかになったし、 スパイウェアやpharmingの手口を見るにつけ、金銭目的による犯行ならば、成 功する確率が低くても攻撃者にとっては見合うらしいことがはっきりとしてき た。

また、SNSやblogサービスなどのように、ログインしたまま使うサービスが増 えたことも状況を変化させてきている。昨年の5月には、「はてな」の近藤社長とお会いした機会に、 罠リンクを踏むとアカウントを消される問題について口頭で伝えていた。その 後、9月にも別の方からの指摘があったらしく、「は てな」はこの種の脆弱性を修正したらしい。

いよいよこの種の問題の啓発を進めないといけないかもしれないな、と思いつ つも、どう進めていってよいか道筋が見えなかった。昨年11月のInternet Week 2005のチュートリアル「安全なWebアプリ開発の鉄則 2004」では、36 枚目のスライドでこの種の脆弱性を扱った。 このときのタイトルは「きわどい操作を強制させられる」としていた。 この時点では「CSRF」という呼び方を知らなかった。

そしてその半月後、「ほほう、いよいよこの脆弱性に名前がついたんだな」と 思ったのが、securityfocus.com の webappsecメーリングリストにアナウンス が投稿されて知ったホワイトペーパー「Session Riding ― A Widespread Vulnerability in Today’s Web Applications」だった。 この論文は冒頭で次のように主張している。

In this paper we describe an issue that was raised in 2001 under the name of Cross-Site Request Forgeries (CSRF) [1]. It seems, though, that it has been neglected by the software development and Web Application Security community, as it is not part of recent Web Application Security discussions, nor is it mentioned in OWASP's Top Ten [2] or the like. (略)

We prefer to call this issue Session Riding which more figuratively illustrates what is going on.

(私訳)

この論文では、2001年にCross-Site Request Forgeries (CSRF) の名称の下で 提起された問題点について述べる。これは、しかし、ソフトウェア開発のコミュ ニティにも、Webアプリケーションセキュリティのコミュニティにも無視され てきたように思える。最近のWebアプリケーションセキュリティの議論の対象 になっていないし、OWASPのトップ10やそれに類するものでも触れられていな い。(略)

我々は、この問題のことを、何が起きるのかをより比喩的に言い表して、 Session Ridingと呼ぶのを好む。

Thomas Schreiber, Session Riding ― A Widespread Vulnerability in Today's Web Applications, 2004年12月

CSRF対策が進まないのは日本に固有のことではなく、国際的にもいくらか同様 の状況があったとみえる。CSRFの名称は確かに 2001年6月のBUGTRAQへの投稿 が初出のようで、調べてみると、自分も受信していて、「重要」のマークを付 けていた。後で読むつもりで読んでなかったのか、記憶に残らなかったのかは わからない。

  • Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images), BUGTRAQ, 2001年6月15日

    Subject: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)
    Date: Fri, 15 Jun 2001 01:15:42 -0400
    From: Peter W <peterw@usa.net>
    
    Cross-Site Request Forgeries
    (CSRF, pronounced "sea surf")
    
    I hope you don't mind if I expand on this a bit. You've come across the
    tip, in my opinion, of a rather large iceberg. It's another
    Web/trust-relationship problem. Many Web applications are fairly good at
    identifying users and understanding requests, but terrible at verifying
    origins and intent.
    (略)
    

調べてみると、「CSRF」はwebappsecでは、2001年12月に一度話題になったも のの、次に登場するのは2003年1月に一度、その次は2004年3月、次は8月、そ して12月の論文紹介と、たしかに話題になることが少なかったようだ。それが 2005年になると、1月、2月、3月、4月、6月と毎月のように話題となっている。

問題提起が憚られるもうひとつの理由

「CSRF」ないし「Session Riding」の名前を使い、キーワードを連呼して啓発 するというのが適切でないというのは、先に書いたとおり、それによって起き 得る被害の性質に大きな幅があるためなのだが、重大な結果をもたらし得るケー スについても対策が進まなかった理由として、次の懸念もあったのではないか。

CSRFによる被害が出たとき、罠を仕掛けた攻撃者の行為は、日本の法律に照ら して違法となるだろうか?

アクセスをするのは被害者自身によるものであるし、そのアクセス自体は制限 された利用の制限を免れるものではないので、不正アクセス禁止法には触れな いと思われる。

荒らし行為が行われれば、業務妨害罪による立件もあり得ると思われるが、特 定の個人だけを狙ったCSRFの場合には、業務妨害とするのも無理かもしれない。

刑法改正で予 定されている「不正指令電磁的記録作成等の罪」ならば、こうした行為を 罪に問えるかもしれない。これは俗に「ウイルス作成罪」と呼ばれてきたもの であるが、改正案の条文は次のようになっており、いわゆるウイルスのみでな く、受動的攻撃全般をも指すようにも解釈できそうである。

人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録

この法改正が必要とされていることからも、現行法で受動的攻撃のようなもの をカバーしきれていないことがうかがえるところであり、この刑法改正は、 CSRF攻撃も抑止できるかもしれないという意味で歓迎されるところである*3が、 去年もこの改正は見送られており、いまだその抑止効果は有効になっていない。

この状況で下手にCSRFの危険性を主張しはじめると、違法でなければ何をやっ てもよいという輩が、悪戯を繰り返して被害を出しかねないという懸念もあっ たのではなかろうか。

XSS脆弱性の場合は、罠によって他人に他所のドメインのページの画面上でス クリプトを実行させるところまでは、CSRF同様に罪に問えないと思われるが、 それによって盗んだcookie(セッションID)を使って当該サイトにセッション ハイジャックのアクセスをした時点で、不正アクセス禁止法3条2項2号違反と なると思われるため、安心して啓発活動をすることができた。

そうした法律による保護が、CSRFに対してはまだできていないため、誰も問題 提起せずに来てしまったのではなかろうか。

mixiの事件以来、既に大きく話題になってしまった以上、荒らし行為では済ま ないような(つまり、情報漏洩など、取り返しのつかない結果をもたらす) CSRF脆弱性についてはいまこそ対策を進めるべきであろう。

*1 CSRF攻撃を 受けたユーザが身の潔白を説明させられる手間を食わされるという点で、ユー ザにも被害はあるわけだが、そのことによるサイトの信用低下を、かまわない レベルと判断する運営者がいても不思議ではない。

*2 IPAの脆弱性届出状 況の統計資料の付表においても、「セッション管理の不備」という分類項 目がある。IPAの用語定義では、「セッション管理の不備」とは、セッション 追跡パラメータの値として、第三者に推測可能な値(ユーザIDそのものなど) を使用している場合のことを指すらしい。

*3 ただし、昨年5月15日の日記にも書いたとおり、 ウイルスには該当しないような不正指令電磁的記録については、実行の用に供 した者だけを処罰の対象とし、作成および提供は除外するべきである。

本日のリンク元 TrackBacks(91)

2005年07月04日

明日のテレビ東京「ガイアの夜明け」

明日(5日火曜日)の夜10時からのテレビ東京の番組「日経スペシャル ガイア の夜明け」で、次の内容のものが予定されているようだ。

さて、どんな内容になっていますやら。

本日のリンク元 TrackBack(0)

2005年07月10日

本日のリンク元 TrackBack(0)

2005年07月11日

宮城県がセキュリティアップデートの中止を推奨中

という記事が出ているし、3月の時点でもJPCERT/CCから次の注意喚起が出ていた。

  • JPCERT/CC REPORT 2005-03-30, JPCERT/CC, 2005年3月30日

    これは JPCERT/CC が 3/20(日) から 3/26(土) の間に得たセキュリティ関連 情報のうち、重要と思われるものを抜粋してまとめたレポートです。

    (略)

    [4] Java Web Start の脆弱性

    (略)

    Java Web Start には、本来許可されていない動作をアプリケーションに許し てしまう脆弱性があります。結果として、遠隔から第三者がアプリケーション を経由して、そのアプリケーションを実行しているユーザの権限を取得する可 能性があります。対象となるのは以下のバージョンの J2SE に含まれる Java Web Start です。

    - 1.4.2_06 およびそれ以前の 1.4.2 リリース Windows 版、Solaris 版、Linux 版

この脆弱性は、発見者が報告していたように、容易に悪用されかねない極めて危険性の高いものであった。Java Web Startの起動は、J2SE(JRE)をインストールしただけで有効になるので、「Java Web Start」という言葉を耳にしたことのない J2SE(JRE)ユーザにも影響する。

そういう状況があるにもかかわらず、宮城県企画部情報政策課は「よくある質問とお問合せ」のコーナーで、図1のように言っている。

宮城県と熊本県の電子申請ユーザが誤って実在する第三者プロキシを設定するおそれ

の両ページに書かれているとおり、宮城県や熊本県が配布している専用プログラムのインストーラを起動すると、図2の画面が現れる。



図2: 宮城県と熊本県が配布しているインストーラの画面

「プロキシサーバ」などと言われても何のことだかわからない人たちが使うであろう、電子申請システムにおいて、このように「記入例: proxy.server.co.jp」と書かれていれば、そのまま記入例どおりに、「proxy.server.co.jp」と入力してしまう人はけっこういるのではないだろうか。

そして、その記入例に書かれている proxy.server.co.jp:8080 というサーバは実在し、稼動しているようだ。宮城県と熊本県の配布物は、OCSPか何かのアクセスのときにこのプロキシ設定を使うようだ。

参考: http://www.server.co.jp/

本日のリンク元 TrackBacks(2)

2005年07月17日

官庁はJavaの脆弱性にどう対処すればいいのか

現状、Webを閲覧利用するにあたって、JRE(Javaの実行環境)のインストール を求められるのは、民間商用サイトにおいてはめったにないことだと言ってよ い。それに対し、政府系の電子申請システムを利用しようとすると、大半のケー スでJREのインストールを求められる。これは、ファイルに対する電子署名の 処理をクライアント側で行うようにしたこと、採用したXML形式による署名の ためにJavaライブラリが充実していることなどが原因だろうか。Javaの普及を 願う者としては願ったり叶ったりだが、JREの脆弱性発覚時の体制がWindowsの それほどには確立していないことが、仇となってしまっている。

インストールさせる者による脆弱性告知

先日の宮城県のケースはともかくとして、 JREをインストールさせている官庁(中央省庁および地方自治体)にとって、 JREに脆弱性が見つかるたびに対応策を告知することは義務であるという考え 方は、概ね普及したようである*1。まことに適切なことである。 しかし、告知には2種類のものがある。Javaのアップデートをしないで対処せ よと呼びかけるものと、アップデートせよと呼びかけるものだ。

前者の告知の内容はだいたい次のようなものになっている。

  • ○月×日、JRE 1.X.X_XX に脆弱性が発見されました。詳細については サンマイクロシステムズ社のページ(英語)をご覧ください。
  • △△省電子申請システムを利用する限りにおいては問題ありません。し かし、悪意ある他のサイトを訪れたときに当該脆弱性によってセキュリティ侵 害を受ける可能性があります。
  • この脆弱性に対策された新バージョン 1.X.X_YY がリリースされていま すが、△△省の電子申請システムでは動作保証をしていません。現在、鋭意 動作確認を行っているところですが、確認が完了するまで下記の対処方法にし たがってください。
  • 信頼できないサイトを閲覧しないでください。
  • 電子申請システムを利用中に他のサイトにアクセスしないでください。 電子メール中のリンクもクリックしないでください。
  • 電子申請システムの利用を終えたら、JREを非稼動状態に設定し、電子申 請システムを利用する間のみJREを稼動状態に設定してください。
  • Java Web Startを非稼動状態に設定してください。
  • ……

こんな複雑で手間のかかることを求めるくらいならいっそ、「当局への電子申 請には、当局電子申請専用のパソコンをご用意ください」とした方が簡潔でわ かりやすいのではないかと思えるくらいだ。

この種の案内を出しているところは中央では以下などがある。

地方自治体もこれに習ってか、同様の告知をしているところが少なくない。 参考: Google検索「java 脆弱性 site:lg.jp」

追いつかない対応

一方、現時点で脆弱なバージョンを使わせているにもかかわらず危険性を伝 えていないところもあり、警察庁、防衛庁、外務省、厚生労働省などがあった。

  • 警察庁, 電子申請・届出システム

    重要なお知らせ

    警察庁に申請をされる方のパソコンにインストールして利用するJava(TM)2 Runtime Environment(以下,J2RE) 1.4.1_01において、脆弱性が発見されたため、警察庁の電子申請・届出システムは脆弱性が解消されたJ2RE1.4.2_06に対応 いたしましたので、こちらを参照して早急な対応をお願い致します。(平成16年12月13日)

  • 防衛庁, JRE インストール手順

    RE(Java 2 Runtime environment)1.4.1_03が端末にインストールされて いない場合は、下記URLよりJRE1.4.1_03をダウンロードしてインストールしてください

    http://java.sun.com/products/archive/j2se/1.4.1_03/index.html(Windows(all languages,including English)を選択して下さい。

  • 外務省, 利用上の 留意事項(Java実行環境について)

    本窓口をご利用いただくにあたっては、サン・マイクロシステムズ株式会社のダウンロードサイトからJRE version1.3.1_10をインストールしていただく必要が ありますが、ダウンロードならびにインストールの際には下記の事項 にご注意ください。

    * version1.3.1_10以外のJREがインストールされている場合は、事前にアンインストールしてください。

    * 本窓口を利用するためのJREをインストールした後に、異なるバージョンの JREをインストールすると、本窓口が利用できなくなります。ご注意ください。

  • 厚生労働省, 電子申請・届出に必要なソフトウェア (リンク不能な場所 に書かれている文から引用:)

    ※ システムの動作確認は以下の各バージョンで行っています。
    JRE1.3.1_11、JRE1.4.1_07、JRE1.4.2_04
    セキュリティ等の観点から、JRE1.4.2_04でのご利用を推奨していま す。(平成16年6月現在)

このところ 1.4.2系列のJREに頻繁に脆弱性が発覚しており、各官庁の対応も 追いつかない様子が見られる。 しかし、そもそも「_XX」の「アップデートリリース」が出るたびに、「対応」 が必要となること自体がおかしいのではないか。

たとえば、総務省の対応はスマートなものになっている。

  • 総務省, 動作環境(平成16年9月現在)について

    5.Java実行環境

    次に示すいずれかのJava実行環境が必須です。(注3)

    ・Microsoft社 Java Virtual Machine(以下、『MSJVM』)(注4)

    ・Sun Microsystems社 Java 2 Runtime Environment v1.3.1、v1.4.1、 v1.4.2(以下、『JRE』)(注5)

    (注5) システムの動作確認はv1.3.1_10、v1.4.1_07、v1.4.2_03の各バージョンで行っています。セキュリティーの観点からは、最新バージョンの導入を推奨します。 JREはSun Microsystems社のページからダウンロードできます。

「_XX」のバージョンをとくに指定していない。つまり、「どのバージョンで も動きます」ということを言っていて、だからこそ、どのバージョンを使うか はユーザの責任だ(常に最新バージョンを使うことを推奨)と言えてしまって いる。

総務省のアプレットは規模が小さくて、他省庁のアプレットは大きいといった 事情の違いがあるのかもしれないが、本来目指すべきところは、このように実 行系のバージョンに依存しないアプレット作りであろう。

それが簡単なことではないことは知っている。1.4.1 が 1.4.2 になると動か なくなるということはよくあることだ。だが、「_XX」という「アップデート リリース」で動かなくなるというのは、どういう作りをしているのか? JREのバージョンを上げると動かなくなるというのは、枯れていない最新ライ ブラリを使っている場合を除けば、やはり下手糞なプログラムの書き方をして いる(誤ったライブラリの使い方をしているなど)からではないか。

「_XX」をセキュリティアップデートだと位置づけるのであれば、それによっ てアプリケーションが動かなくなるということは、ほとんど起きないものでな くてはならない。Windows Updateと同様にだ。

無責任な製品を国家インフラに使用?

だが、Sun Microsystemsはそれを提供してこなかったように思える。たとえば、JRE 1.4.2_08のリリースノートを見ると、各「_XX」バージョンでの変更点の一覧があるが、 ものすごい数のセキュリティに関係のないバグの修正が並んでいる。こんなの では、動いていたものが動かなくなる確率も上昇するだろう。

そういう事態を避けるために、セキュリティに関わるアップデートは独立して 提供するべきだが、Sun Microsystemsはそれをやっていない。 そういう、開発者のお遊びを続けているままのようなソフトウェアを、国家の 電子申請システムのために一般市民に使わせること自体が、そもそもの誤りで はないか。

Sunがしっかりしていないなら、ちゃんとやれと圧力をかける機会がSunの大口 顧客にはある(私にはない)わけだが、政府やITゼネコン会社たちはそういう 要求をちゃんとやっているのか? 金融庁の告知 にある、

1.この問題による危険性

サンマイクロシステムズ社のホームページにおいて、このソフトの脆弱性が公 表されております。こちらで内容をご確認ください。
http://sunsolve.sun.com/search/document.do?assetkey=1-26-101749-1

という、一般国民への危険性の説明において、英語のドキュメントしか紹介で きないというのは、誰が悪いのか? 日本語版の脆弱性文書を提供しない Sun のような会社の製品を国家のインフラにいつまで使い続けるつもりなのか。そ れが止むを得ないことなのなら、政府が日本語版の脆弱性説明文書を書いて公 表するべきだろう。

本当に動かなくなるのか

そもそも、電子申請のアプレットにおいて、「_XX」のバージョンを上げると 動かなくなるという事態が、本当に起きているのだろうかという疑問がある。 実際、「_XXにアップデートすると○○の機能が正常動作しなくなる現象が報 告されています」といった注意を呼びかけている役所をこれまでに見たことが ない*2。単に、 「動作確認ができていません」というだけのことではないだろうか。なぜそこ まで動作確認に拘るのか?

もしかするとこれは、まさにいわゆる役所仕事の弊害にすぎないのではないだ ろうか。つまり、発注時に、「JRE 1.4.2_04 での完動を保 証すること」といった要件を無思慮に入れているために、こういうことになっ ているのではないか。新たなアップデートリリースが出ると、役所は「動作を 保証できない」という思考に短絡し、正常に動くかもしれない可能性と脆弱性 回避のトレードオフという発想に思考が及びもしない。そして、「アップデー トを止める」という発想に陥るか、でなければ、新バージョンでの動作検証と 動作保証のための改修という新たな開発事業を発注するということをやってい るのではないか。

新たな「_XX」バージョンのリリースに対して、動作検証に何か月〜半年以上 もかかっているというのがおかしい。予算を確保するところから始めているの ではないか?

ここは、「JRE 1.4.2 の任意のアップデートリリースでの動作を保証すること」 という発注要件にするべきだろう。もちろん、そのための費用を上乗せしてだ。

その追加費用はどのくらいになるだろうか。新バージョンでの動作検証と改修 という追加事業にいくらかかっているか知らないが、仮に初期開発費の2割だ とする。システムの運用予定期間(たとえば2年)内に脆弱性が4回発覚すると 予測したとき、初期開発費の8割増しの費用でトントンということになるが、 実際にはそれより安くできるのではないか。

脆弱性が発覚するたびに毎回お決まりの「2割」分の追加事業を発注している 場合、アップデートで動かなくなるようなことは実際にはないにもかかわらず、 検証作業をチンタラやるだけで定期的に儲かってウハウハかもしれないし、逆 に、改修に必要なコストを毎回見積もる場合には、最初にあえて杜撰なアプレッ ト開発をやっておくことで、後にアップデートリリースが出るたびにボロボロ と改修項目が必要となってウハウハとか、そういうことが起こり得る。

そこを、最初からアップデートリリース時の対応改修費も一括して発注してお けば、受注者にとってきちんとしたアプレット作りが利益をあげるために必要 となるし、競争が存在するならば、割り増し分が適正価格に落ち着くかもしれ ない。

そういうことは行われているのだろうか? 「動かないコンピュータ」とかで 扱ってくれてもよさそうな話題なのだが。

JRE 5.0で事態は改善されるか

経済産業省の場合は JRE 5.0(別名 JRE 1.5)へ移行したようだ。JRE 5.0では、 「_XX」というバージョン表記は廃止され、「Update 4」といった名前が付け られるようになった。

これにより、これが「アップデートリリース」であることが名前からして明確 となったわけで、もはや官庁が国民に対して、「Update 1での動作しか保証し ていません」だとか、「Update 2にしないでください」などと呼びかけること は許されなくなると期待できる。Windows XPで「Service Pack 2の適用をさせ ない」などということが許されないのと同様にだ。

経済産業省は、次のように、JRE 1.4.X_XX を捨てて、JRE 5.0 系を使うよう に指示している。

  • 経済産業省, ITEM2000(Version 2.2.0)の入手方法

    旧バージョンのITEM2000で使用したJavaの動作環境(JRE1.4.1._07以前のJRE)では、最新版のITEM2000が正常に動作しません。

    旧バージョンのITEM2000を使用されていた方は最新版のITEM2000をインストールする前に、ITEM2000 Version 2.1.0とJREの両方をアンインストールし、さらに旧バージョンのITEM2000がインストールされていたフォルダを削除してください。

しかし、先ごろ発覚した Update 1の脆弱性については触れられていない。 これは次のように考えることが可能かもしれない。 JRE 5.0では自動アップデートの機能が Windows Update同様に、タスクバーに 現れるようになった(図1)。

図1: JRE 5.0の自動アップデート機能

これによって、JREのアップデートはユーザの責任ということになったと言う ことが可能かもしれない*3

しかしそれでよいのだろうか? Windowsをインストールさせている(というか、 インストールして販売している)パソコンメーカの何社かは、Windowsの脆弱 性パッチがリリースされるたびに、そのパソコンのポータルサイト等で Windows Updateの適用をうながす告知をしているくらいなのだから、最初から 入っているわけではないJREを自身の提供サービスの都合で消費者に入れさせ る事業者および官庁は、JREの脆弱性情報を告知するべきではないだろうか。 せめて政府機関くらいはそうしてほしい。Acrobat Readerの脆弱性についても。

とりあえず、アップデートリリースが出るたびに専用ソフトのCD-ROM(JREが 同梱されているもの)を作り直すということ(以前は行われていたこともあっ た)は、やらなくてもよくなったと言えるかもしれない。ただし、インストー ルと同時にアップデートチェックされるような仕掛けを用意するか、アップデー トの必要性を同梱マニュアルに書いておくべきだろう。

こういったことは省庁横断的に議論されているのだろうか。ベンダー間で集まっ て勉強会とかやっているのだろうか。地方自治体はどうするんだろうか。

*1 Acrobat Readerのインストールを要求 している官庁も、Acrobatの脆弱性発覚時に告知するべきだと思うが、それは 行われていない。

*2 そうした通知が必要ないほどまでに、あるいは、報告さえないほ どまでに、電子申請自体が使われていないのかもしれないが。

*3 しかし、更新確認の頻度が、初期設定では 月に1回と設定されているようなのだが……。

本日のリンク元 TrackBacks(3)

2005年07月18日

岡山県と外務省が他人の著作物の知的所有権を主張中

自治体の中で先進的と言われる岡山県の電子申請システムは、公的個人認証などに対応した電子申請のため、 利用者に専用インストーラを配布している。

配布されているのは、http://www.pref.okayama.jp/e-entry/ready/install.jar に置かれている実行形式のJavaファイルであるが、これを起動すると図1のよ うに「ライセンス利用許諾」*1なるものが現れる。

図1: 岡山県が著作権とその他の知的所有権を主張している様子

ここには次のように書かれている。

3 インストールツールに関する知的所有権

(1) 本インストールツールに関する著作権及びその他の知的所有権は、岡山県に帰属します

岡山県, 電子署名アプレットライブラリファイルインストーラ, 「ライセンス利用許諾」

しかし、配布ページにも書かれている(図2)ように、これは、「Log4j」や 「Xalan」、「Apache XML Security」など、 Apache Software Foundationによって開発が進められているオープンソースソ フトウェアが含まれる。これらは岡山県の著作物ではないし、岡山県が知的財 産権を所有するものでもなかろう。

図2: 岡山県が所有権を主張するファイル

それどころか、このインストーラがインストールするものは、これら のファイルだけのようだ(図3)*2

図3: install.jarがインストールするファイル

そうすると、これのいったいどこに岡山県が著作した部分や、岡山県の知的な モノが存在するのだろうか? 強いて挙げるなら、この「ライセンス利用許諾」 なる文書が、岡山県のチテキ財産だろうか。

「Log4j」や「Xalan」はApache Software FoundationがApache Licenseの下で 配布しているものだが、図3のように、Apacheのライセンス 文書は削除されていて存在しないし、インストーラやアプリケーションの実行 時にどこかに表示されるわけでもない。「Apache Software Foundationによっ て開発されたソフトウェアを含みます」といった一言さえない。

にもかかわらず、「本インストールツールに関する著作権及びその他の知的所 有権は、岡山県に帰属します」という。

Javaに必要なライブラリをバイナリ形式のまま ext/ (ないし endorsed/ ) 入れて使うというのは、開発者が開発時に自分でやる行為としては正当である にしても、こういう形で一般の人にインストーラで機械的に入れさせたうえ、 その著作権を主張するというのは、いくらなんでもダメだろう。

ちなみにこのインストーラのプログラムは、IzPackというインストーラ生成 系で自動生成されているようだ。

同様の行為は、茨城県パスポート電子申請のサイトと、長崎県電子申請システムのサイトにも見られる。

茨城県が http://www1.asp-ibaraki.jp/home/po/po/html/passport/html/JAVAlib.exe で配布し、 長崎県が http://eap.pref.nagasaki.jp/download/JAVALIB.exe で配布してい るインストーラは、同一のもののようだが、起動すると図4のように、「使用 許諾契約」という文書が現れる。


図4: 茨城県と長崎県が配布するソフトウェアの場合

これも同様に「Log4j」や「Xalan」などと、あとは総務省が権利を保有する JPKIのファイル(JPKICryptJNI.jarとJPKIUserCertService.jar)2個をインス トールするだけなのだが、下まで読んでも「Apache」の文字は存在せず、「著 作権及びその他の知的所有権は、外務省に帰属します」という。

図5: インストール物に同梱されているreadme.txt

図5のように、インストールされたファイル達とともに「readme.txt」という ファイルが存在するが、その内容は、先の「使用許諾契約」の文章そのもので あり、以下のように書かれている。

3. 本インストールツールに関する知的所有権

(1)本インストールツールに関する著作権及びその他の知的所有権は、外務省 に帰属します。

外務省の著作物というのは「uninst.bat」のことだろうか。

茨城県と長崎県は配布者としての責任を負っているが、開発元は外務省という ことで、外務省の「パスポなび」のサイトを見に行くと、「ソフトウェアとドキュメントのダウンロード」というページがあって、 図6のように、「Javaライブラリ」「申請データに電子署名を付与する際に必 要」として、 http://www.ryoken-inq.mofa.go.jp/fw/dfw/csv/direct/dl/JAVAlib.exe に置かれたファイルが配布されている。

図6: 外務省が JAVAlib.exe を配布している様子

これも茨城県や長崎県が配布しているものと同一のようだ。そして、「著作権 及びその他の知的所有権は、外務省に帰属します」という表示が現れる。

ただし、どういうわけか「初めて申請する 電子申請」という別のページ から入っていくと、 図7のように、「Apache Software使用に関して」という注記があり、 「著作権・使用許諾・通知事項」というリンク先で、Apache Licenseの全文と、 「This product contains software developed by The Apache Software Foundation」 という文言などが書かれている。

図7: 別のページでの JAVAlib.exe の配布の様子

しかしここで配布されているJAVAlib.exeも、「著作権及びその他の知的所有 権は、外務省に帰属します」と主張して、Apacheについては触れていない。

Apache Licenseは、このようにWebサイトに注意書きしておくだけで済まされ るものなのだろうか?

では、法に厳格であるはずの法務省の配布物はどうなっているだろうか。

法務省オンライン申請システムは「事前準備」のページで、独自のファイル「installer.exe」を配布している。これを実行すると、 図8のような使用許諾契約書が現れる。

図8: 法務省のインストーラが主張する著作権

第4条(著作権)

本システムの著作権は法務省が保有しており、国際条約及び著作権法により保 護されています。

2 本システムには、法務省に対するライセンス付与者(以下「供給者」とい う。)が権利を保有するソフトウェアが含まれています。

3 本システムはシステム利用者に対し、本使用許諾書に従い、非独占的に使 用許諾されるものであり、本システムの著作権が譲渡されることはありません。

「ライセンス付与者が権利を保有するソフトウェアが含まれています」 ……なるほど、これは万能な表現だ。どこにでもコピーペーストして使える。 下まで見ていくと、附則より下の部分に、図9のように

本ソフトウェアには、IBM XML Parser for Java Edition が含まれている他、Apache Software Foundation(http://www.apache.org/)により開発されたソフトウェアが含まれています。

と書かれている。

図9: 法務省の使用許諾契約書の末尾部分

これでよいのだろうか……よくわからない。

よくわからないが、C:\moj\ にインストールされたファイルを見に行ってみ ると、図9のように、ApacheのLicenseファイルは見当たらない。 こんなのでよいのだろうか?



図10: 法務省配布物の中身にApache Licenseファイル が存在しない様子

法務省はきちんと考えがあってやっているのだろうが、岡山県の事例のように、 地方自治体がそれぞれこうやって独自の著作権を主張するソフトウェアの配布 をこれからするようになっていくだろうと思うと、ゾッとしてくる。

政府発注のシステムにオープンソースプロダクトを使うのを広めるのはよいに しても、ライセンスの処理の方法などはガイドラインでも用意しておかないと、 何も考えない役所は、開発者のお遊び気分のままのような代物を、そうとは知 らずそのまま出してしまうのではなかろうか。

*1 日本語として変だ。ライセンスを利用す る許諾の何?

*2 その他には、総務省が権利 を保有するJPKIの ライブラリ2個を別のディレクトリ(市町村役場で受け取る公的個人認証の CD-ROMによって既にインストールされているもの)からコピーしてくるしかけ になっている。

本日のリンク元 TrackBacks(3)

2005年07月19日

自炊が楽しくなってきた今日この頃

今日は夕方から秋葉原に出勤の予定なので昼すぎまで東京の自宅ですごしてい る。 つくばに住んでいたときと違って部屋が人並みに広くなり、ちゃんとしたキッ チンがある。自炊を始めたところ、これがなかなか楽しい。 昼ごはんに鶏肉のアラビアータを作ってみた。

4月に引っ越して以来、インテリアをそろえるために、あちこちのネットショッ プを使いまくった。さて、個人情報は漏れずに済むだろうか……。

本日のリンク元 TrackBack(0)

2005年07月22日

警察庁の指示がスパイウェア感染を招き金融被害をもたらしている可能性

最近、必要もなくやたら文字を小さく表示させるWebサイトが増えている。 官公庁も例外ではない。そのくせ、「文字を大きくするには」などという案内 を用意して、曰く、「アクセシビリティ」なのだという。アホかおまえら。 作っていておかしいと思わないのだろうか。もしかすると彼らは、文字を大き くするブラウザ設定で作業しているのかもしれない。だから自分のページでは、 文字を少し小さく作りたくなるのだろう。すると、そこを閲覧する人がまた少 しブラウザの文字サイズを大きくする。そして、そこが作るページはさらにま た少し小さい文字となり、そこを閲覧する人がまた少しブラウザの文字サイズ を大きくする。つまり、文字サイズのデフレスパイラルに陥っているわけだ。 一度地獄まで落ちたらよい。

たとえば、最近リニューアルされた警察庁のトップページが特に酷い。図1は Firefoxで文字サイズ標準で表示したときの様子である。

図1: 警察庁トップページの一部(原寸大)

読めない。

こんなアクセスビリティの悪いサイト作りが官公庁に許されるはずもないわけ で、右上を見ると「音声読み上げ・文字拡大はこちら」と書かれている(図2)。

図2: 警察庁が「音声読み上げ・文字拡大はこちら」と案内している様子

そして、この「音声読み上げ・文字拡大はこちら」のリンク先に何があるかというと、 図3のようになっている。

図3: 警察庁がActiveXコントロールをインストールさせている様子

その下を見ると次のように書かれている。

動作環境

(略)

ブラウザで、JavaScriptの実行が有効になっていること。
ブラウザで、Cookieの使用許可が有効になっていること。
ブラウザで、署名付きActiveXの実行が有効になっていること。

そして、「ブラウザの設定方法」というところに、「署名付きActiveXの実行 を有効にする方法」という説明がある。そのリンク先は図4の ようになっている。

図4: 警察庁が署名ActiveXコントロールを「有効」に設定せよと指示している様子

「署名済みActiveXコントロールのダウンロード」のデフォルト設定は「ダイ アログを表示する」である。このときのダイアログとは、ActiveXのデジタル 署名の署名者名を確認して、信用できる発行者によって作られたものかを確認 するという、図3の画面の図にあるステップのことだ。

ここの設定が「有効」になっていると、どんな発行者によるActiveXコントロー ルであっても、確認なしに自動的にインストール、実行されてしまう。つまり、 気付かないうちにスパイウェアに感染し放題という状態になってしまうわけだ。

ちょうど一昨日、内閣官房から「夏休み期間にお ける情報セキュリティにかかる注意喚起 〜 フィッシングやスパイウエアへの 対応について 〜」という報道発表が出ていたところだ。そこには図5のよ うに書かれている。

図5, 内閣官房, 警察庁, 金融庁, 総務省, 経済産業省, 「夏休み期間における情報セキュリティにかかる注意喚起 〜 フィッシングやスパイウエアへの対応について 〜」の5ページ目より

「十分な対策を講じていない場合」とある。そのとおりだ。「十分な対策」と は、ウイルス対策ソフトを入れることではあるまい*1。本来、「対策」など という、追加の処置をしていなくても、「サイトを閲覧するだけでスパイウェ アをインストールされる」などということがあってはならない。起きるとした ら何らかの欠陥があるということだ。つまりここで言う「対策」とは、1ペー ジ目に書かれている「OSをアップデートし常に最新の状態にする」のことをわ かりやすく言っているのだろう。

だが、警察庁の指示通りに「署名済みActiveXコントロール」の設定を「有効 にする」に設定している人は、いくらWindows Updateをしていても、「サイト を閲覧するだけでスパイウェアをインストールされる」ことになる。当然、ウ イルス対策ソフトも効かない。

昨年7月24日の日記にも書いていたように、警察庁と同じ方法で大穴を開けさせている ところは、昔からたびたび見つかっている。であるから、今、注意喚起として 本当に有効で必須のことは、

あなたのセキュリティ設定は間違ったものに変えさせられていませんか?

と、今一度確認させることだ。だが、内閣官房の「夏休み注意喚起」もこのこ とを教えてくれなかった。

もう何年も前から何回も何回も何回も何回もこの問題を言ってきたが、今時分 になって警察庁までもがこのありさまというのは、どうしたことか。悪いのは 業者ということなのだろうが、この事態を防止するには、もう、セキュリティ ポリシーやらでこういう行為を禁止するよう明文化しておくしかないだろう。 聞くところによれば、各官公庁は情報セキュリティポリシーを作るところまで はまず達成したのだそうだが、こういう禁止行為は明文化されているだろうか。

さて、警察庁が今果たさなければならない義務はこうだろう。まず、 http://www.npa.go.jp/zsmd/html/index.html のページを見たすべての 人に対して、設定を見直すように呼びかける必要がある。このとき、なぜその ような呼びかけをするのかの理由として、間違った危険な設定を指示をしてい たことを説明する必要があるだろう。すべての人に対して呼びかけることは、 当該ページに掲載するだけでは達成できないであろうから、少なくとも npa.go.jp トップページへの掲載が必要。それでも無理だとなれば報道発表で 国民に周知するしかなかろう。

他にも問題がある*2。図3の説明も有害である。

起動中に以下のようなセキュリティ警告が表示された場合は、「はい(Y)」ボ タンをクリックしてください。

とあるが、何も考えずに「はい」を押す行動を習慣付けている。ここで重要な ことは、「Hitachi Government & Public Corporation System Engineering Ltd.」とは何なのかを理解*3して、 信用できるかを閲覧者が自ら判断しなくてはならないということだ。この習慣 付けなくしては、スパイウェア対策にならない。

つまり、日立公共システムエンジニアリング株式会社の製品を使ってアクセスビリティ機能を実現している のだということを、警察庁自身が説明しないといけない。なぜなら、警察庁 サイトの閲覧者は警察庁を信じて閲覧に来ているのだから。

だが、「音声読み上げ・文字拡大はこちら」のページのどこにも、そのこと (配布主体が誰なのか)は書かれていない。そればかりか、配布主体について 次のように書かれている。

■免責事項

「ZoomSight」の利用により、直接的あるいは間接的になんらかの損害が発生 した場合でも、警察庁は、一切の責任を負いませんので、予めご了承ください。

追記

日立公共システムエンジニアリングの、Zoom Sightのページを見に行くと、どうやらこの製品は多数の官公庁に導入さ れているようだ。まさか……と嫌な予感がしつつ「署名付きActiveXの実行を有効に」で検索などしてみたところ、 汚染がかなり広がっているようだ。

嗚呼、糞業者!!

追記(7月25日)

検索のキーワードを変えてみたところ、他にもいくつか見つかった。

*1 ウイルス対策ソフ トなんぞ、スパイウェア対策にならないのだから。

*2 さらに言えば、「Cookieの使用許可を有効にする方法」の指示も間違っている。この指示は、デフォルト 設定よりプライバシーレベルを下げさせている。

*3 ほんとうは、この警告ダイアログの「名前 : ZoomSight」の部分が、メーカーのこの製品の説明ページへのリンクになっ ていないといけないのだが、このメーカーはそれもやっていない。

本日のリンク元 TrackBacks(33)

最新 追記

最近のタイトル

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|
最新 追記