水無月ばけらのえび日記

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

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

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

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

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

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

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

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

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

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

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

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

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

その感覚でいうと、

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

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

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

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

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

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

>その感覚でいうと、

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

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

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

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

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

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

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

>>その感覚でいうと、

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

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

>

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

サニタイズの定義を

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

のようにしたならば、

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

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

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

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

しかし、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>

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

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

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

>

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

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

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

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

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

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

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

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

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

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

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

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

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

>

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

たとえば、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>

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

Google先生ですか? 【謎】

ご参考【謎】:

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

>Google先生ですか? 【謎】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　高木さんのお話でも、

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

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

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

>ところでIPAは本名でないと届出を受理してくれないそうですね。

　実は受理される、に一票。

　統計公表時に「本名が書かれていなかったので不受理としたものが 1件あった」とか言われたら、それはそれで面白いと思います。:-)

>PGPのことも知らないし、https://isec.ipa.go.jp/inq/menu/index.jspはJavaScript有効でないと動かないし……。届出、微妙かも。

　その点は確かにハードルが高いと思います。

　フォームがスクリプト無効で動かないことについては私も指摘したのですが、いまだに改善されていないみたいですね。HTML をローカルに保存して「巧みに改変」すれば送信できると思いますが、それはそれで危険ですし……。

>PGPのことも知らないし、

そういえば【謎】keiさん【誰】もしきりにGnuPGを勧めているわけですが、

http://www.nantoka.com/~kei/diary/?200506a&to=200506081#200506080

GnuPGのバイナリ自体を安全に入手する方法について言及を避けているあたりが残念です【謎】。

たとえば【謎】

http://www.gnupg.org/(en)/download/integrity_check.html

にはSHA1署名を下に貼ってあるから確かめろと書いてるわけですが、これ見てなんの疑問も抱かない人【誰】に総務省のオレオレ証明書とかを叩く資格はないと思います。

ご参考【謎】:

http://takagi-hiromitsu.jp/diary/20050628.html#p01

GnuPGのインストールって簡単ですね【謎】。

>SHA1署名

何か意味の分からないことを書いてますがSHA1ハッシュと言いたかったのでした。

結局、高木さんがなぜ『サニタイズって言うな』キャンペーンを行っているのか、りゅうさんが何にどういう思いで「激しく同意」しているのか、そういったところが腑に落ちていないままなのではないかと想像してしまうのですが、勝手な妄想でしょうか。

私は、そこには、無知、誤解、甘え、といったことに対する怒りがあるのではないかと思っています。

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

とのことなので、ここで終わるということであれば、それはそれで私はかまいません。

>結局、高木さんがなぜ『サニタイズって言うな』キャンペーンを行っているのか、りゅうさんが何にどういう思いで「激しく同意」しているのか、そういったところが腑に落ちていないままなのではないかと想像してしまうのですが、

　[No.3053]のりゅうさんの投稿は非常に明確で分かりやすいと思いますし、私のコメントも「なるほど」というものなのですが、どこか腑に落ちていなさそうな要素がありましたでしょうか。

　むしろ、名無しさんの方が腑に落ちていないように見受けられますが……。おそらく、名無しさんは「既存のサイトに対して、そのセキュリティ対策として『サニタイズ』を行う」という場合であっても「サニタイズ」という発想は不適切であるという立場であって、その点では高木さんとも立場を異にしているのではないかと想像しましたが、そのあたりどうなのでしょうか。

　蛇足かもしれませんが補足しておきますと、私は別に「サニタイズ言うな」に反対しているわけではありませんし、むしろ賛同しています。

　多分に想像を含むので日記には書きませんでしたが、高木さんの「キャンペーン」から私が連想したのは

ウェブサイトのセキュリティ対策の再確認を ～脆弱性対策のチェックポイント～

http://www.ipa.go.jp/security/vuln/20050623_websecurity.html

　という文書でした。

