新生鳩丸掲示板♯

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

>>

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

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

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

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

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

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

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

> もちろん、

(snip)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>　高木さんのお話でも、

>

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

>

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

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

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

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

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

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

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

私の最初の投稿の

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

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

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

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

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

および

>その感覚でいうと、

の前提となっています。

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

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

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

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

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

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

>SHA1署名

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

>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のインストールって簡単ですね【謎】。

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

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

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

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

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

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

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

　今のところ私は特に「主張」はしていないのですが、この質問でよく分かりました。この質問に 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 に渡ることはありませんので、改めてサニタイズする必要は無いといえます。