新生鳩丸掲示板♯

>バグがあればどのような文字列も潜在的に危険だと思いますが、そのような主張でしょうか。

　今のところ私は特に「主張」はしていないのですが、この質問でよく分かりました。この質問に YES と答える立場と NO と答える立場の両方があり、そこで考え方の違いが出ているのだと思います。

　たとえば以下を見ていただくと、

PerlのTaintモード（汚染検出モード）

http://www.ipa.go.jp/security/awareness/vendor/programming/a04_03_main.html

　ここでは、外部入力は全て汚染されている ("taint" である) ので、そのまま使うと危険だという考え方をしています。「どのような文字列も潜在的に危険」であるから無害化 (サニタイズ) しなければならない、という考え方です。

　ただし、これは見方の一つでしかありません。もう少し具体的に言うと、これは「新規にシステムを作る立場」と「脆弱性を指摘する立場」の、それぞれの見え方の違いに過ぎないのだと思います。結局の所、高木さんの主張は記事の末尾にある

>特に新規にシステムを開発するような局面において「『サニタイズ』(のようなプログラムを汚くする対策)ではなく、本来やるべき処理が何かをプログラマにきちんと伝えていくことが必要である」と参加者に訴えていた。

　という文に集約されると思うのですが、「特に新規にシステムを開発するような局面において」という条件付きであることが重要だと思います。

　脆弱性を指摘する立場では、良く「適切なサニタイズがされていない」という言い方をすると思いますが、これは既存の脆弱な (バグのある) プログラムを評価したものです。この局面では、結局の所脆弱であるかどうかだけが問題となりますので、結果としてサニタイズされているかどうかだけが問題となります。

　結果として脆弱でなくなりさえすればよいので、プログラマが意識してサニタイズルーチンを入れたのか、それともたまたま特別なサニタイズが必要ない状況だったのか、ということはどうでも良いことですし、そもそも端からは (指摘者の立場からは) 分からないことでもあります。他の不具合 (たとえば単引用符が検索できない) があるかどうか、ということも、脆弱性の有無とは関係のない話になってしまいます。

#実際、納得のいかない直され方をすることは良くあるのですが、ともあれ脆弱でなくなったのであれば、それ以上は何も言えないわけです。たとえ特定の文字列が検索できなくても。

　高木さんのお話でも、

>既存のサイトに対して、そのセキュリティ対策として『サニタイズ』を行うというのは、セキュリティ屋の発想としては極めて自然である

　と明確に言われており、このような局面において「サニタイズ」という考え方をすること自体を否定されているわけではなくて、既存のサイトの脆弱性を指摘する立場と、新しく開発する立場とを明確に区別して議論されているのだと理解しました。

　……というようなところで、私の中ではかなりすっきりした感じです。

>Google先生ですか? 【謎】

いえ、もう一人の先生【誰】です。

ところでIPAは本名でないと届出を受理してくれないそうですね。PGPのことも知らないし、https://isec.ipa.go.jp/inq/menu/index.jspはJavaScript有効でないと動かないし……。届出、微妙かも。

>いろいろ試してみると、そのサイトのドメインを含むURLしか送信できないようになっていました（ほっ）。ただ、そのサイトはリダイレクタを提供しているので、そのサイト内のページと見せかけつつ、全く別のページにリダイレクトするURLを送信させることができました。

>

>ちなみにそのサイト、一般的にはかなり信頼されているので、迷惑的な使い方をされると信用に傷がつくのではないかと思います。いちおう教えてあげた方がよいでしょうか？

Google先生ですか? 【謎】

ご参考【謎】:

http://www.rbl.jp/phishing/index.php?mode=show&date=20050523

>・単引用符がそのまま SQL に渡るのであれば危険です。SQL インジェクションの危険性があるからです。

単引用符がそのまま SQL に渡るのはバグではないですか？これまで見たとおり。

バグがあればどのような文字列も潜在的に危険だと思いますが、そのような主張でしょうか。

あるいは、類型的にその周辺でバグが起こりやすく、注意が必要な文字列が「危険」ということでしょうか。

>この単引用符が「サニタイズ」の対象なのであれば、例の「サニタイズ」の定義により、「単引用符」は「危険な文字列」である必要があります。

>この「単引用符」は危険ですか？危険だとするならば、なぜですか？

　言われていることは同じですよね。

・単引用符がそのまま SQL に渡るのであれば危険です。SQL インジェクションの危険性があるからです。

・そうでなければ問題ありません。

　適切にエスケープしているのであれば、単引用符がそのまま SQL に渡ることはありませんので、改めてサニタイズする必要は無いといえます。

>>そういう問題ではないのではないかと思います。