　この文書に対してセキュリティホールmemo のこじまさんは http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/06.html#20050623_IPA で「出力時の無害化は?」とコメントしています。さらに http://www.st.ryukoku.ac.jp/~kjm/security/ml-archive/memo/2005.06/msg00045.html でコメントがついていますが、はっきり言ってこの項目は分かりにくいと思うのです。私も、「少なくとも技術者向けではない」と感じました。

　それは何故なのかというと、ここでは「無害化」の具体的な例が挙げられていないからなのだと思います。入力時に無害化するのか出力時に無害化するのか、何をどう無害化するのか、というような具体的な内容が何もないので、経験のない現場の技術者がこれをこのままぶつけられても困るでしょう。

　このような場面において「サニタイズ言うな」というキャンペーンは大きな意味を持つはずです。

>　[No.3053]のりゅうさんの投稿は非常に明確で分かりやすいと思いますし、私のコメントも「なるほど」というものなのですが、どこか腑に落ちていなさそうな要素がありましたでしょうか。

その「なるほど」が、高木さんのサニタイズという言葉の定義がばけらさんの定義と異なっているという部分にしかかかっていないように見えたからです。なぜ食い違っているのかを措いてそこで安心しているように私には見えました。

「なぜ」りゅうさんが『サニタイズって言うな』キャンペーンに激しく同意しているのかは別の問題だと思います。

また、高木さんにしても、問題がばけらさんの日記とこれまでの投稿の内容に示されるようなことなら、キャンペーンを張るほどのことはないのではないかと思います。

>　むしろ、名無しさんの方が腑に落ちていないように見受けられますが……。おそらく、名無しさんは「既存のサイトに対して、そのセキュリティ対策として『サニタイズ』を行う」という場合であっても「サニタイズ」という発想は不適切であるという立場であって、その点では高木さんとも立場を異にしているのではないかと想像しましたが、そのあたりどうなのでしょうか。

私も現実的な問題として、パッチとしてのサニタイズの有用性を否定しているわけではありませんし、どのようなケースでもサニタイズが完全に必要ないかという問題についても答えを持っているわけではありません。

ただ、ばけらさんがケースとして挙げられた単引用符のような問題については、これをサニタイズと呼ぶのは適切でないと考えています。そしてこの立場は高木さんと同じなのではないかと想像しています。

ちなみに、これまでの投稿で私の立場を表明したことはなかったと思います。

ところで、ひとつ質問があるのですが、

私の最初の投稿の

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

の意味は伝わったでしょうか？

決してわかりやすい表現ではなかったと思うので確認させてください。

これこそ蛇足だと思いますが、この内容がそれに続く

>それが正しくできていれば、...

および

>その感覚でいうと、

の前提となっています。

>　高木さんのお話でも、

>

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

>

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

「既存の」とか「新規の」という条件は要らないと思います。

バグにより生じる脆弱性の場合、「バグを修正する」「脆弱性を無くす」という2通りのに対処方法が考えられます。セキュリティ屋としては脆弱性を無くすという考え方で問題ありませんが、開発者としてはバグを修正すると考えるべきです。そうしないと根本的な問題が放置されてしまう可能性がありますし、バグとして扱えば最初から出さないように注意することも期待できます。

動作上必要な処理と、脆弱性を無くす為の処理を同じように「サニタイズ」と呼んでしまうと、このような考え方をするのを阻害してしまいます。セキュリティ屋的にはバグが原因かどうかはどうでも良いことなので両方ともサニタイズであっても問題無いですが、開発者的にはそれが大変重要な点なので、前者はサニタイズではないのです。

なので区別されているのはセキュリティ屋と開発者です。

「特に新規にシステムを開発するような局面において」という前置きも、「新しく作る場合くらいちゃんと作ろうよ」ということで、そんな深い意味は無いような気がします。

>「既存の」とか「新規の」という条件は要らないと思います。

　御意。まあ枕詞と思ってください。

>動作上必要な処理と、脆弱性を無くす為の処理を同じように「サニタイズ」と呼んでしまうと、このような考え方をするのを阻害してしまいます。セキュリティ屋的にはバグが原因かどうかはどうでも良いことなので両方ともサニタイズであっても問題無いですが、開発者的にはそれが大変重要な点なので、前者はサニタイズではないのです。

