最新 追記

高木浩光@自宅の日記

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

2005年12月02日

無題

リンク元を辿ったところ、

高木浩光氏のブログにトラックパックを送っているのだが、何故か失敗してし まう。今までブログを使ったことがないので、やり方を間違えているのだろう。

TTFOXZの日記 2005-11-28

というのがあったので、こちらからリンクして差し上げることにする。

本日のリンク元 TrackBacks(100)

2005年12月03日

トレンドマイクロが嘘を言い始めてしまったが大丈夫だろうか

*1

11月25日の日記で

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

と書いたが、同じ日の同じころトレンドマイクロの製品Q&A(トラブルシューティング)に、「solution 12478」というエントリが追加されていた。

このエントリは11月25日に登録されたが、11月28日に改定されている。改定部 分がどこかというと、以下の部分だけのようだ。

上記機能に伴い、弊社サーバに送信された情報の扱いに関しましては、アクセス先URLのパラメータ部分を除くURL情報(*注1)のみ弊社サーバに蓄積され、お客様に関する各種情報(アクセス元IPアドレスやアクセス時間、ブラウザの種類など)につきましては一切保持されません


solution 12478: [URLフィルタ]ならびに[フィッシング対策ツールバー]によってトレンドマイクロへ送信される情報と扱いについて, トレンドマイクロ, 11月25日初版

上記機能に伴い、弊社サーバに送信された情報の扱いに関しましては、アクセス先URLのパラメータ部分を除くURL情報(*注1)のみ弊社サーバに蓄積され、お客様に関する各種情報(アクセス元IPアドレスやアクセス時間、ブラウザの種類など)につきましては本機能によって弊社サーバへ送信されることはありません


solution 12478: [URLフィルタ]ならびに[フィッシング対策ツールバー]によってトレンドマイクロへ送信される情報と扱いについて, トレンドマイクロ, 11月28日改訂版

