高木浩光＠自宅の日記

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

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

• 簡単！ やさしいセキュリティ教室 金融犯罪に遭わないために, 三井住友銀行

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

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

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

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

---

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

うはは。

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

---

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

うひひ。

偽メールの例3

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

---

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

うは。それ……。

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

---

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

ぐほほほ。

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

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

---

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

そうだそうだ。

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

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

---

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

だよねー。

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

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

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

うはははははははははは。（つД`）ぐすん

よし、あとは拡張子だ！

■ 日経バイト休刊最終号にウイルスバスター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日の日記にひき続き、トラックバックが できない様子なので、こちらからリンクして差し上げる。

• 2005-12-21 スパイバスター2006 トレンドマイクロ, TTFOXZの日記

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

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

一種の優越意識である。

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

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

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

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

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

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

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

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

• シンプルな安全確認ルールとそれに則ったサイト作りを〜産総研高木氏講演, INTERNET Watch, 2005年12月2日

の講演で述べた「シンプルな安全確認ルール（手順）」というのがどういうも のかというと、まず、次の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を買っても、その「安全な使い方」はマニュア ルに書いてない。学校でインターネットの使い方を教わっても、「安全な使い 方」は教えてくれない。そこが誤りの根源ではないか。

■ 青梗菜炒めが美味い

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

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

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

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

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

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

• 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月
• GIJOE, PHPサイバーテロの技法―攻撃と防御の実際, ソシム, 2005年11月

「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中にプログラムを埋め込むというこの仕組みが、最初からデフォルトでエスケープされるように作られていたらよかったのに……と思えてくる、そんな今日この頃だ。

■ 「逆」にしたERBが登場

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

自動quoteつきERBの実験, おおいわのこめんと (2005-12-29)

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

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

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: プログラミングを理解していない対策屋でも、「それさあ、サニタイズしてないのがいけないんだよねー」と、訳知り顔で語ってみせることができてしまう。
  • 事例: 後述。
  • 問題点: 誤った対策方法を教える解説や中身のない解説を増やしてしまう。

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

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

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

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

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

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

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

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

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

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

スパム時代のサニタイズ開発手法 第3回 Cookieは悪くない――潜む漏えいパターンの真実, ITmedia, 2005年12月14日

何が言いたいのかサッパリな記事。「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の入力パラメタ に依存する変数に対してエスケープが必要」というものなのだろう。記事は、 「入力値をサニタイズするという対策は正しくない」ということをハッキリ言 うべきだ。

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