>なので区別されているのはセキュリティ屋と開発者です。

　全くその通りだと思います。というか、私もそういうことを言っていたつもりですが、ちょっとアレだったようで。

>また、高木さんにしても、問題がばけらさんの日記とこれまでの投稿の内容に示されるようなことなら、キャンペーンを張るほどのことはないのではないかと思います。

　では、名無しさんはもっと違うところにもっと重要な「問題」があると考えられているわけですね。もしよろしければ、ご説を披露していただけませんか?

>ただ、ばけらさんがケースとして挙げられた単引用符のような問題については、これをサニタイズと呼ぶのは適切でないと考えています。

　それは申し訳ないです。実は、単引用符は例として不適切だったと後悔しています。あの例は、まさに「見方によってはサニタイズではないと考えられ得る例」であり、しかも「傍目からもエスケープで足りると判断できる例」だったからです。

　実際にはこのような明確にエスケープが必要なところではなく、たとえば店の ID をデータベースに渡すような微妙なところでインジェクションが発生したりします。そのような場合、必ずしも SQL 文レベルでの「エスケープ」が正しい対処法ではなく、たとえばその前の段階で「指定された ID が不正です」のようなエラーを出すことが適切であることもあるでしょう。この両者の処理を統括する呼称としては、今のところ「サニタイズ」以外に適切なものが思いつきません。

>ちなみに、これまでの投稿で私の立場を表明したことはなかったと思います。

　そのつもりではないのでしょうが、

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

　というご質問から、名無しさんは「どのような文字列も潜在的に危険」という考え方には与さない立場で話されているのだと理解しました。そう判断したことによって名無しさんの言われていること全てに筋が通りましたので、私はそこですっきりしたのです。

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

>の意味は伝わったでしょうか？

　特に難しい表現ではないと思うので、私は私なりに理解できたつもりではあります。しかし、名無しさんの意図と一致しているかどうかは分かりません。

　伝わっているかどうか怪しいと思われているのであれば、例を挙げて説明していただけると分かりやすいかと。

http://www.nantoka.com/~kei/diary/?200507b&to=200507172#200507172

> もちろん、

(snip)

> という指摘がされているが、

通信路のすり替えがありうるなら受信したメールだってぜんぜん信頼できないと思いますが、https経由のWebメールとかで受信すれば近傍での通信路のすり替えで一斉にやられることはありませんから複数のサイトにフィンガープリントを掲示して「対策」した総務省よりはマシですか。

> 企業でGnuPGを導入する場合は、この辺りの扱いの難しさがあることは感じる。

というかこの期に及んでS/MIMEのことに微塵たりとも触れてないのが謎ですが、何か自己復号実行ファイル並に致命的な欠陥でもあったりするのでしょうか。

>>　高木さんのお話でも、

>>

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

ところで、これって肯定してますかね？

すこし屈曲した表現に見えなくもないですが。

>なので区別されているのはセキュリティ屋と開発者です。

そうなると、サニタイズって言っちゃいけないのは「開発者」に限ってしまうということになるんでしょうか。

「発想としては極めて自然」というのを限定的に捉えた上で、開発時から(あるいはその前から啓蒙者として)携わるセキュリティアドバイザも含めて関係者全員に「ちゃんと作ろうよ」を呼びかけていると考えるとすっきりするんですが…。

>　では、名無しさんはもっと違うところにもっと重要な「問題」があると考えられているわけですね。もしよろしければ、ご説を披露していただけませんか?

言葉足らずは後で足すとして短く言うと、これまでに例としてあがったような問題に対処するときに、それらの対処をひとくくりにサニタイズと呼んでしまうと、りゅうさんの言われるように根本的な問題の解決から離れてしまう、という危惧があるのだと思います。

本来なすべき事柄が正確に理解されないまま放置されるからです。すなわちここで指摘されているのは「思考停止」です。

>>ただ、ばけらさんがケースとして挙げられた単引用符のような問題については、これをサニタイズと呼ぶのは適切でないと考えています。