「アクセス元IPアドレスが送信されることはない」というのが虚偽だというの は自明だろう。(それとも、「IPスプーフィングしています」とでも言うのか?*2*3

「アクセス時間が送信されることはない」というのはなかなか珍妙だ。たしか に、アクセス時間を表現したデータを送信してはいないのだろうが、送信とい う事象の発生自体が時刻を確定させるわけだから、アクセス時間が送信される のと同等だ。(それとも、「ユーザのアクセスから十分に長いランダムな時間 経過後に送信しています」とでも言うのか?*4

なぜこんなみっともないことをする必要性があるのか理解し難い。

25日にメールで頂いた回答では、

お客様に対して十分な説明が無かったことに関しましては、弊社といたしましても謙虚に受け止め、今後、弊社ホームページならびに製品ヘルプ等へ本仕様に関する情報を明記を行い、お客様に対して情報開示を行っていきたいと考えております。

とのことだったが、このような心構えの下でそのような情報開示ができるのだ ろうか。

日経バイトの誤報は訂正されるか

星澤さんが11月21日の日記に書いていた日経バイト12月号には、次のように書かれていた。

中でもトレンドマイクロの「ウイルスバスター2006」はフィッシング詐欺,ファー ミング詐欺対策として,Webサーバーへのアクセス時に毎回トレンドマイクロ のデータベースを参照するというこれまでにない仕組みを 導入した。(p.57)

ウイルスバスター2006はフィッシング詐欺/ファーミング詐欺対策として,三 つの機能を搭載している。一つ目が「サイト評価機能」。Webサイトアクセス 時に,トレンドマイクロのデータベースに保存してある信頼サイトのURL リスト(いわゆるホワイトリスト)とアクセスしようとしているサイトのURLな どを照合し,正しいサイトであれば同社が決めたサイトの分類 (ニュースサイトなど)を表示してアクセスする。違っている場合は接続を遮 断する。 (p.58)

DNSサーバーで名前解決後,ウイルスバスター2006はトレンドマイクロのデー タベースに接続してWebサイトの評価情報を取得する。評価情報とは, ドメイン名,IPアドレス,Webサイトのカテゴリ,信頼性情報(信頼サイト, フィッシング詐欺サイト,未登録サイト)の四つ。DNSで取得した情報が正当 なものだと判断されれば,WebサーバーにHTTPで接続する。ちなみに,同社の データベースに送信したドメイン名などは保存していないという。 (p.58)


セキュリティ対策ソフトの新機能, 日経バイト2005年12月号

ここには事実と異なることが2つ書かれている。

記事は全体として何かを送信するということについて書いておらず、送信して いると読める部分は「送信したドメイン名など」となっているように、あたか もドメイン名しか送信しないかのように書かれているが、実際には、ドメイン 名以外に、ホスト名、パス名、URLパラメタも送信している。

記事には「ドメイン名は保存していない」と書かれているが、トレンドマイク ロの製品Q&A(トラブルシューティング)によれば、 ドメイン名は保存している(「弊社サーバに蓄積され」)とある。

また、事実と異なるように誤解させる記述がさらに2つある。

記事には「DNSサーバーで名前解決後」とあるが、11月27日の日記に書いたように、存在しないサーバ名のURLを入力してエンターキー を押しても、その文字列が送信される。あたかも名前解決できたときだけ 送信されるかのように記事は読まれかねないが、それは事実でない。

記事は全体を通して、アクセス先がトレンドマイクロに送信されることを明確 に書いていない。「データベースを参照する」、「データベースに保存してあ るリストとURLなどを照合」*5、 「データベースに接続して評価情報を取得する」と書いてあるだけだ。 「評価情報とは,ドメイン名,IPアドレス(略)」とあるので、あたかもこれ らの情報を取得するだけであって送信するわけではないかのように読まれかね ない。辛うじて「ちなみに,同社のデータベースに送信したドメイン名などは」 という文から、「ああ、つまり送信しているわけね」と推察することはできる。 なぜはっきり明瞭に(たとえば次のように)書かないのか理解しかねる。

正しい記事の文例:

Webサーバーへのアクセス時に毎回アクセス先のURLをトレンドマイクロの データベースに送信して確認するというこれまでにない仕組みを導入した。

Webサイトアクセス時に,アクセスしようとしているサイトのURLをトレンドマ イクロのデータベースに送信し,データベースに保存してある信頼サイトの URLリスト(いわゆるホワイトリスト)に含まれるかを照合し,

ウイルスバスター2006はトレンドマイクロのデータベースに、アクセス先Web サイトのドメイン名など*6 を送信し、評価情報を取得する。

*1 訂正(4日22:04) タイトルの誤字を訂正(「虚」と書いていたものを 「嘘」に)した。(「虚偽の」と書き始めて「うそ」にしようとして文字を消 しただけだったため「虚」と誤字になった。)

*2 TCP接続による送信なのでそれはあり得ない。

*3 「弊社サーバへ送信される ことはありません」とあるので、「他社サーバへは送信される」という意味 の可能性はある。

*4 実際には、遅くとも数秒 以内に送信されている。送信の目的からして、迅速でないと使いものにならな くなる。

*5 URLを送信するのではなしに、データベース を参照してホワイトリスト取得してローカルで照合するという意味にも読める。

*6 実際にはURLの全部だったわけであるが。

本日のリンク元 TrackBack(1)

2005年12月05日

リダイレクタの存在は脆弱性か?

星澤さんの2日の日記 に出ていた件、ITmediaにも記事が出ており、次のように要点が書かれている。

このフィッシングメールは、571.94ドルの税金還付を受けるためにIRSのサイ トで手続きをするようにと受信者に伝えている。より本物らしく見せるため、 このメールはメール内のURLを直接クリックするのではなく、ブラウザのアド レスバーにコピー&ペーストするよう指示している。このURLは本物 の IRSサイトのドメイン名を使っているが、このサイトの設定ミスのために、 フィッシング詐欺犯が設置した偽のサイトにリダイレクトされてしまう。 (略)

「これは典型的なフィッシングよりも高度だ。URLが――最初は――本物のサイトにつながるからだ」とSophosのセキュリティコンサルタント、 グラハム・クルーリー氏は語る。


政府サイトの設定ミスを突いたフィッシング, ITmediaニュース, 2005年12月1日

この問題は、広く信頼されているドメイン名のサイト上に、「リダイレクタ」 (任意のURLへ自動ジャンプさせるCGIプログラム)が存在する場合、攻撃者が 被害者に見せるURLのドメイン名がその信頼されたドメイン名であっても、最 終的なアクセス先は、攻撃者が指定する任意のサイトとなってしまうというも のだ。たとえば、

http://example.go.jp/redirect?url=http://phisher.example.com/

というURLを見せられたときに、「go.jpのサイトだな」と信用してアクセスし ても、最終的に表示される画面は「phisher」のページとなるということだ。 (後ろの方の怪しげなURLは「%」エンコードでわかりにくくすることができる。)

問題を指摘したSophosは、これを「明らかなセキュリティ上の設定エラーが IRS の正規 Web サイト上にあり」と位置づけたとされて いるが、さて、これは本当に脆弱性として扱うべき(修正されるべき)ものだ ろうか。

まず、本当に「設定」で回避することができるのか。リダイレクタの大半は、 任意のサイトへのリダイレクトを目的としている。その場合、このような悪用 をされないようにするには、Refererをチェックするしかない。Refererが空の 場合は、機能しないようにする必要があるので、Refererの送出を止める設定 のブラウザを使用している閲覧者は、そのリダイレクタ経由でのリンクを使え なくなってしまう。

リダイレクタ自体が不要だということは、多くの場合に言えるかもしれない。 大して必要でもないのに、閲覧者のアクセス動向を探る(どのリンクをクリッ クして外部サイトにジャンプしたかの記録をとる)ために安易にリダイレクタ を設けているサイトも少なくないかもしれない。

だが、本当にリダイレクタが必要な場合はどうすればよいだろうか。

「リダイレクタの存在は脆弱性ではない」という見方もできる。

ちょうど先日、JNSAのフォーラムで「安全なWeb利用の鉄則」という講演をし てきた。これは以下にレポートされている。

この講演の要旨は、利用者の自衛手段となる「鉄則」を明確にし、利用者とサ イト運営者の責任分界点を明確にすることが必要であるとするものであるが、 その「鉄則」は簡潔でなければならず、過剰な手順を教えるのは誤りであると いうことを主張している。

結論として挙げた鉄則は以下である。(スパイウェアに感染していないことを 前提とした場合。)(Webブラウザに脆弱性がないことを前提とした場合。)

つまり、利用者の簡潔な鉄則は、情報を入力する直前で今見ている画面を確認 することである。

ジャンプ前にジャンプ先が信用できるサイトかどうかを確認する方法がダメな 理由は、情報の入力にSSLの使用を前提としている場合、最初に確認した信頼 できるサイトから入力画面に到達するまでに辿ったページに一つでもSSLを使 用していないページがあったなら、そこでパケット改竄されて、違うところへ 飛ばされている可能性があるので、ジャンプ前では確認にならないからだ。

SSLを使用しない場合であっても、複数のリンクを辿っていく場合、常に信用 できるところを辿っているか確認する意識を継続しないといけないのだから、 あまり現実的な方法ではない。

このような利用の鉄則が周知されていれば、リダイレクタがどこにあろうと問 題ではなくなる。

とはいえ、「利用者への周知など無理だ」という理由から、「無用なリダイレ クタは排除した方がよい」ということも言えるのだろう。しかし、そうすると、 すべての著名サイトはリダイレクタを設けてはならないということになってし まう。

選択肢は、次の二つ。

  • リダイレクタは脆弱性ではないと考え、利用者が入力時確認を徹底する。
  • すべてのリダイレクタの存在は脆弱性であるということにして、リダイ レクタを設けたいときは、信用性の低いドメイン名を使うか、数値形式のIPア ドレス(ホスト名でアクセスできない)を使った別サーバに設置する。

リダイレクタを撲滅させたいがために、リダイレクタ設置者の責任を追及する あまり、利用者の本来なすべき確認手順の周知をおろそかにするということが 起きがちだ。いずれにせよ、簡潔な利用の鉄則の周知を怠らないべきである。

ところで、携帯電話にはアドレスバーがないので、この鉄則は携帯電話のWeb ブラウザには適用できない。携帯電話では、ジャンプ前(メールからURLにジャ ンプするときや、QRコードで読み取ったURLにジャンプするとき)で確認する しかない。

ということは、アドレスバーのない携帯電話では、リダイレクタがあってはな らない(もしくは、リダイレクト時に携帯電話のブラウザが確認画面を出す必 要がある)ことになる。

と、書いてみたが、同じことは去年4月28日の日記に書いていた。


2005年12月06日

ウハ、三井住友銀行の素晴らしいセキュリティ教室

昨日の日記でリンクした「シンプルな安全確認ルールと……」の講演では、「本当に伝えるべきことを誰も伝え ていない」という趣旨のことを述べたのだったが、なんと、民間事業者が 既にそれを伝えていたことを知った。

すばらしい。ほぼ完璧の出来栄えだ*1。いつから公開されていたのだろう? 少なくとも10月31日には既にあったようだ。

ぼやぼやしているうちに仕事を一つ先に取られてしまった。

以下、ハイライトシーン。

そもそも「アドレスバーがない」なんて論外


簡単!やさしいセキュリティ教室, 三井住友銀行

うはは。

三井住友銀行では、このような画面によるログイン方法を提供しません


簡単!やさしいセキュリティ教室, 三井住友銀行

うひひ。

偽メールの例3

ただいまアクセス集中により、インターネットバンキングがご利用いただきに くい状態となっております。ご利用の際は、臨時で設置した下記のログイン URLからアクセスしてください。


簡単!やさしいセキュリティ教室, 三井住友銀行

うは。それ……。

(2)の警告は、その証明書がWebブラウザに登録されている「信頼出来る第三者」 機関から発行されていないことを示しています。つまり、その電子証明書は誰 もが作成できるため、極めて信頼性の低いものといえます。


簡単!やさしいセキュリティ教室, 三井住友銀行

ぐほほほ。

以下の設定を推薦します。

1. 「ActiveXコントロールに対して自動的にダイアログを表示」は「無効にす る」(※)
2. 「スクリプトを実行しても安全だとマークされてないActiveXコントロール」 は「無効にする」(重要)
3. 「署名済み ActiveXコントロールのダウンロード」は「ダイアログを表示 する」(重要)
4. 「未署名のActiveXコントロールのダウンロード」は「無効にする」(重要)


簡単!やさしいセキュリティ教室, 三井住友銀行

そうだそうだ。

3.を「ダイアログを表示する」に設定することで、「署名済みActiveXコント ロール(つまり、このプログラムは安全だよ!と誰かが主張しているプログラ ム)」を実行する前に、このような警告画面が表示されるようになります。

この時、「発行元」を確認して発行者が信頼できるかどうかを慎重に判断して ください(このプログラムが安全だよ!と主張する人が、信用できるかどうか を検討してください)。


簡単!やさしいセキュリティ教室, 三井住友銀行

だよねー。

※ ソフトウェアキーボードは、スパイウェアの完全な対策ではありません。
その他のタイプのスパイウェア(悪意のWebサイトへ誘導するタイプのスパイウェアや、新しいタイプのスパイウェアなど)対しては、有効な対策とならない場合があることに注意してください。

※ スパイウェアはインターネットバンキングの暗証番号を盗み取るだけでな く、パソコン上の全ての情報や操作が危険にさらされる可能性があります。対 策で第一に大切なのは、まず、「スパイウェアに侵入されないこと」です。

簡単!やさしいセキュリティ教室, 三井住友銀行

うはははははははははは。(つД`)ぐすん

よし、あとは拡張子だ!

*1 細かいツッコミどころはいくらか あったが、細かいので割愛。


2005年12月23日

日経バイト休刊最終号にウイルスバスター2006の件の訂正が掲載されたが……

3日の「日経バイトの誤報は訂正されるか」 の件、昨日発売された日経バイト2006月1月号で、「編集後記」のページ (p.128)に訂正文が掲載された。次のように書かれている。

●2005年12月号58ページ,3段目の16行目に「ちなみに,同社のデータベース に送信したドメイン名などは保存していないという」とトレンドマイクロの取 材に基づき記述しましたが,その後トレンドマイクロから「データベースに送 信されたURLの一部を保存している」と取材内容の訂正がありました。お詫び して訂正いたします。

編集後記――バグ・ログ――, 日経バイト2006年1月号, p.128

訂正はされたものの、結局、「スパイウェアとは何か」、「ユーザの挙動情報 を送信するソフトウェアに求められる責任は何か」といった記事が書かれるこ となく、日経バイトは休刊となってしまった。

ソニーBMGのrootkitまがい音楽CDの件や、マルウェアに該当するスパイウェア (パスワードを盗み出すものなど)の件が社会問題として騒がれている今こそ、 ビジネスとして「何をやってはいけないのか」の認識を深めるべく、そうした 記事が書かれるべきだった。

……と落胆していたところ、日経バイトのWebサイトにも訂正文が掲載されているのを見つけた。 日経バイト本誌とは別の記述が追加されている。

2005年12月号58ページ,3段目の16行目に「ちなみに,同社のデータベースに 送信したドメイン名などは保存していないという」とトレンドマイクロへの取 材に基づき記述しましたが,その後トレンドマイクロから「データベースに送 信されたURLの一部を保存している」と取材内容の訂正がありました。お詫び して訂正いたします。この仕組みはプライバシーにかかわり得る情報 を収集していることとなり,スパイウェアの一種だと見なされても仕方がない と結論づけざるを得ません。

日経バイト2005年12月号訂正, 日経バイト

記者の無念さが伝わってくるが、残念ながら読者に伝えるべきことはそこでは ない。

どんな情報を無断で送信することが一線を越えることになるのか、送信する場 合にユーザに説明するべき事項とは何か、説明が正確でなければならないこと、 スパイウェアはなぜスパイウェアと認定されているのか、収集目的が正当と確 信していれば何をやってもよいのか、一流の企業がなぜ説明を怠ってしまうの か――などを伝える必要があった。

日経バイトは休刊となったが、日経BP社なら必ずやってくれると思う。

アンチウイルスベンダが消費者のリテラシー向上を期待しないという構図

昔から、「ウイルス対策会社は本当はウイルスが蔓延して喜んでいるのではな いか?」とか、「ウイルスを撒いているのは実はウイルス対策会社じゃないの か?」などという声をよく耳にしたものだが、それは下衆の勘繰りだろう。そ のような言葉を発する人はたいてい、品のない表情をしている。

最近ではそのような声を聞くことが少なくなった。現実として、ウイルスは蔓 延し、スパイウェアによる実害も続出し、アンチウイルスは、社会にとってセー フティネットとして欠かせないソフトウェアとして認識されるようになった。

そうした認識が形成される前の、2000年から2001年ごろを思い返すと、セキュ リティ関係者は、ウイルス対策ソフトを普及させることに躍起(あるいはそれ で精一杯)になっていた。新しいウイルスが現れて騒動になると、それを伝え るマスコミ報道に登場する「専門家」は、「ウイルス対策ソフトを入れること」 「ウイルス対策ソフトを最新のものにすること」とコメントしていたものだ。

本当は、真に必要な対策は脆弱性パッチを適用する体制を整えることであるに もかかわらず、当時、それを伝える大手マスコミは皆無に近い状態だった。 2000年の省庁Webサイト改竄事件のときでも、「ファイアウォールを導入して いなかったのが原因」などと報道されるだけだった。当時の私は、「どうして 脆弱性のことを報道しないのか」と苛立ったものだ。

それが、2001年3月のNHKニュース(おはよう日本)で、ついに「ソフトウェア の欠陥」という表現が使われるようになった。当時としては画期的な報道だっ た。

千葉県にある職業訓練施設でも、今月4日にホームページが書き換えられ、修 復に2週間以上かかりました。 侵入を防ぐためのソフトを導入するなど、必要な対策はとっていたと思ってい ました。

「本当にまさかうちがというような感じでございます。対策立ててるのに、 またなんでやられたのかなという、本当にショックでしたね。」(雇用・能力 開発機構 情報システム課長談)

(略)

「今回の一連の事件の背景には、プログラムの欠陥というものがあります。 専門用語ではセキュリティホールと呼んでいますけども、こういうセキュリティ ホールが数多くあって、それらが放置されているコンピュータが世の中にある と。これが狙われたということです。」 (情報処理振興事業協会 セキュリティセンター所長談)

(略)

ホームページで情報を公開する企業や団体は、ソフトの欠陥にすばやく対応す ることが求められています。

おはよう日本, NHK, 2001年3月22日

消費者側の脆弱性パッチの話が大手メディアに登場したのは、Nimdaワームが 登場した2001年9月以後のことだった。

ところがこのソフトウェアには、利用者が確認をしないのに、一部のプログラ ムを勝手に取り込んでしまう欠陥がありました。Nimdaはこの欠陥を利用し、 利用者が知らないうちにパソコンがウイルスに感染するように作られていたの です。

(略)

メーカーは今もソフトウェアの欠陥を公表し、利用者に対応方法を紹介してい ます。

(略)

世界中で広がったNimdaの被害は、コンピュータウイルスへの新たな対応が必 要なことを示しています。

「メーカーでは、ソフトウェアの欠陥について、その内容あるいは対応のし方 というのを利用者に知らせる対策をとっているんです。その対策、ちょっ と難しい中身なんですけども、いずれにしても、利用する私達の側もですね、 こうした情報に常に関心を持つことが必要なようです。」 (キャスター談)

ニュース10, NHK, 2001年10月25日

これも当時としては画期的な報道だった。

そして現在、残された課題は、スパイウェア(あるいは「マルウェア」、つま り悪意あるプログラム)対策と、フィッシング対策である。 フィッシング対策は、ユーザのリテラシ向上が事の本質だが、またもやマスコ ミは肝心なことを伝えない。 これについては、2月11の日記「フィッシング 報道に見るテレビによる啓発の限界」に書いた。 そして、マルウェア対策。これは、拡張子を正しく見分けるリテラシを身につ けることが問題解決の本質であるが、これもなかなか伝えられない。 これについては、Network Security Forum 2005での講演で話した。

アンチウイルス(スパイ)ソフトを買うのもけっこうだけども、それで問題が 解決するかのように言いふらすのは、詐欺だろう。

その点、これまでの大手アンチウイルスベンダーは、きちんと言うべきことを 言っていた。

にもかかわらず、MSBlastは急速な拡大を見せた。

この原因を星澤氏は、大きく2つに分けて指摘している。1つは、各クライアン トでの対策も含んだトータルなセキュリティ対策の欠如だ。

(略)

もう1つ星澤氏が指摘したのは、ユーザーのセキュリティ意識である。セキュ リティの維持には、関連情報に気を配り、適宜パッチを適用するという継続的 な作業が不可欠だ。これはWindowsであろうと他のOSであろうとまったく同じ ことである。

しかし残念ながら、「セキュリティホールを修正するためのパッチを 当てていなかったのがMSBlast拡大の一番の要因」(同氏)。逆に言 えば、問題が公表されればそのつどパッチを適用し、ウイルス対策ソフトウェ アの更新も行っていれば、MSBlastに感染してあたふたすることもなかった。 MSBlastは多少痛い教訓ではあるが、「これを機会に(パッチの適用 を含めた)セキュリティ意識が浸透するよう期待したい」と星澤氏 は述べている。

沈静化へ向かうMSBlastがあぶりだしたユーザーのセキュリティ意識, ITmedia, 2003年8月18日

アンチウイルスベンダーの立場からしてみれば、消費者には脆弱性のことなぞ 知らないままでいてくれた方が、製品を売り込みやすいという構造があるはず だ。ともすれば、「製品が防ぎますので、煩わしい脆弱性パッチは気にせずに 済みます」という宣伝に走りかねない。にもかかわらず、上の記事のように、 これまでの例ではきちんと、アンチウイルスソフトに限界があることを示しつ つ、一番の対策は脆弱性パッチをあてることだと、アンチウイルスベンダーの 専門家も言葉を添えるようにしてきていた。これは、セキュリティ対策という ものをビジネスにする上で、企業としての品性を失わないための最低限のマナー であろう。

ところがである。先日のInternet Week 2005の中で開催されたJNSA主催の 「Security Day」のパネル討論「【徹底討論】ボットネット対策 ボットネットの脅威 − 動向、対策を考える」 を見に行ったところ、エゲツない営業トークを耳にした。

討論で、ボットに知らずに感染し続けている消費者がいっぱいいるが、どうし たらよいだろうかという議論の流れで、議論が行き詰まりかけたとき、アンチ ウイルスベンダーを代表して登壇していた方が、正確な表現は覚えていないが、 次のような趣旨の発言をしていた。

「リテラシーを高めるのが無理な方々がいらっしゃる。そこを弊社のサービス がお役に立てればと考えている。あ、宣伝になっちゃいましたか?」 (高木の記憶により再現した発言の要約)

元々、初期のアンチウイルスソフトというのは、ユーザがいくら気をつけてい ても防げないタイプのウイルス感染を検疫するものだった。他人から預かった MS-DOSのフロッピーディスクを入れると、そこに入っているCOMMAND.COMが起 動して、それがウイルス感染しているとか、まさに、生命体における伝染病の ように已む無く感染を広げていくものだった。昔のMicrosoft Officeのファイ ルは、開くとプログラム(マクロ)が動くものだったため、仕事で同僚や顧客 が送ってくるOfficeのファイルを開かざるを得ないときには、アンチウイルス による検疫が必須だった。

だが、最近の状況は異なっている。Microsoft Officeもデフォルトではマクロ が自動で動かないようになり、そういった理由で検疫する必然性は縮小した。 今、アンチウイルスがやっていることは、脆弱性を突いて起動するものや、ユー ザの無理解ないし誤操作によって起動してしまうマルウェアを、阻止すること である。これは昔と違って本質的に必要なことではない。脆弱性をなくし、プ ログラムを含み得る拡張子のファイルを起動しないようユーザが理解すること で、解決が可能なことなのだ。

だから、今第一に行うべきことは、ユーザへのリテラシ教育に他ならない。 「無理です」と言ってみせるのは簡単だが、やれることはあるだろう。

それを差し置いて、あたかも対策ソフトを買うことで問題が解決するかのよう なことを言うのはエゲツない。かつての愉快犯によるバルク型ウイルスと違っ て、特定の少数ユーザだけを狙った金銭目的の攻撃が問題となっているのに、 それをソフトウェアで防げるわけがない*1

もちろん、社会的に、スパイウェア対策ソフトは普及した方がよいに違いない。 だが、その限界を明らかにした上で販売しなくてはならない。被害者の立場か らすれば、たった一回の「新種」マルウェアにひっかかっただけで、何百万円 という損害が出るのであり、対策ソフトは「確率的」な防止でしかないことを 伝えなくてはならない。

無題2

2日の日記にひき続き、トラックバックが できない様子なので、こちらからリンクして差し上げる。

セキュリティベンダーやセキュリティ専門家は、一般大衆のセキュリティ意識を高めるために様々な啓蒙活動を行なっている。

しかし、それが原因で、一般ユーザーを 「教育」する意識ばかり肥大化し、相手を 「見下す」ことに繋がっていないだろうか?

一種の優越意識である。

本当にユーザーの立ち場に立つなら、もっと本質を重視するはずだ。あんな態度は取らないはずだ。

私が星澤裕二氏や高木浩光氏の姿勢を追及する過程で見たものは、まさにその部分なのだ。ユーザーを馬鹿にしてるとしか思えない姿勢や表現が大量にあるのだ。

だが、彼ら自身はその事実に気付いていないだろう。

一般ユーザーの視点を見失っているのだから・・・。

「大量にある」そうだが、具体的にどれのことを言っているのか示して書いて くれないだろうか。

根拠を示さずに風説だけを流布する行為は正当な批評にあたらない。論拠を示 さずに書くと名誉毀損ととられる危険性が高まってしまうので注意したい。

*1 パターンマッチングで防げる わけがないし、スパイウェアはキーロガーのようなデータ送信型だけではない ので、外向きのポートを塞いでも解決にならない。フィッシングも、ごく少数 をターゲットとして攻撃が行われている場合、表沙汰になることもない。


2005年12月24日

Phishing対策ツールバーなんていらない! 元々あるIEの機能を使う

安全なWebサイト利用の手順

の講演で述べた「シンプルな安全確認ルール(手順)」というのがどういうも のかというと、まず、次の2つの状況によって手順を分ける。

  • 初めて訪れたサイトを利用しようとするとき
  • 既に何度か使ったことのあるサイトを利用しようとするとき

初めて訪れたサイトでは、サーバ証明書の内容を読んで、書かれている会社名 や住所が、自分が今使おうと想定している相手なのかどうかを確認し、間違い なければ利用を開始し、次回に備えてそのドメイン名を暗記しておく――(A)。

既に使ったことのあるサイトに訪れたつもり(偽サイトかもしれない状況で) のときは、アドレスバーに表示されたドメイン名を見て、記憶しているものと 同じかを確認し、重要な情報を入力するときは、錠前アイコンの存在を見て、 SSLが使用されているかを確認する――(B)。

この手順は、Web黎明期から変わることなく暗に求められてきた、利用者の基 本リテラシである。

特に(B)の手順は、先日話題にした三井住友銀 行のセキュリティ教室に書かれている通り(そこではsmbc.co.jpに特化 して書かれているが、上の手順はそれを一般化したもの)であり、(B)に補足 すべき「ポップアップウィンドウを信用しない」といった事項は、三井住友銀 行のセキュリティ教室に書かれている。

手順の困難さ

とはいえ、こうした手順を踏むことに困難さがあったため、phishingの被害が 拡大したのだろう。その困難さとは次のものと考えられる。

まず難しいのは、(B)の手順において、

  1. アドレスバーに表示されたURLからドメイン名部分を正しく抽出すること
  2. ドメイン名のアルファベット文字を間違いなく読み取ること
  3. 記憶しているドメイン名と一致するかを間違いなく判断すること

であろう*1。1.については、

先頭から順に見て「//」より後ろに現れる最初の「/」より前の部分のうち 最後の部分

という文法を知っていないといけないし、2.は、「l」と「1」を判別できるか という問題で、現在も残る困難性である。3.は、「example.com」 「example.net」「example.co.jp」「example.jp」のどれだったか覚えていら れないという困難性である。

この困難性ゆえに騙されてしまうケースを救うためにしばしば呼びかけられる 注意喚起として、「必ずブックマークからアクセスしてください」というもの があるが、昨年12月5日の日記に書いたイー バンク銀行の送金通知メールのように、ブックマークからでは利用できない利 用形態があるのであって、だからこそphishing被害が止まらないのだから、そ のような注意には実効性がなく、それは単に「いちおう注意喚起はしましたの で」というアリバイ作りにしかなっていない。

そこで登場したのがいくつかのphishing対策ツールバーであろう。たとえば、 「PhishWall」の仕組みを見てみる。

PhishWallデモページ」に書かれている説明によると、 PhishWallツールバーをブラウザにインストールしておくと、PhishWall対応サー バに初めて接続したとき、ツールバーに黄色の「●●●」マークが表示され、 「このWebサイトと信頼関係を結ぶためには登録作業を行ってください」とい うダイアログウィンドウが現れる。ここで「登録する」ボタンを押すと、次回 以降も含めて、そのサイトに訪れると「●●●」マークが緑色で表示されると いう。

つまり、PhishWallのこの仕組みは、前述の(B)の手順を機械化して、1.〜3.の 困難性を排除するものと言える。

元からある機能で困難を克服

だが、そんな機能はいらない。元々あるInternet Explorerの機能を使えば同 じことができるのだ。

それは、「信頼済みサイトゾーン」(図1)を活用することである。

図1: IEの「信頼済みサイトゾーン」

まず、初めてサイトを訪れたとき、利用者は前述(A)の手順にしたがって、そ のサイトを今後を含めて使うかどうか判断する。今後も使うと決めたとき、 「次回に備えてドメイン名を暗記しておく」の替わりに、次の操作をする。

図1の「サイト」ボタンを押し、信頼済みサイトゾーンに現在表示中のサイト を追加する(図2)。

図2: 信頼済みサイトゾーンに追加する

このようにしておけば、次回以降このサイトを利用する際、必要な(B)の手順 は、ステータスバーを見るだけで済むことになる。つまり、図3のように、ス テータスバーに緑色のマークと「信頼済みサイト」という表示が現れるのを 確認する。

図3: ステータスバーに表示される信頼済みマーク

これで、(B)の1.〜3.の困難は克服できる。


注意: 信頼済みサイトゾーンにサイトを登録する場合、必ず、信頼済みサイト ゾーンのセキュリティレベルを「中」以上にすること。また、インターネット ゾーンでユーザ独自に無効に設定している機能は、信頼済みサイトゾーンでも 無効に設定した方がよい。設定の注意点については「やってはいけないセキュリティ設定指示 Top 15 (Windows XP SP2編)」を参照。


次に、この記事に図解されているように、PhishWallのシステムは、他のいくつかの類似ツール バーと違って*2、サーバ側にも専用ソフトを 設置して公開鍵暗号を使い、サーバが偽でないことの確認を安全なものにして いる(通信路上でのパケット改竄などによる攻撃を防止している)ようである が、これも、Internet Explorerが元々持っている機能でほぼ同等のことを実 現できる。

つまり、図4のように、信頼済みサイトゾーンの登録サイト設定で、「このゾー ンのサイトにはすべてサーバの確認(https:)を必要とする」のチェックをオン にしておくことが、それに相当する。

図4: 信頼済みサイトゾーンにおけるhttps:の扱い

日本語版のWindowsではここが「確認を必要とする」と曖昧な表現になってい るが、英語版Windowsでは、「Require server verification (https:) for all sites in this zone」と書かれており、「server verification」とは、 サーバ証明書のPKIとしての検証処理のことを指すのだろう。

ここがチェックされている場合、信頼済みサイトゾーンには https:// のペー ジしか登録できなくなり、https:// のページに正常にアクセス*3したときだけ、信頼済みサイトゾーンの緑マークが表示される。

このように、PhishWallがやっている鍵の検証は、従来からWindowsが備えてい たWebブラウザ用PKIによって、同じように検証できるのである。

初めて訪れたサイトの信用をどう確認するか

そうすると、PhishWallの存在意義は何だろうか。

(B)の手順の困難さを解決するものとしての意義はほとんどない。

強いて挙げるならば、信頼済みサイトゾーンへの登録は手作業で行わなければ ならないところが、ボタンひとつでできるようになることと、もうひとつは、 認証局の信頼性の影響*4であろう。

有意な違いは、サイトを初めて訪れたときの効用にある。

ツールバーがないときは、(A)の手順で、サイトが自分の意図したところかど うか調べることになるが、ここで、正規のサーバ証明書があるからといって、 信用できるサイトだということにはならない。なぜなら、Web用サーバ証明書 を発行する認証局は、基本的には、発行先の組織の社会的信頼について確認し ないからだ。

ただ、一部の認証局が、組織の社会的信頼も評価して、一定以上の水準の組織 に対してだけ、証明書を発行するサービスを提供することはあり得る。この場 合、そのことを知ったうえ、そのサービスにより発行された証明書であること を示す記述がサーバ証明書に書かれているのを読んで、ユーザが確認すること になる。

しかし現実問題として、詐欺師たちがそれらしい名前のペーパー会社を作って、 正規の実在証明付き証明書を手に入れて、偽サイトを立ち上げる可能性は否定 できない。それをどうやって防止できるだろうか。SSLを公平に誰でも使える ようにと敷居を下げれば詐欺師に悪用され、詐欺師に悪用されないようにと敷 居を高くすれば、誰もSSLを使わなくなりオレオレ証明書が蔓延してしまう。

PhishWallは言わば、極めて限定した相手にしか販売しない認証局のような働 きをしている。

今の段階はそういう仕組みも成り立ち得る。銀行とクレジットカード会社だけ に販売しているうちは、売るか売らないかの判断を客観的に行うことができる。 だが、将来こうしたシステムが普及していって、我も我もとPhishWallサーバ を買いたいと言い出したらどうなるだろうか。「お前には売らない」という判 断基準を、どうやって設けるかという問題に直面することになる。

客観的基準がなくても自動的にそれを決定できるメカニズムがある。それは、 価格だ。ライセンス料が、数百万円から数千万円に設定されていれば、詐欺師 達はそれを買いに来ないだろう。詐欺師達は、詐欺行為によって得られる不正 利益の期待値と、詐欺行為にかかる費用を天秤にかけて、見合う手段でしか詐 欺をはたらかない。

そうすると、専用のサーバシステムを販売しなくても、単に高額な登録ライセ ンス料を受け取るだけのサービスを始めることで、同等のphishing対策ビジネ スを展開できるのではないかと思えてくる。このとき、技術的には既存のSSL のサーバ証明書を使えばよい。高額料金の支払い能力によって「認証」済みの サイトの、証明書リストを提供するサーバを用意しておき、それをダウンロー ドして照合するだけのツールバーを配ればいい。正規サイトの管理者が行う手 順は、(1)普通の認証局から数万円でSSLのサーバ証明書を買ってSSLサーバを セットアップし、(2)phishing対策ビジネス会社に1千万円払って自分のサイト の証明書を登録してもらう――と、これだけだ。

だが、技術的にも管理的にも何もやっていないに等しい(ツールバーは開発し て配っているにしても。サーバも準備しているにしても)単なる登録業務の会 社に、1千万円払うということに納得できる管理者はいないかもしれない。セ キュリティモデルとしては正しいが、釈然としない。せめて、技術的に意味が あるかのような専用システムを買わないと納得できないのではなかろうか。

公式サイトの垣根で奪われる自由

もうひとつの道は、高額料金で「認証」するのではなしに、主観的基準によっ て、販売先を選ぶという方向性である。これは、携帯電話会社の「公式サイト」 のモデルに似ている。しかしそれは、「インターネット的」でない代物だ。

インターネットが旧来の電話会社がやってきたことと根本的に異なっていたの は、常に自由と平等が尊重され、独占を避けるよう技術が設計されてきたこと だ。だからこそこれまでのような発展があったはずだ。

WebブラウザにSSLが初めて搭載されたときにも、ブラウザ製造者が自ら認証局 ビジネスも展開するなどということはしなかった。規格をオープンにして、広 く認証ビジネスに参入できるようにした*5

携帯電話上のサービスは所詮、電話会社の恣意的なコントロールの下に置かれ たものであり、自由がない代わりに一定の安全が安易に得られている。

インターネットを電話のようにしてしまえという発想をする人もいる。通信路 だけでなく、ユーザ認証やコンテンツまで通信会社がコントロールすることで、 「インターネットの危険をなくせ」という発想だ。自由を削がれたそれは、も うインターネットとは似て非なるものである。

このまま、phishing対策を大義名分として、特定の著名事業者を恣意的に優遇 する仕掛けが広範囲にわたって導入される(パソコンにそれがプリインストー ルされて出荷されるなど)ようになると、やがて人々はそれを拠り所とするよ うになり、それなしにはネットを利用しないようになり、インターネットの自 由(インターネットで(他と平等に)サービスを提供する自由)は事実上消滅 することになるかもしれない。

そんなはずではなかった。Webを安全に利用できるための仕掛けは、初めから 組み込まれていたのだ。(A)の手順で確認し、(B)の手順で確認する。それを単 に知らされていない人達がたくさん使い始めたという理由で、このまま電話世 界へと堕ちていってしまうのか。

リテラシー向上では無理なのか

安全な利用の手順が一般の人には覚えられないなんていうのは嘘っぱちだ。 「覚えられない」なんて言う人は、必要でない確認方法を挙げて「そんなのは 無理だ」と言っている*6三井住友銀行のセキュリティ教室に示されている単純な心得だけで、 安全に利用できるよう、Webサイトの方が構成されているべきなのだ。

もっとも、現にそうなっていないWebサイトがある(11月30日の日記参照)わけで、そうしたサイトで、「製品を買うだけで安全対 策ができる」というところが、phishing対策製品のひとつの売りなのだろう。 だが、そういう製品に毎年ライセンス料を支払うのと、画面構成を一回改修す るコストとどちらが大きいのか検討しているだろうか*7

それでもなお、対策製品の意義はある。

ひとつは、何らかの理由で古いWindowsを使っている人達を助けることだ。ア ドレスバーにウィンドウを被せてURLを偽装する手口は、Windows XP SP2での 修正で対策されたが、Windows Meをまだ使っている人にはどうすることもでき ない。これは、まだしばらく、皆でコストを負担していかないといけないのだ ろうか。

もうひとつは、対策製品を消費者のパソコンにインストールすると、安全確認 の方法を自然に教えてくれるようになるという点だ。phishing対策ツールバー を導入しても、そのツールバーの見方を知らなければ安全にならないわけで、 ユーザはそれを学ぶのだろう。お金を出して買っただけに、その機能を勉強す ることになる。だが、それは、元々あるブラウザの安全な使い方を学ぶのとど う違うのか。

パソコンを買っても、Windowsを買っても、その「安全な使い方」はマニュア ルに書いてない。学校でインターネットの使い方を教わっても、「安全な使い 方」は教えてくれない。そこが誤りの根源ではないか。

*1 他にも、アドレスバーを偽装されるとか、「%」エンコード やパスワード部分を使って混乱させられるといった攻撃が一時期流行ったが、 現在ではブラウザ側で対策がとられているか、サイト側でポップアップウィン ドウを使うのをやめるという方向で解決が図られているところなので、これら のケースは除く。それでもなお残る利用手順の困難性について、ここでは述べ ている。

*2 他の類似機能を持つツールバーのいくつかは、 本物サイトかどうかの情報をツールバー製造元のサーバに問い合わせる(ない しそこからダウンロードする)方式を採用しているが、その問い合わせ(ない しダウンロード)を適切に暗号処理していない場合、通信路上でのパケット改 竄によって、偽サイトに接続しようとしているのに本物サイトだとの偽応答に すり替えられる危険性があると考えられる。

*3 オレ オレ証明書の警告が出たときは「いいえ」を押してアクセスを回避しなくては ならない。

*4 (B)を信頼済みサイトゾーンのマークで確認す るときに、それを偽サイトに偽装される可能性があるとしたら、サーバ証明書 の秘密鍵が流出する場合と、認証局が誤って、phishing犯に本物サイトドメイ ン用の証明書を渡してしまう場合である。サーバ証明書の秘密鍵の流出リスク は、PhishWallサーバでも同様にあるように見受けられる。つまり、Windowsに 多数登録されているサーバ証明書発行認証局のどれかひとつが事故を起こす確 率を、どう見積もるかである。PhishWallの場合では、PhishWall販売店が誤っ てphishingサイトの鍵を鍵サーバに登録してしまう事故が、それに相当するだ ろう。どちらの事故確率が低いと見積もるかだ。

*5 といっても、安全基準を満た した事業者しか、ルート認証局に登録するわけにはいかないわけだが。

*6 冒頭で挙げた講演をレポートしたINTENET Watchの記事に、

高木氏は、利用者に対して不要な対策を要求している例もあるとして、DNSキャッシュポイズニングに関して書かれた記事を取り上げた。

という記述があるが、これは、日経IT Proの以下の記事のことを指して発言し たものである。

ユーザーができるDNSキャッシュ・ポイズニング対策はあるだろうか。SANSが 公表した事例のように,全く異なるサイトへリダイレクトされればユーザーも 異常に気付くだろう。だが,本物そっくりの偽サイトへリダイレクトされた場 合には「気が付きにくいだろう」(JPCERT/CCの山賀氏)。「極論すれば, 『HTTPのページは信用しない。HTTPS(SSL)のページでは,ページご とにデジタル証明書を開いて確認する』ということが,ユーザーの対策となる。 だが,これらは理想論。ユーザーに実施させるのは不可能だ」(同氏)。

勝村 幸博, 「悪質サイトへ勝手にリダイレクト」---DNSキャッシュ・ポイズニング攻撃の現状と対策(下), 日経IT Pro, 記者の眼, 2005年4月13日

これは大間違いで、INTERNET Watchの記事にレポートされている通り、

「デジタル証明書は、PKIの仕組みにより自動的に本物であるか偽者であるか を確認できるところにミソがあるのであって、目で確認するものではない。そ れよりも、(デジタル証明書の異常を示す)警告が出るか出ないだけで判断す ればよいこと」と指摘した。

ということだ。目で確認する(「実在証明」の利用をする)必然性があるのは、 初めてサイトを利用するときだけである。

*7 この記事によると、この製品の場合ライセンス料は、ユーザ一人当たり年間 600円にもなるという。これは見えない形で消費者の負担として跳ね返ってく るのだろう。ツールを利用しない人達にまで。


2005年12月25日

青梗菜炒めが美味い

失敗なく美味くできるのでマイブーム中。

図: 青梗菜炒めと生姜焼きと味噌汁とご飯

2005年12月27日

プログラミング解説書籍の脆弱性をどうするか

印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。

ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。

久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。

「PHP実践のツボ」は「セキュアプログラミング編」と謳っているわりに、いきなり最初のサンプルコードからしてクロスサイトスクリプティング脆弱性がある。――(A)

<?php
$strdate = $_GET['strdate'];
echo <<<EOD
日時文字列を入力してください。
<form>
<input type="text" name="strdate" value="{$strdate}">
<input type="submit" value="OK">
</form>
EOD;
if (!$strdate) {

(以下略)

山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.3

動かしてみると図1のように脆弱性が確認できる。

図1: 「PHP実践のツボ」の最初のサンプルコードが脆弱である様子*1

p.158にはこんな解説がある。――(B)

危険な文字列は削除する

この問題に対しては、変数 $filename の中に上位ディレクトリを示す「../」という文字列があった場合、適切に変換するしかありません。

1つは上位ディレクトリ指定の文字列を削除する方法です。

$filename = $_GET["filename"];
// 上位ディレクトリ指定を削除
$filename = str_replace("../", "", $filename);

山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.158

これは典型的によくあるまずい対策だ。

$filename = "----..././----";
$filename = str_replace("../", "", $filename);
echo $filename;

の実行結果は「----../----」と表示される。

そしてp.213にはこの記述ときた。

商用サイトなどでSSLを使用する場合は、一般的に認証局(Certificate Authority:CA)で発行された証明書を使用します。

非商用サイトなどで単に暗号化の目的だけならプライベートCAで発行した証明書でも問題ありません。ただし、プライベートCAで発行した証明書を使用する場合、SSLでの接続時にブラウザから警告メッセージが表示されます(図5)。

山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.213

こういう記述が誤解を拡大再生産してきたのだろう。今の時代に、焚書というわけにもいかないか……。

「サニタイズ言うなキャンペーン」とは何か

もう一冊のPHPサイバーテロの技法―攻撃と防御の実際はどうかというと、抜け目なく書こうとする配慮が見られ、たしかにわりとよく書かれた*2本である。

しかし、安全なプログラミング手法という視点ではなく、あくまでセキュリティ対策だという視点で書かれているところに問題が残る。

たとえば、p.28のクロスサイトスクリプティング脆弱性の対策コードを見てみる。――(C)

ここを以下のように修正します。

while ( $row = mysql_fetch_array( $result , MYSQL_ASSOC ) ) {
    echo '<p>' ;
    echo 'No.'.$row['id'].'<br />' ;
    echo '題名:'.htmlspecialchars($row['title'],ENT_QUOTES).'<br />' ;
    echo '名前:'.htmlspecialchars($row['name'],ENT_QUOTES).'<br />' ;
    echo '日時:'.$row['postdate'].'<br />' ;

(略)

ソースコードの違いは一目瞭然だと思います。過去の投稿内容の各テキストが、ブラウザに表示される直前*04に、htmlspecialchars((テキスト),ENT_QUOTES)を通過しています。これが「HTML出力用サニタイズ」です

GIJOE, PHPサイバーテロの技法―攻撃と防御の実際, ソシム, p.29

これのどこが悪いかというと、「id」と「postdate」について htmlspecialchars を通していない点である。

たしかにこれは脆弱性ではない。プログラムの全体を精査すれば、「$row['id']」の値が数値しかとらないことを確認できるだろうし、「$row['postdate']」の値が日付を表す文字列しかとらず、HTTPリクエストの値(CGI入力)に依存していない式だとということも確認できるのだろう。

だが、そのような確認作業をしないと正しいコードかどうかわからないような、プログラムの書き方をすべきでない。セキュリティ云々以前に、プログラムの開発方法論として、できるだけ局所的な視点でコードの正当性を確認できるように書くのが、近代プログラミングの基本だ。つまり、このコード断片だけ見て、問題がないとわかるように書くべきである。例えば次のように。――(D)

while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
    echo '<p>';
    echo htmlspecialchars('No.' . $row['id']).'<br />';
    echo htmlspecialchars('題名:' . $row['title']).'<br />';
    echo htmlspecialchars('名前:' . $row['name']).'<br />';
    echo htmlspecialchars('日時:' . $row['postdate']).'<br />';

ここで、「'No.' や '題名:' や '名前:' や '日時:' の定数文字列まで htmlspecialchars に通すなんて無駄じゃないか」などということを考えてはいけない。いまどき、そんな貧民的プログラミング思考をするのはプログラム職人として恥ずかしいことだ。

元々、HTMLを出力するときは、その出力全体に対して「<」「>」「&」のエスケープ処理の検討が要求されているのであって、CGI入力に依存しているかどうかは無関係である。そこの考え方に「無毒化」だの「無害化」だの「消毒」だの「サニタイズ」だの「サニタイジング」だのという(最近流行の)発想は出てこない。

HTML出力を書くときは、むしろタグを出力したいときの方が例外的であると考えるのがよい。たとえば、echo を全面的に使用禁止として次のように書くのもよいだろう。――(E)

while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
    htmlout_tag('<p>');
    htmlout('No.' . $row["id"]);
    htmlout_tag('<br />');
    htmlout('題名:' . $row["title"]);
    htmlout_tag('<br />');
    htmlout('名前:' . $row["name"]);
    htmlout_tag('<br />');
    htmlout('日時:' . $row["postdate"]);
    htmlout_tag('<br />');

タグの属性部分を出力するときは次のように書く。

    htmlout('日時文字列を入力してください。');
    htmlout_tag('<form>');
    htmlout_tag('<input type="text" name="strdate" value=');
    htmlout_quote($strdate);
    htmlout_tag('>');

使用した関数の定義はたとえばこんな感じだ*3

function htmlout($str) {
    echo htmlspecialchars($str, ENT_NOQUOTES);
}
function htmlout_quote($str) {
    echo '"' . htmlspecialchars($str) . '"';
}
function htmlout_tag($str) {
    echo $str;
}

広義のクロスサイトスクリプティング脆弱性、つまり、掲示板へのタグ付き文字列の書き込みの問題が語られるとき、「HTTP_USER_AGENT もサニタイズしないといけないんだよ」ということがよく言われる。上のサンプルコードに User-Agent も加えるとき、

    echo 'No.'.$row['id'].'<br />' ;
    echo '題名:'.htmlspecialchars($row['title'],ENT_QUOTES).'<br />' ;
    echo '名前:'.htmlspecialchars($row['name'],ENT_QUOTES).'<br />' ;
    echo '日時:'.$row['postdate'].'<br />' ;
    echo 'ブラウザ:'.$row['useragent'].'<br />' ;

というコードを書きがちであるわけだが、それを見て、「$row['user_agent'] もサニタイズしないといけないんだよ」ということになる。対策マニアからすれば、

HTTP_USER_AGENTってのはね、攻撃者側でブラウザをいじって勝手に変えられるんだよー。ツールとか使ってね。HTTP_REFERERも偽装できるんだ。だから、User-Agent: とか Referer: とか、あと、X-Forwarded-For: や Via: に由来する変数もサニタイズしないといけないんだよー。

と、ハッカー気取りで語ってみせる大チャンスであるわけだが、そんなことはどうでもいい。(E)の書き方(D)の書き方(つまり、タグ以外は一律に全部エスケープして出力する書き方)をしていれば、そんなことはどうでもよいのだ*4

ではなぜ、解説書でさえ(C)のようなコードを書いてしまうのか。3つ考えられる。1つ目は、貧民的プログラミングの発想。2つ目は、煩雑な見栄えを嫌がってということがあるだろう。

まず、「htmlspecialchars」という名前が長い。これをあちこちに埋め込まないといけない。文字列連結している文の部分部分に htmlspecialchars を入れて、入れて、入れていかないといけない。これが嫌で嫌で堪らないプログラマが、それでも「セキュリティ対策しないと……」ということで仕方なく必死に作業していくと、必要最小限の場所にだけ htmlspecialchars と書くことになりがちだ。

その結果として何が起きるかというと、いわゆる「サニタイズ漏れ」だ。それを目を皿にして探していく作業も、たいへんなコストがかかることになる。

上に挙げた(A)の事例について、こうした脆弱性を指摘された本の著者はこう反論するかもしれない。「PHPの入門書なので、まずは PHPによる HTML formの基本的な書き方を説明したいだけ。最初からそこらじゅうに htmlspecialchars と散りばめたのでは、読者がついてこなくなってしまう。セキュリティ対策の方法は後半で書いているのだから、これでよいのだ……」と。

事実、2002年に、ある@ITの解説記事の脆弱性を指摘したとき、関係者の方から

記事の主旨はサーバサイドアプリケーションの諸環境の紹介を第一としておりますことご了解いただけますと幸いです

という釈明を受けたことがある。また同じころ、知人が書いていた書籍について、出版前に読んで欲しいと依頼されて読ませてもらったところ、やはり、SQLの使い方を紹介する章のサンプルコードがモロにSQLインジェクション脆弱性のある安易な書き方になっていて、「こういう書き方、やめようよ」と言ったことがあるのだが、著者は、「ここはSQLの使い方をわかってもらうためだから余分なコードは入れたくない」と主張して、全面的な書き直しはしなかった(注意書きが添えられ、後ろの章にセキュリティ対策の章が付け加えることで対処された)ということがあった。

このように、コードの見た目が煩雑になることがプログラマ達に嫌われていて、特に解説本の著者がひどく嫌っていることがわかるが、それが脆弱プログラマを増殖させる原因となっている。

そして3つ目の原因が、「サニタイズ」という言葉が安易に流行りすぎていることの弊害である。

「サニタイズ」というのは、「無害化」という意味の言葉であることから明らかなように、あくまでも「セキュリティ対策」としての文脈でしか語られない。そうすると、「CGI入力の(に依存した)変数はサニタイズせよ」というスローガンになってしまう。これが悪しきプログラミングスタイルを助長して困る。

正しくは全ての変数をエスケープ対象とせよが基本であるし、変数だけじゃなくて式全体をエスケープの対象とするべきなのに、「サニタイズ」という言葉で教育が行われていると、その考え方に至る機会が殺がれてしまう。

だから、「サニタイズ言うな」なのだ。

解説本の著者にとって、煩雑なコードはただでさえ避けたいところ、こうした処理のことを「サニタイズ」という言葉で理解していると、本質的に必要な処理としてではなく、「あくまでセキュリティ対策として必要なんだ」という誤った理解をしてしまいがちだ。その結果、「サンプルコードでは脆弱なまま、後の解説でセキュリティ対策として教える」という書き方になってしまう。

この種の処理が、セキュリティ対策以前に元来本質的に必要な処理(SQL文を構成するコードでは元々常に必要な処理であるし、HTMLを出力するコードでは元々常に必要な処理)であることは、たとえば、次の事例を見れば明らかであろう。

  • サポート&サービス FAQ紹介, 文書番号 763, オービックビジネスコンサルタント

    [Q]
    起動時に下記のエラーが発生する。
    「行1:’XXXX’の近くに不正な構文があります。
    文字列’)’の前で引用符が閉じていません
    state:37000,Native:170
    state:37000,Native:105」

    【文書番号】763 【更新日】2003/08/12
    【対象商品】奉行21シリーズ全製品,奉行2000シリーズ全製品


    [A]
    原因・理由

    コンピューター名に「’ シングルクォーテーション」が含まれている場合に発生します。

    回答・対処方法

    コンピューター名に「’ シングルクォーテーション」を使用しないようにして下さい。

    (略)

これはローカルで動くソフトウェアのバグの話なので、セキュリティ脆弱性とは関係がないため、このような対処方法が案内されているのだろう。このように、セキュリティとは無関係なところでも、SQL文を構成するときに「'」で囲んだ中に式(上の場合は「コンピュータ名」)を埋め込むときには、式の評価結果中の「'」をエスケープする処理は、元々当然のこととして必要なのだ。これは、入門書としてSQLの使い方を解説する場面で、一番最初に叩き込むべきことである。セキュリティとかを持ち出すまでもない。

SQL文やHTMLだけでなく、文法を持つ文字列一般を文字列連結で生成するときに、こういった処理が必要となることを、プログラミング一般を教えるときに体験させておくべきかもしれない。

11月22日の日記「攻撃者視点ではなく開発者視点での解説を」で批判したその連載記事でも、サニタイズという言葉に毒されている様子がうかがえていた。

セキュアプログラミングの限界

Webアプリケーションの脆弱性を生み出さないために、Webアプリケーション開発者の間ではセキュアプログラミングという概念が浸透していった。この概念には、セキュアなプログラムを作成するためのあらゆる方策が含まれているが、よくいわれることはユーザーからの入力データをそのままプログラムに受け渡すのではなく、一度必ず浄化作業(サニタイジング)を行うという考え方である

例えば、プログラムやコマンドで意味を持つメタキャラクタ(メタ文字:\、[、]、|、$、*など)の入力を禁止し、正規表現にて入力文字列のパターンを限定することによって入力データの浄化を行う。

Webアプリケーションファイアウォールの必要性 第1回 機密情報に合法的に近づけるWebアプリケーションを守れ, @IT, 2005年8月17日

セキュアプログラミングが何たるかを取り違えているのだから、「セキュアプログラミングの限界」などという誤った帰結にたどり着いている。「サニタイズ」という概念は攻撃者視点の発想であり、攻撃者視点で対策を考えていると、攻撃者視点ではなく開発者視点での解説を」で示したような、誤った対策手法を導いてしまいかねない。

上に挙げた(B)の事例にも、「サニタイズ」という流行語の害が見られる。

「危険な文字列は削除する」という発想をすることが間違いなのだが、「サニタイズ」という言葉からは「削除」とか「変換」という対策を連想させやすい。

パス名を受け取ることを想定したパラメタに「../」や「..\」が含まれていたら、削除とか変換をするのではなく、エラーとして例外処理して終了するというのが、本来のそのプログラムの正しい動作だろう*5

「サニタイズする」という対策屋発想には、「不用意にプログラムの挙動を変えてはいけない」という背景があるように思える。つまり、既に稼働中のシステムに対して脆弱性検査を行ったときに脆弱性が見つかると、プログラムの他の部分に影響を与えないように、最小限の変更で脆弱性を排除したいと考えるだろう。「○○のときはプログラムを終了」などという大それたプログラムの意味の変更を、対策屋が実施するべきでないという考え方は頷ける。そのような考えに基づくと、CGIの入力段階で削除したり変換するということになる。これが、元々の「サニタイズ」という言葉だったはずだ。先の引用にあった、

ユーザーからの入力データをそのままプログラムに受け渡すのではなく、一度必ず浄化作業(サニタイジング)を行うという考え方である。

Webアプリケーションファイアウォールの必要性 第1回 機密情報に合法的に近づけるWebアプリケーションを守れ, @IT, 2005年8月17日

という記述は、まさにそうした「サニタイズ」の発想で書かれている。

既存のシステムに応急手当としてそのような対策をする場面ではそれでもよい。「サニタイズする」と言って正しい。だが、これから新規に開発するシステムにおけるセキュアプログラミングを語るときに、「サニタイズ」とか言うのはもうやめたらどうか。

もっとも、万が一に脆弱性があるかもしれないことを想定しての保険として、CGIの入力段階でパラメタを洗浄する(サニタイズする)ことには賛成だ。とくに、制御コードはサニタイズしてしまうことを検討した方がよいかもしれない(真に改行コードの入力を必要とする部分では、改行コードは削れないが)。だが、それはそれなのであって、ごちゃ混ぜにしてはいけない。「本来の正しいプログラム方法 + 万が一のための保険としてのサニタイズ処理」という整理を常に心がけるべきである。

「サニタイズ」というあたかも専門用語であるかのような香りの漂う、このカタカナ化された輸入語は、とても安易に使えて一度使うとやめられない麻薬のような言葉なので、セキュアプログラミングの本質を理解していない素人対策屋(つまり、脆弱性検査の経験はあっても開発者としての経験がないような人)でも、「それさあ、サニタイズしてないのがいけないんだよねー」と、訳知り顔で語ってみせることができてしまう。

もちろん、「サニタイズ」を「エスケープ」に言い換えるなどというのは超大間違いだ。実際、どこだったかで、パス名パラメタの「../」チェックの対策を解説する文書で、

「../」を「..%2F」にエスケープしましょう。

などというものを見た記憶があるが、超大間違いだ。

とりあえず「サニタイズ」も「エスケープ」も口にしないようにしてみたらよい。サニタイズという言葉を使わずに自分が言いたいことを表現しようとしてみたらいい。正しく説明することの困難から逃げようとするな、ということだ。

ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに

ERBをWebページに使うとき、クロスサイトスクリプティング脆弱性のないように書くには、 「<%=h ... %> 」という記法を使って、次などのように書く。

No. <%= row["id"] %><br /> 題名: <%=h row["title"] %><br /> 名前: <%=h row["name"] %><br /> 日時: <%= row["postdate"] %><br />

これは(C)のプログラムをERBに置き換えたものだ。

「h」というのは「html_escape」というメソッドの別名として定義されており、エスケープ処理が煩雑にならないようにすることを意識して設計されていることがうかがえる。

このようにすっきりした書き方を見ると、「title」と「name」のところだけ「<%=h ... %>」とするのが不自然で、全部「<%=h ... %>」にしてしまうのが自然だという感じがしてくるだろう。

そうすると、「h」付きと「h」無しを逆にしたらよかったのにと思えてくる。

<%= ... %> の外は静的なHTML断片であるのに対し、<%= ... %> の部分は動的なものを埋め込みたいときに使う。動的なものを埋め込みたいときというのは、そのほとんどは、タグ自身を埋め込みたいわけではないだろう。とすると、デフォルトで全部HTMLエスケープしてしまうのが自然ではないだろうか。逆に、タグをどうしても動的に埋め込みたいときに <%=h ... %> と書く方がよかったのではないか。(名前は「h」以外にした方がよさげだが。)

そのようにして考えると、そもそも、ASPから始まって、JSP、PHP、ERBと受け継がれてきた、HTML中にプログラムを埋め込むというこの仕組みが、最初からデフォルトでエスケープされるように作られていたらよかったのに……と思えてくる、そんな今日この頃だ。

*1 PHPの設定で「magic_quotes_gpc = On」にしているので、無駄な「\」が現れている。

*2 ただし、p.67のCSRF対策などには問題がある。「対策4」として、

管理者セッション内の各種データの受け渡しに、$_GET や $_POST ではなく、$_SESSION を利用する。

という手法が挙げられていて、これが本命の対策のように書かれているが、これは対策にならない。4月27日の日記に書いていたように、必要なパラメタ値がセッション変数にセットされているということは、前のどこかのページでその値をセットするリクエストがあるはずで、そのリクエストにCSRF攻撃した後に実行ページにもCSRF攻撃するような仕掛けで破られてしまう。

また、4-1-7節「SSLの効果」のp.125の記述に、パケット盗聴されたときの問題について、

Webアプリケーションを作るために、そのレベルでのクラッキングの可能性まで考えなければならないなんてナンセンスです。*15

逆に、SSLを利用し、かつ、クッキーに「SSL以外ではやりとりしない」という属性をつけていたとしても、XSSすら防げません。

と書かれていて、何を言いたいのかちょっと意味不明になっている。

もうひとつ問題点を挙げると、p.228のコラムで「magic_quotes_gpc」について、

magic_quotes_gpc機能についてはその副作用から批判も強く、この設定はOffとすべきと書かれた文献も多く存在しますが、プログラマーのスキルレベルが信用できないWebアプリケーションを利用するケースでは、magic_quotes_gpcをOnにする方が、ほんの気持ち程度は安全と言えます。

と書かれているが、magic_quotes_gpcをOnにすると、CGIパラメタがShift_JISで渡されたときに文字化けが発生してしまうため、これが邪魔になるという問題が起きているようだ。そのため、酷いことに、magic_quotes_gpc がOnのPHP環境でも動くようなプログラムを作るテクニックと称して、PHPプログラムの冒頭で、CGIパラメタの全部に対して「stripcslashes」をかけるという「前処理」が、一部のPHPプログラマの間で定番となっているようだ(この本に書かれているわけではない)。magic_quotes_gpc = On したり stripcslashes したり、また htmlspecialchars してみたりと、ほんと汚いPHPコードがたくさん Googleで見つかる。magic_quotes_gpc は Off で徹底がよいだろう。

それから、p.197の「7-1 ソースコードが手元にないときの脆弱性の見つけ方7-1-5 実際に攻撃してみる」で、

本当の悪意あるクラッキングであるなら、当然、プロキシやネットカフェを利用するなどのアクセス元の隠蔽も必要ですが、その手段については本書の範囲外です。

などと書かれているのが危ない。不正アクセス行為にあたらないことが確信できる操作しかしてはいけないのに、これでは勘違いする読者もいるのではないか?

とはいえ、この本では、session.use_trans_sid を off にすることや、session.use_only_cookie = 1 とすること、session.auto_start を off にすることなど、PHP特有の危険を回避するための重要な設定について書かれているところが良い。なお、このあたりの内容は以下のサイトでも読める。

*3 さらに発展させると、HTMLの要素を入れ子状に追加したり挿入して構成していくメソッドを用意するという方向性に行き着くが、やりすぎると、かえって煩雑になる、あるいは処理が重くなるなどの理由で、使われなくなってしまう。どこまで構造化された方法を使うのが、最もバランスがとれているかということになる。

*4 書籍「PHPサイバーテロの技法―攻撃と防御の実際」においても、p.48に「クッキー表示のサニタイズ」というコラムがある。cookieの値をHTML出力するときに「<」「>」のエスケープが必要かということが議論されていて、「XSS脆弱性があれば……クッキーを操作可能であるため……万が一のため……」としてエスケープするコードを示しているが、そういったことは、全部エスケープする正統なコーディングをしていれば考えるまでもない。

*5 この書籍には、続くページで、

また、上位ディレクトリ指定があった場合に不正な入力として終了する方法もあります。

山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.159

という補足が書かれてはいるが、こちらが本来なすべきこととは書かれていない。


2005年12月31日

「逆」にしたERBが登場

27日の「(略)とかERBとか、逆だったらよかったのに」の件、大岩さんが、逆にしたERB改造版を作ってくれた。

さて、使い勝手はどうだろうか。

要約版:「サニタイズ言うなキャンペーン」とは

27日の日記「『サニタイズ言うなキャンペーン』とは何か」は、いろいろ盛り込みすぎたせいか思ったよりわかりにくいものになって いるらしいので、結論から順に整理しなおしてみる。

  • 結論: まず「サニタイズ」という言葉を使うのを避けてみてはどうか。正しく説明することの困難から逃げようとしないで。

    • 例外1: 万が一に脆弱性があるかもしれないことを想定しての保険として、CGIの入力段階でパラメタを洗浄することを、サニタイズと言うのはかまわない。

    • 例外2: 既存のシステムに応急手当としてCGIの入力段階でパラメタに処置をする場面では、サニタイズと言うのはかまわない。

  • 理由1: 「サニタイズせよ」というスローガンは、「危険な文字列は削除する」のが本来的な対策であるかのように誤解させる。または、「危険な文字は変換する」のが本来的な対策であるかのように誤解させる。
    • 事例1: 書籍「PHP実践のツボ セキュアプログラミング編」における(B)の解説
    • 事例2: 「../ を ..%2F にエスケープしましょう」という大間違いな解説。
    • 問題点: 削除という対策は別の危険をもたらす場合がある。
      • 事例: 「..././」が「../」に変換されて攻撃が成功してしまうという、対策の失敗
    • 経緯の考察: 一部の脆弱性について、たしかに文字削除をするのが妥当な対策である場合もあるため、その削除処理が「サニタイズ」と呼ばれるようになり、次第に意味を拡大させて使用されるようになったのではないか。
    • 何が正しいか: インジェクション系の脆弱性では、メタ文字をエスケープするのが正しい。パス名パラメタのチェックおよびディレクトリトラバーサルでは、異常時には例外処理に飛ばすのが正しい。
  • 理由2: 「サニタイズせよ」というスローガンは、「CGIの入力パラメタに対して処置する」のが本来的な対策であるかのように誤解させる。
    • 事例: 「攻撃者視点ではなく開発者視点での解説を」で批判した@ITの記事
    • 問題点: CGIパラメタがプログラム中のどこでどのように用いられるかを把握せずに安全なプログラムにできるはずがなく、その把握は一般には困難である。
      • 事例1: いろいろ
      • 事例2: 「セカンドオーダーSQLインジェクション」(後述)。
    • 経緯の考察1: 既存のシステムに応急手当としてCGIの入力段階でパラメタをサニタイズすることが、セキュリティ対策屋の仕事として普及したが、これが間違って、新規開発の場面でなすべきこと(セキュアプログラミング)として広まってしまったのではないか。
    • 経緯の考察2: 「サニタイズする」という対策屋発想には、「不用意にプログラムの挙動を変えてはいけない」という背景があるように思える。
    • 何が正しいか: 入力段階ではなく「出力段階」で。「出力」というのは(出力というより)、問題を起こす場所。
  • 理由3: 「サニタイズせよ」というスローガンは、「CGIの入力パラメタに依存した式に対してだけ処置すればよい」というプログラミング手法で十分であると思わせてしまう。
    • 事例1: 書籍「PHPサイバーテロの技法―攻撃と防御の実際」における(C)のコード
    • 事例2: 書籍「PHPサイバーテロの技法―攻撃と防御の実際」における、cookieの値をHTML出力するときにエスケープするべきかを議論したコラム。
    • 問題点1: サニタイズ漏れを起こしやすくなる。
      • 事例: User-Agent: や Via: などの値を表示しようとした場合に、クロスサイトスクリプティング脆弱性を生みやすいことが古くから知られている。
    • 問題点2: 対策コードが整然とせず煩雑なものとなりやすいため、Webプログラミングの解説本で、対策を入れることが敬遠されがち。
    • 問題点3: 正しく書かれていることの確認がやりにくくなる。
    • 経緯の考察: 処置はCGIパラメタの入力段階で行うのではなく「出力段階で」ないし「出力の直前で」なすべきだと理解していても、貧民的プログラミングの発想があるため、「サニタイズ」という語感によって、入力に依存するところだけやっておこうというプログラミングスタイルをもたらしているのではないか。
    • 何が正しいか: 文法のあるテキストを文字列連結で生成するときは、全ての箇所で、文法に応じて存在し得るメタ文字をエスケープするのは、本来やるはずのこと(セキュリティに関係なく)。
  • 理由4: 「サニタイズすることがセキュアプログラミングである」と勘違いしていると、それが開発においてオプションであるという発想 (正常系の実装が優先するという発想)に陥りがち。
    • 問題点: Webプログラミングの解説書で、後付けの対策として書かれてしまう。
      • 事例: 書籍「PHP実践のツボ セキュアプログラミング編」で、いきなり最初のサンプルコードからしてクロスサイトスクリプティング脆弱性がある。
    • 経緯の考察: 正常系の実装として本来なすべき処理であるなら、わざ わざ「サニタイズ」だの「サニタイジング」だのいう特別な用語は出てこな いはずという直感が働くため。
    • 何が正しいか: インジェクション系などの脆弱性では、その「対策」と呼ばれるものは、セキュリティ対策という以前に、正常系の実装として本来なすべき処理。
  • 理由5: プログラミングを理解していない対策屋でも、「それさあ、サニタイズしてないのがいけないんだよねー」と、訳知り顔で語ってみせることができてしまう。
    • 事例: 後述。
    • 問題点: 誤った対策方法を教える解説や中身のない解説を増やしてしまう。

既にここまで来ている――サニタイズ症候群の末期的惨状

という連載は、最後まで読んでみてけっきょく質の低い解説だったが、タイト ルの「サニタイズ開発手法」というネーミングからして、そのダメっぷりは当 初から臭っていた。

どのあたりが「質の低い」ものなのか、いくつか挙げておく。

複数ページ間におけるセッションを管理するために、Webブラウザの持つCookie(クッキー)という仕組みが利用されることが多い。このCookie というものは、要約するとユーザーがWebページのフォームに入力した情報を一時的にクライアントPCに保存しておき(保存された情報をCookieと呼ぶ)、Webサーバ側で何らかのフォームを表示するときにCookie情報を使い、フォームの表示データを整形するというものだ。このため、悪意あるスパイウェアなどでCookie情報を抜き取るような行為が問題視されている。

スパム時代のサニタイズ開発手法 第1回, ITmedia, 2005年12月1日

「フォームの表示データを整形」というのが意味不明。この文脈で、cookieを 抜き取る原因を「スパイウェア」としているのがおかしい。「このため」とい う接続詞が前後の文脈につながっていない。なぜcookieを抜き取られるとまず いのかと、cookieを抜き取られる原因としてWebアプリの脆弱性を挙げるべき ところ。

また、プログラム側にバグがない場合でも個人情報が保存されているファイル自体のパーミッション設定(ファイルの読み出しや実行権限などの属性設定)が不適切になっていると、前述のようにブラウザで(ファイル名までの)URLを直打ちするだけで、誰でもそのファイル内容が参照できてしまうことになる。

スパム時代のサニタイズ開発手法 第2回, ITmedia, 2005年12月7日

ファイル丸見え問題を、ファイルの置き場所ではなく、ファイルのパーミッショ ン設定の問題と捉えているところが、いかにも素人臭い。

何が言いたいのかサッパリな記事。「Cookieは悪くない」の理由はきちんと説 明されてないし、「漏洩パターンの真実」なんぞ書かれていない。

ブラウザ上で動作するスクリプトコードとしては、従来からJavaScriptが存在するが、最近はJavaScript自身のバージョンも上がっており、表現力が増している。悪意あるスクリプトコードを受け取って対策が講じられていないと、ローカルPCから情報が抜かれてしまい任意のサーバなどへ自動送信といったこともできてしまう。

IEなどで使われるActiveXは、仕様上でレジストリの読み出しも可能としているため厳重な注意が必要となる。もちろん、便利さゆえの機能ではあるが、セキュリティと利便性は裏腹ともいえるのだ。

スパム時代のサニタイズ開発手法 第4回 Perlは悪くない――CGIセキュリティホールの落とし穴, ITmedia, 2005年12月20日

なんじゃこりゃ。べつに「表現力が増している」わけじゃないし。 ActiveXに注意が必要だとしてべつに「レジストリの読み出しも可能」が事の 本質じゃ全然ないし。「Perlは悪くない」は意味不明だし、 「CGIセキュリティホールの落とし穴」は全然書いてないし。

Perlは“手続き型言語”の一種であり、何らかの処理を行わせたい場合には、あらかじめ用意されている関数を呼び出すことで処理が可能となる。このことはPerlに限らず、ほかのプログラミング言語でも考え方が変わらない。何を意味するかというと、次のような具合だ。

スパム時代のサニタイズ開発手法 第5回, ITmedia, 2005年12月21日

まったく無駄な段落。

そうとはいえ、タグの無効化だけでWebアプリケーションのセキュリティホール(脆弱性)がすべてなくなるというわけではない。あくまでサニタイズはセキュリティホール(XSS)対策のための一手段にすぎないことを認識しておいてほしい。予期せぬ情報漏えいを防ぐための、最後の切り札と考えておくのがよいだろう。

スパム時代のサニタイズ開発手法 第7回 サーバの複雑さが変えたセキュリティ「サニタイズ」とは, ITmedia, 2005年12月27日

「最後の切り札」?? 何が言いたいんだ。

デベロッパーのためにもう少し突っ込んだ見解も示しておこう。(略)

Perlではコメントを「#」で始まる一行で記述することができる。コメントはプログラムの動作には何ら影響を与えないものだが、ソースコードの可読性を良くするために残すものだ。コメントが適切に付けられたコードは、メンテナンスが必要なときに読みやすいプログラムとなる。

Perlでは変数を「$」で始まる文字列で利用することができる。プログラムにおいて変数はいわば一時的なメモリ領域である。

スパム時代のサニタイズ開発手法 第7回 サーバの複雑さが変えたセキュリティ「サニタイズ」とは, ITmedia, 2005年12月27日

「デベロッパー」にとってまるっきり無駄な段落。

実際の処理はタグの置換というシンプルなものだが、プログラム本来の処理ではないため意外と見落とされやすい。

スパム時代のサニタイズ開発手法 第7回 サーバの複雑さが変えたセキュリティ「サニタイズ」とは, ITmedia, 2005年12月27日

意味不明。

オンライン・ムック「スパム時代のサニタイズ開発手法」では、これまで情報漏えいに対する防御策をさまざまな観点から解説してきた。

「サーバの複雑さが変えたセキュリティ「サニタイズ」とは」では、Webアプ リケーションにおけるサニタイズの仕組みを解説し、「巧妙化するネット地雷 原の避け方」と「あのCGIがクラックされてしまった理由」では、Perl言語を 例にして防御策の重要性を示した。いずれもがサービス指向となってきたWeb サイトで重要視しなければならない防御ノウハウばかりだ。

連載最後となる今回のポイントは、

スパム時代のサニタイズ開発手法 第8回 , ITmedia, 2005年12月28日

7回も連載してきてそれだけか。Perlのopenの話と、XSSが書いてあるだけだ。 今のご時勢にこれだけってのは、アリエナイ。

「サニタイズ」とさえ言っていれば、なんとなくそれっぽい解説のようなもの ができてしまうという、「サニタイズ」普及の悪影響もついにここまで達したか! と思い知らされた記事だった。

「じゃあなんと言えばいいのか」って?

次のような疑問が出てくるかもしれない。


「サニタイズ言うな」といわれても、たしかにインジェクション系の脆弱性に ついては、「(文字列連結で構成するテキストの文法に応じて)メタ文字のエ スケープする」と言えばよいのだとして、だけど、blogエンジンのようにHTML の入力を許したいWebアプリケーションにおいての対策のことはどう言ったら よいのか。それこそ「サニタイズ」なんじゃないの?


答えは簡単。「スクリプトの禁止」「スクリプト除去」「スクリプトの無効化」 などと普通の言葉で言えばよい。なぜわざわざ変な言葉を持ち出す必要がある のか。

「HTMLタグの記入を許すblogアプリなどでは、スクリプトの除去が必要です」 というように説明すればよい。

最近では、万能な意味で「サニタイズ」を使う人が増えてきた。英単語として のsanitizeは「消毒する」という意味だが、これをわざわざ意味を変えて「無 害化する」と訳す人が目立つようになってきた。その背景には、「入力で対策 することが誤りである」という指摘に対して、「出力で対策することもサニタ イズと呼びたい」という思考が働いているのだろう。

「消毒する」という表現には、「変数にシュッ・シュッと消毒液をかけておく」 というニュアンスがあるように思える。つまり、入力の段階でパラメタに一律 に消毒をかけておき、あとは自由に使うという開発スタイルをうまく表現した もののように思える。プログラムの最終段であるHTML出力のそれぞれの場所で エスケープ処理することを「消毒する」と表現するのはちょっと不似合いな感 じがする。あらゆる対策に使える言葉として広げようとするものだから、「消 毒」では似合わないので、「無害化」などという異なった訳が出てきたのでは ないか。

「無害化」と呼ぶくらいだったら、「脆弱性排除」と言えばよい。あらゆる脆 弱性対策を「無害化」と呼ぶくらいだったら、「脆弱性排除」と言うのと違わ ない。

そこまで「サニタイズ」の意味が広げられてしまうと、「サニタイズ」と言っ たところで何の説明にもならない。カタカナ英単語を使うことであたかもそこ に何か専門的なものがあるかのような臭い醸し出す役割しか果たさない。

そういうことをやっていると、「サニタイズ」という言葉を使うだけで満足す るような人達が出てきて、「スパム時代のサニタイズ開発手法」のような糞記 事が現れてくる。

「セカンドオーダーSQLインジェクション」ですって?

日経システム構築2005年12月号に、「緊急点検!Webア プリ・セキュリティ 多層の防衛ラインでシステムを守る」という記事が 出ているが、この記事がまた「サニタイズ」の嵐*1になっている。

それは別にして、この記事には奇妙なことが書かれている。

「対策済み」こそ危ない

それでも本誌の読者ならば,既に「対策済み」かもしれない。だが,その安心 感が足をすくいかねない。クラッカは,開発者が対策済みであること さえも悪用し,その盲点を突くような攻撃パターンを編み出す。

緊急点検! Webアプリ・セキュリティ 多層の防衛ラインでシステムを守る, 日経システム構築2005年12月号

「対策済みであることを悪用する」というのは、いったいどういう意味か??

読み進めていくと、どうやらこれは次のことを指しているようだ。

最新の攻撃手法に適応していくことは,ユーザー企業やSIベンダーの担当者に は荷が重い。自前のテストでは不足する網羅性や最新動向への適応性を補うた めに,セキュリティの専門家によるセキュリティ監査サービスを適宜活用した い。

例えば,「セカンドオーダーSQLインジェクション」という攻撃は, 自前のテストではテスト項目として挙がりづらい。この攻撃は,一般 的に言われている「SQLインジェクション対策」では防げない特徴がある。

クラッカは,ユーザーからの入力値をサニタイジングするという,“正しい” とされるSQLインジェクション対策を逆手に取る。仮にユーザー情報を登録・ 変更するようなアプリケーションでこの攻撃が成功すれば,図7のように他人 のパスワードを自由に書き換えられてしまう。

緊急点検! Webアプリ・セキュリティ 多層の防衛ラインでシステムを守る, 日経システム構築2005年12月号

「セカンドオーダーSQLインジェクション」 (second-order SQL injection)と は、Next Genration Security Software社が2002年に発表した論文の中で名付けたものであり、それは 以下で読める。

  • Chris Anley, Advanced SQL Injection In SQL Server Applications", Next Genration Security Software Ltd.

    [Second-Order SQL Injection]

    Even if an application always escapes single - quotes, an attacker can still inject SQL as long as data in the database is re-used by the application.

    (たとえアプリケーションが常にシングルクオートをエスケープしていても、 攻撃者はなおも、データベース中のデータがそのアプリケーションで再利用さ れるときにSQLをインジェクトすることができる。)

    For example, an attacker might register with an application, creating a username

    Username: admin'-- 
    Password: password

    (例えば、攻撃者がアプリケーションに登録して、ユーザ名「admin'--」、 パスワード「password」のユーザ名を作ったとしよう。)

    The application correctly escapes the single quote, resulting in an 'insert' statement like this:

    (このアプリケーションはシングルクオートを正しくエスケープし、このよう なINSERT文が作られる。)

    insert into users values( 123, 'admin''--', 'password', 0xffff)

    Let's say the application allows a user to change their password. (略)

    (このアプリケーションが、ユーザにそのパスワードを変更することを許して いるとしよう。)(略)

    The query to set the new password might look like this:

    (新パスワードをセットするクエリはこんな感じになるかもしれない。)

    sql = "update users set password = '" + newpassword + "' where 
    username = '" + rso("username") + "'"

    Given the username admin'--, the query produces the following query:

    (ユーザ名 admin'-- が与えられると、以下のクエリが生成される)

    update users set password = 'password' where username = 'admin'--'

    The attacker can therefore set the admin password to the value of their choice, by registering as a user called admin'--.

    (したがって攻撃者は、admin'-- というユーザを登録することによって、admin のパスワードを自由にセットできる。)

この話は、日経システム構築の記事図7で解説されている。

これは要するに何が悪いのかというと、

sql = "update users set password = '" + newpassword + "' where username = '" + rso("username") + "'"

の部分で、式「rso("username")」の値に対して「'」のエスケープ処理をして いないのが悪い。

このように書かれたプログラムの問題を指して、

一般的に言われている「SQLインジェクション対策」では防げない

緊急点検! Webアプリ・セキュリティ 多層の防衛ラインでシステムを守る, 日経システム構築2005年12月号

と言うのはいかがなものか。

正しいSQLインジェクション対策は、文字列連結でSQL文を構成しようとする全 ての箇所で、「'」で括った部分に埋め込む式の値に対して「'」のエスケープ 処理を施すというものだ。それを淡々と遂行していればこのようなことにはな らない。

記事中に、

だが,セカンドオーダーSQLインジェクションは,これらの対策をくぐりぬけ る。この攻撃を防ぐにはさらに,(4)「変数を使っ てSQL文を組み立てているすべての個所でサニタイジングする」(ラッ クシステムソリューション5部部長倉持浩明ことが欠かせない。

例えば,データベースに格納済みの値を利用する場合や,ファイルに保存した 値を利用する場合なども,必ずサニタイジングする。

緊急点検! Webアプリ・セキュリティ 多層の防衛ラインでシステムを守る, 日経システム構築2005年12月号

と書かれているのがそれを指しているのだろう。だが、それを「さらに」と言 うのはいかがなものか。すべての箇所でエスケープするのが元々当然なのであ り、当然だということを伝えるべきである。

クラッカは,ユーザーからの入力値をサニタイジングするという, “正しい”とされるSQLインジェクション対策を逆手に取る。

緊急点検! Webアプリ・セキュリティ 多層の防衛ラインでシステムを守る, 日経システム構築2005年12月号

とあるように、この記事が言うところの「一般的に言われている対策」とは、 「CGIの入力パラメタに対してエスケープする」だとか、「CGIの入力パラメタ に依存する変数に対してエスケープが必要」というものなのだろう。記事は、 「入力値をサニタイズするという対策は正しくない」ということをハッキリ言 うべきだ。

「サニタイズ」なんて言葉を使っているから、「入力値うんぬん」の呪縛から 逃れられない。サニタイズ症候群の悪影響はこういう形で現れてくる。

*1 正確には「サニタイジング」 と書かれている。無駄に「イング」形にしている分だけ、さらに神格化できて いるところが滑稽だ。


最新 追記

最近のタイトル

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