新生鳩丸掲示板♯

>その「放置される」というのは、私の書いた「放置される」と違っているような気がするのですが、そんなことないですか？

「放置される」=何も対策がなされない、と理解しましたが、違いましたか。「適切な」対策がなされない、という意味で「放置」と言われているのであれば、それはそれで正しいのではないかとも思います。

>ところで、「高木さんの上げられているケース」というのはどれのことでしたっけ？

「開発者にとっては綺麗にプログラムを書くことが大命題であり、セキュリティ屋が(セキュリティ関連の)問題を指摘してくると『プログラムが汚くなる』としてそれを嫌う人が多い」

　という話です。「汚くなる」という反発があったとしても、脆弱性が存在するということ、対応が必要であるということは伝わっているのではないかと思うのです。

　適切な対応が出来るかどうか、という点がまさに問題になるのですが、何らかの対応が行われるということは期待してよい状況のではないかと思いました。

>http://www5a.biglobe.ne.jp/~mkh-isii/?NL000214-173

　興味深いですね。情報ありがとうございます。

　こんな認定がされちゃっていますが、

>本件レントゲン写真が定期健康診断において撮影された他の数百枚のレントゲン写真と同一機会に、当該被験者に関する何らの予備知識も無く読影された場合には、当時の一般臨床医の医療水準を前提にすれば異常を発見できない可能性の方が高いことが認められる

　レントゲン撮っても異常を発見できない可能性の方が高いって……。

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

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

>このページを先に見てしまったので、何か作意的なものを感じてしまいます…。実際のところはどうなんでしょうね。

>http://www5a.biglobe.ne.jp/~mkh-isii/?NL000214-173

その「?NL000214-173」というのはアフィリエイトIDか何かですか【謎】。

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

>

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

その「放置される」というのは、私の書いた「放置される」と違っているような気がするのですが、そんなことないですか？

ところで、「高木さんの上げられているケース」というのはどれのことでしたっけ？

ここにこの投稿をくっつけると話が唐突になるかもしれませんが、続きで読んでもらっていると期待して…

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

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

>

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

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

引き続き SQL 文を例として使います。すでに特定の文脈で例として適切でなかったとありますが、このことが説明の障害にはならないと考えています。

ここでは文字集合とその符号化方式について考えます。

SQL 文を発行するときには、その文を書くために使える文字集合と符号化方式がそのプロセッサの仕様として定義されているはずです。同一の機能を実現するための手段が複数あったとしても、それは定義されています。

その SQL 文において、文字列リテラルとして使える文字集合と(広い意味での)符号化方式は SQL 文そのものに使えるそれらとは異なっているのが通常です。そうでなければ、たとえば(文字列を固定長とするなどの他の手段を用いない限り)文字列リテラルの終了をプロセッサが認識できないからです。こちらの文字集合と符号化方式もプロセッサの仕様として定義されているはずです。

この文字集合と符号化方式のセットが文字列リテラルの書式の一部を構成しています。

SQL 文を書くときには、この書式を守らないことには話になりません。つまり SQL 文のプロセッサには、そのプロセッサの仕様に従った文字集合と符号化方式に従ったデータを渡す必要があるわけです。このこと自体には異論はないと思います。

これに対して、フォームで文字列を入力として受け取る事を考えます。

その文字列の文字集合と符号化方式は上の SQL 文のプロセッサの仕様とはまったく関係のないところで決まります。

その文字列を SQL 文のプロセッサに渡すためには、当然、調整が必要になります。

入力文字列をその符号化方式に従ってデコードし、それを SQL 文のプロセッサの仕様に従った文字列リテラルにエンコードして SQL 文を構成する必要があります(コード上は明示的におこなわれないことがあるかもしれませんが、その場合でも暗示的にはおこなわれており、抽象的には必須の過程です)。

ここで具体的にこれらの文字集合と符号化方式を見ると、それらはそれぞれかなりの部分が重なって、ほとんど同じになっているケースも多いのではないかと思います。

しかし実際にはそれらはそれぞれに固有で別個のものです。特に入力文字列と文字列リテラルのそれはほぼ確実に内容も異なります。

これが何を表すのかは必要ならば後で述べますが、必要ないかとも思います。

「単引用符がそのまま SQL に渡る」のような表現は上記の観点からはあいまいな表現になってしまっていると思われます。

SQL 文のプロセッサが文字列リテラルに使えると定義する文字集合が単引用符を含む限り、「文字としての」単引用符はそのまま渡せるわけです。適切な符号化方式が使われている限り。

符号化方式を無視して何らかのビット列をそのまま SQL 文のプロセッサに渡したとしたら、それはむしろきっと意味的には同じデータをそのまま渡せていないことになります。

とりあえず、ここまででコメントいただけますか？

このページを先に見てしまったので、何か作意的なものを感じてしまいます…。実際のところはどうなんでしょうね。

http://www5a.biglobe.ne.jp/~mkh-isii/?NL000214-173

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>

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

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

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

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

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

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

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

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

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

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

>>

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

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

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

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

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

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

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 でコメントがついていますが、はっきり言ってこの項目は分かりにくいと思うのです。私も、「少なくとも技術者向けではない」と感じました。

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

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