>

>　それは申し訳ないです。実は、単引用符は例として不適切だったと後悔しています。

その点については了解しました。

>　実際にはこのような明確にエスケープが必要なところではなく、たとえば店の ID をデータベースに渡すような微妙なところでインジェクションが発生したりします。そのような場合、必ずしも SQL 文レベルでの「エスケープ」が正しい対処法ではなく、たとえばその前の段階で「指定された ID が不正です」のようなエラーを出すことが適切であることもあるでしょう。この両者の処理を統括する呼称としては、今のところ「サニタイズ」以外に適切なものが思いつきません。

そのとおりかもしれませんし、別の適切な呼び名や別の概念の異なる考え方があるかもしれません。

もうひとつの質問([No.3072])に答えを出してから考えても遅くないと思います。

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

>　というご質問から、名無しさんは「どのような文字列も潜在的に危険」という考え方には与さない立場で話されているのだと理解しました。

これは反語のように見えるかもしれませんが、単純な選択肢の提示です。

事実私自身、どのような文字列も潜在的に危険という考え方はありうると思っています。ただし、その理解の仕方はこれまでに述べてきた私の想像する高木さんの考え方と相反するものではないとも思っています(この文が混乱をもたらすようなら忘れてください。これは傍論です)。

　spamチェックが誤爆していましたので復活させておきました。

　しかし、なんでこれが……。ちょっとチェックルールを見直します。

>言葉足らずは後で足すとして短く言うと、これまでに例としてあがったような問題に対処するときに、それらの対処をひとくくりにサニタイズと呼んでしまうと、りゅうさんの言われるように根本的な問題の解決から離れてしまう、という危惧があるのだと思います。

　それは私の考えとほとんど同じだと思いますが、

>本来なすべき事柄が正確に理解されないまま放置されるからです。すなわちここで指摘されているのは「思考停止」です。

　ここはちょっと違いますね。少なくとも該当の記事の中では、「放置される」という現象が起きるとは述べられていないように思いますし、高木さんの上げられているケースでも、「セキュリティ上の問題が存在しており、解決する必要がある」というところまでは正しく伝わっているのではないかと考えます。

>これは反語のように見えるかもしれませんが、単純な選択肢の提示です。

　なるほど了解です。早とちりしたようで、すみません。

　ところでスレッドが長くなってきましたが、私なりのまとめを

http://bakera.jp/hatomaru.aspx/ebi/topic/2377

　に書きましたので、よろしければそちらで続けていただければと思います。よろしくお願いします。

>　実は受理される、に一票。

というわけで（謎）、めでたく不受理となりました。これはこれで面白い結果なのかも……

>>　実は受理される、に一票。

>というわけで（謎）、めでたく不受理となりました。これはこれで面白い結果なのかも……

　なんと、そうなりましたか。

　ガイドラインには

>匿名の届出でないこと（発見者への連絡が可能であることを確認で

きること）

　という要件があるのですが、どうせメールでしか連絡は取らないのですし、メールが届きさえすればそれで良いのではないかと思ったのですが。

>メールが届きさえすればそれで良いのではないかと思ったのですが。

"責任ある届出を促すため"だそうですが、自衛の必要がありますから、本名は入力できませんねぇ。

と今気づいたのですが、件名"【IPA#04003329】 届出に関するお願い"と本文"このメールは、取扱い番号 IPA#03343976 に関する連絡です。"で番号が違っているのが謎でした。

>　実際にはこのような明確にエスケープが必要なところではなく、たとえば店の ID をデータベースに渡すような微妙なところでインジェクションが発生したりします。そのような場合、必ずしも SQL 文レベルでの「エスケープ」が正しい対処法ではなく、たとえばその前の段階で「指定された ID が不正です」のようなエラーを出すことが適切であることもあるでしょう。この両者の処理を統括する呼称としては、今のところ「サニタイズ」以外に適切なものが思いつきません。

毒が入っているから食べずに全部捨てるというのを無毒化/消毒というのは変と思うのは私だけでしょうか。