>>これまでの話では二番目のものについてはなにも述べていません。

>>「危険な文字列」というものがなぜ「危険」なのかを考えると、話のかみ合わなさの原因が見えそうな気がします。

>

>　なんだかよく分からなくなったのですが、例を上げて説明していただけませんか?

たとえば、

>たとえば単引用符(')を検索したケース

このケースでは、単引用符を検索する命令を検索エンジンに与えようとするならば、その検索エンジンの仕様に従って単引用符をエスケープする必要があると思われます。そうしないとその検索エンジンでは単引用符を検索できないからです。

この単引用符が「サニタイズ」の対象なのであれば、例の「サニタイズ」の定義により、「単引用符」は「危険な文字列」である必要があります。

この「単引用符」は危険ですか？危険だとするならば、なぜですか？

>そういう問題ではないのではないかと思います。

>これまでの話では二番目のものについてはなにも述べていません。

>「危険な文字列」というものがなぜ「危険」なのかを考えると、話のかみ合わなさの原因が見えそうな気がします。

　なんだかよく分からなくなったのですが、例を上げて説明していただけませんか?

>　うーん、結局はとらえ方の違いなのでしょうか。

>

>・「危険な文字列」というものがそもそも存在しない

>・「危険な文字列」が適切にエスケープされている

>・エスケープ不可能な「危険な文字列」が存在するのでサニタイズが必要

>

>　のうち二番目のものについて、サニタイズを目的とした処理ではないとしても結果的にサニタイズされているのであり、サニタイズ処理であると言って良い、というのが私の見方です。

>　が、それはサニタイズではない、とするいう見方も可能だということですね。

そういう問題ではないのではないかと思います。

これまでの話では二番目のものについてはなにも述べていません。

「危険な文字列」というものがなぜ「危険」なのかを考えると、話のかみ合わなさの原因が見えそうな気がします。

蛇足かとは思いますが、先の定義は「鳩丸ぐろっさり (用語集)」からの引用です。

>高木さんが思っているサニタイズのイメージは「本来は必要ないがセキュリティ上の問題を解決するためだけに仕方なく入れる処理」というものだと思います。

　あ、なるほど。そう考えるとしっくり来ますね。

　私の中の「サニタイズ」の定義には「本来は必要ない」という部分が無かったので、そこが食い違っていたのでしょう。

>このことから、「危険な文字列」というものがない以上、本来的な意味でする特定の文字のエスケープはサニタイズに該当しない、として論理的に問題ないように思われますが、いかがでしょうか。

　うーん、結局はとらえ方の違いなのでしょうか。

・「危険な文字列」というものがそもそも存在しない

・「危険な文字列」が適切にエスケープされている

・エスケープ不可能な「危険な文字列」が存在するのでサニタイズが必要

　のうち二番目のものについて、サニタイズを目的とした処理ではないとしても結果的にサニタイズされているのであり、サニタイズ処理であると言って良い、というのが私の見方です。

　が、それはサニタイズではない、とするいう見方も可能だということですね。

私は『サニタイズって言うな』キャンペーンに激しく同意というか、以前から同じことを思っていましたが、皆さんそうでもないんでしょうか。

高木さんが思っているサニタイズのイメージは「本来は必要ないがセキュリティ上の問題を解決するためだけに仕方なく入れる処理」というものだと思います。というか私がそういうイメージを持っています。

XSSや各種インジェクション系などの脆弱性の原因となる特殊文字のエスケープし忘れというのは、つまるところバグです。セキュリティ上の問題とかいう前にまず正常に動作していないわけです。これらの問題が起こらないようにする処理は正常に動作させるために必要だから入れるのであり、セキュリティ上の問題のためだけに入れるものではありません。なのでこの処理のことを『サニタイズって言うな』と思うわけです。

正常に動作させるために必要な特殊文字のエスケープや除去処理のことをサニタイズと呼ばないとすれば、ほとんどのWebアプリではサニタイズは必要ないと言えるのではないでしょうか。

>>その感覚でいうと、

>>> 問題が起きる文字列をエスケープして処理する

>>というのはサニタイズには該当しないのではないかと思います。

>

>「サニタイズ」という観点からするとそれはサニタイズになっているのですが、そもそもそれは「サニタイズ」という観点から求められるべき事柄ではなくて、普通に行われているべきことだろう、という話……ですよね。

サニタイズの定義を

>プログラミングの用語としては、危険な文字列を含む「汚染された」入力から危険な文字を取り除き、無害化することを指します。

のようにしたならば、

>それが正しくできていれば、「悪意ある入力」というものは基本的にはその意図どおりの効力を持った状態では存在できなくなります。入力データに命令を紛れ込ませることはできなくなるからです。

このことから、「危険な文字列」というものがない以上、本来的な意味でする特定の文字のエスケープはサニタイズに該当しない、として論理的に問題ないように思われますが、いかがでしょうか。

>「サニタイズ」という観点から求められるべき事柄ではなくて、普通に行われているべきことだろう

このこと自体はそのとおりでしょう。

しかし、

>「サニタイズ」という観点からするとそれはサニタイズになっているのですが

上の論理で言えば、ここにいう「サニタイズ」は先の定義で述べられているものや、「必要性は本来ないはず」(高木さん)の「サニタイズ」とは別のものになっているように思われます。

>ちなみにそのサイト、一般的にはかなり信頼されているので、迷惑的な使い方をされると信用に傷がつくのではないかと思います。いちおう教えてあげた方がよいでしょうか？

　それはなんとも言いがたいです。

　どちらかというと、直接お知らせするよりも IPA に届け出る方がおすすめです。脆弱性なのかどうかという点も含めて判断してくれますし、無用な面倒に巻き込まれたりしませんので。

　ただ、様式に沿って届出を書くのはちょっと面倒くさいですが……。

>その感覚でいうと、

>> 問題が起きる文字列をエスケープして処理する

>というのはサニタイズには該当しないのではないかと思います。

「サニタイズ」という観点からするとそれはサニタイズになっているのですが、そもそもそれは「サニタイズ」という観点から求められるべき事柄ではなくて、普通に行われているべきことだろう、という話……ですよね。

>任意の内容を任意のメールアドレスに送れるのであれば、「メールの第三者中継」が可能ということになります。

パラメータにそれっぽいキーワードがたくさん含まれていたので、きっとそうだろうと思っていましたが、実際は任意の内容を送信できるわけではないようです。（じゃあ、何のためにあんなに怪しいパラメータが含まれていたのか謎すぎますが……）

いろいろ試してみると、そのサイトのドメインを含むURLしか送信できないようになっていました（ほっ）。ただ、そのサイトはリダイレクタを提供しているので、そのサイト内のページと見せかけつつ、全く別のページにリダイレクトするURLを送信させることができました。

ちなみにそのサイト、一般的にはかなり信頼されているので、迷惑的な使い方をされると信用に傷がつくのではないかと思います。いちおう教えてあげた方がよいでしょうか？

高木さんの言う「適切にプログラムを記述す」るというのは、データや命令等について、情報としてのメタレベルを適切に判断し、それらをそれぞれのメタレベルに合わせて適切に扱う、ということではないでしょうか。

それが正しくできていれば、「悪意ある入力」というものは基本的にはその意図どおりの効力を持った状態では存在できなくなります。入力データに命令を紛れ込ませることはできなくなるからです。そうであれば、「消毒」としてのサニタイズは必要ないはずです。

その感覚でいうと、

> 問題が起きる文字列をエスケープして処理する

というのはサニタイズには該当しないのではないかと思います。

>例えば"このサイトのURLを携帯に送信する"というフォームがあって、パラメータを改竄するとそのサイトのURLじゃないものを送信できるようになっていた場合、脆弱性になりますか？なるとしたらどういう分類になりますか？

　任意の内容を任意のメールアドレスに送れるのであれば、「メールの第三者中継」が可能ということになります。IPA に届け出ると脆弱性として処理されるはずです。

# しかし、改めて vuln2005q1.pdf をみたら、第三者中継って3件しか処理されてないんですね。意外に脆弱性と思われていないのかも。

やあ、それは任意のメールアドレスに任意の文章やデータを送れる上に送信者が自分の情報をけっこう秘匿できますね。スパムやフィッシングメールの送信に使うもよし、ウイルスを送りつけるもよし。特定の人物に嫌がらせのメールを延々と送りつけてもそのWEBアプリまでしかとりあえずはたどれません。

OPENなsmtpサーバより性質が悪い。

黒い夢が広がっちゃうなあ。

そのまま「任意の内容を送信できる脆弱性」と呼ぶしかないのでは。

送信内容が固定でなければ脆弱性は残ったまま。

パラメータ改竄の話なのですが、どこまでできれば脆弱性と呼べるのでしょうか？

例えば"このサイトのURLを携帯に送信する"というフォームがあって、パラメータを改竄するとそのサイトのURLじゃないものを送信できるようになっていた場合、脆弱性になりますか？なるとしたらどういう分類になりますか？

教えて君になっていてごめんなさい；

>記事のタイトルでは改定なのに、本文が改訂なのが微妙に気になります【謎】。

　意味的にはどちらでも通じるのですが、改訂に統一しておきました。