毒入りのデータを使って中ったりしないよう、毒の部分を除去したり変化させたりする変換処理のことをサニタイズと言うのであって、変換したりしない場合はサニタイズとは言わないような気がします。

毒入りだったら食べずに全部捨てるというのは入力値チェックとかvalidationとか呼ばれているような気がします。

ちなみに ID など番号の場合でも、数字以外の文字は全部捨てるという事を行えばサニタイズで対処できます。

無意識のうちにこのサニタイズを避けるのは、むちゃくちゃ気持ち悪い動作になるからでしょう。

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

>

>ところで、これって肯定してますかね？

>すこし屈曲した表現に見えなくもないですが。

渋々っぽい感じはありますが、だからといって否定しているとは言えないでしょう。

というかその部分は「開発者的にはなんでもサニタイズで解決という発想はよろしくない。そもそもバグだし」というのの前振りなだけなので、そこにこだわっても仕方が無いような気がします。

>>なので区別されているのはセキュリティ屋と開発者です。

>

>そうなると、サニタイズって言っちゃいけないのは「開発者」に限ってしまうということになるんでしょうか。

セキュリティ屋が脆弱性のことをさておいてバグだバグだと言っているというのは存在意義的に変なので、啓蒙の対象とするのはお門違いではないでしょうか。

>「発想としては極めて自然」というのを限定的に捉えた上で、開発時から(あるいはその前から啓蒙者として)携わるセキュリティアドバイザも含めて関係者全員に「ちゃんと作ろうよ」を呼びかけていると考えるとすっきりするんですが…。

誰がプログラマにきちんと伝えていくのか明示されていないので謎なのですが、バグ、つまり仕様を満たしていない動作を指摘できるのは設計した人なので、私はSEなど設計した人がきちんと伝えていくべきだと解釈しました。もちろん、バグだからちゃんと作りましょうと指摘してくれるセキュリティ屋は良いセキュリティ屋ではありますが、セキュリティ屋にそれを望むのは贅沢な悩みという感じがします。

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

>>

>>ところで、これって肯定してますかね？

>>すこし屈曲した表現に見えなくもないですが。

>

>渋々っぽい感じはありますが、だからといって否定しているとは言えないでしょう。

>というかその部分は「開発者的にはなんでもサニタイズで解決という発想はよろしくない。そもそもバグだし」というのの前振りなだけなので、そこにこだわっても仕方が無いような気がします。

御意。

>セキュリティ屋が脆弱性のことをさておいてバグだバグだと言っているというのは存在意義的に変なので、啓蒙の対象とするのはお門違いではないでしょうか

これにはちょっと違和感があります。

バグだバグだと言えといっているわけではなく「本来やるべき処理が何かを」「サニタイズ」と言わずに伝えろと言っているのだと捉えられますから。しかもこの文脈において脆弱性をさておく必要は無いわけですし…。

これは穿ちすぎを承知で言うのですが、高木さんの「不満」はIPAに向けられているような気のせいがとてもしています。IPAに「サニタイズって言うな」と。IPAの立場は開発者というよりはセキュリティの専門家でしょうか。

>誰がプログラマにきちんと伝えていくのか明示されていないので謎なのですが、

そうそうそう、私もそこが気になっているのですよ。誰が伝えていくのか。

ちょっと冒険っぽいですが、「伝えていく」というのを「技術を伝承する」というような意味で解釈できないでしょうか。

「ここに集ったみなさんも伝承者となったのですからみなさん伝道よろしく」みたいな。

ちなみにそう解釈したとしたら「本来やるべき処理が何か」は具体的な仕様とその実装ではなく、たとえば「文字列を扱う仕様に従った適切なエンコードをしなさい」とかいった抽象的なことになりますから、伝道者は設計者である必要はなくなります。

>これにはちょっと違和感があります。

>バグだバグだと言えといっているわけではなく「本来やるべき処理が何かを」「サニタイズ」と言わずに伝えろと言っているのだと捉えられますから。しかもこの文脈において脆弱性をさておく必要は無いわけですし…。

要はその役割をセキュリティ屋に望むのは筋が違うんじゃないかということです。

望むのなら開発者にセキュリティ的な問題把握能力を望むべきでしょう。開発者にそれができなかったからセキュリティ屋というのが居るわけで、さらにプログラミングの知識まで頼ってしまったら、開発者としての立つ瀬がなくなってしまうではありませんか。そもそもバグなのですから、それを修正するためにセキュリティ的な知識は要らないのです。

>これは穿ちすぎを承知で言うのですが、高木さんの「不満」はIPAに向けられているような気のせいがとてもしています。IPAに「サニタイズって言うな」と。IPAの立場は開発者というよりはセキュリティの専門家でしょうか。

写真のスライドに書いてある文句を読むと対象は開発者という感じがします。

>>誰がプログラマにきちんと伝えていくのか明示されていないので謎なのですが、

>

>そうそうそう、私もそこが気になっているのですよ。誰が伝えていくのか。

>ちょっと冒険っぽいですが、「伝えていく」というのを「技術を伝承する」というような意味で解釈できないでしょうか。

>「ここに集ったみなさんも伝承者となったのですからみなさん伝道よろしく」みたいな。

その解釈だと「特に新規にシステムを開発するような局面において」という前置きが無意味になってしまうので駄目っぽい感じがします。伝承は新規開発の時でなくてもできますし。

>要はその役割をセキュリティ屋に望むのは筋が違うんじゃないかということです。

>望むのなら開発者にセキュリティ的な問題把握能力を望むべきでしょう。開発者にそれができなかったからセキュリティ屋というのが居るわけで、さらにプログラミングの知識まで頼ってしまったら、開発者としての立つ瀬がなくなってしまうではありませんか。そもそもバグなのですから、それを修正するためにセキュリティ的な知識は要らないのです。

なるほど。そのとおりかもしれません。

最初このキャンペーンを「サニタイズ」と呼ぶことによるミスリードに警鐘を鳴らしている、ととらえたのですが、そこを引っ張りすぎたかもしれません。

あえて自分のほうに引き寄せた表現をすると「サニタイズ言うな」はすべての人に対する呼びかけだが、その本質を理解するのは開発者だけで十分、と。

>>これは穿ちすぎを承知で言うのですが、高木さんの「不満」はIPAに向けられているような気のせいがとてもしています。IPAに「サニタイズって言うな」と。IPAの立場は開発者というよりはセキュリティの専門家でしょうか。

>

>写真のスライドに書いてある文句を読むと対象は開発者という感じがします。

ここで私が言うのは、これが IPA に対する「あてこすり」になっている、ということです。そのような意図があれば、この章全体がわかりにくくなっているのもうなずけるというものかな、と。

「サニタイズしてなかったんだな」というのはまさに IPA の言いそうなことではありませんか。よくは知りませんが。

でもそう考えると逆に、おもての対象は開発者でいいのかもという感じもしますね。

しかしここまで穿つと、りゅうさんが激しく同意した高木さんの「発想」を説くのは別としても、文章の解釈そのものの意義がなくなってしまいますか……。

一応「サニタイズ言う」ことによって開発者をミスリードするのはやめてくれと主張しているのだろう、という点の賛否に関しては存在意義は残ってますか。ばけらさんのまとめにはその観点はないようなので。

>>ちょっと冒険っぽいですが、「伝えていく」というのを「技術を伝承する」というような意味で解釈できないでしょうか。

>>「ここに集ったみなさんも伝承者となったのですからみなさん伝道よろしく」みたいな。

>

>その解釈だと「特に新規にシステムを開発するような局面において」という前置きが無意味になってしまうので駄目っぽい感じがします。伝承は新規開発の時でなくてもできますし。

冒険なのでこだわってもしょうがないのですが、それこそりゅうさんの言われるように深い意味はないと思いますから、「機会をとらえて」というくらいの意味でいいんじゃないでしょうか。

伝承そのものは地道に脈々とおこなわれるべきですが、伝道にはパフォーマンスが期待されますし。