新生鳩丸掲示板♯

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

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

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

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

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

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

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

>

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

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

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

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

あ、すいません。

結核の集団検診での、数センチサイズの写真の話でした。

実際に医師に伺った話なんですが。

「あんな小さな写真でわかるはずないよ、ハッハッハ！」との事でした。

そんなものなんですね。

ちなみに彼のお孫さんは、個別に大きめなサイズで撮影してチェックされているそうです。

1.0.6で修正は入ったはずなのですがまだクラッシュしますね。

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

>>

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

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

>

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

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

御意。

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

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

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

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

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

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

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

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

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

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

>

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

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

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

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

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

>

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

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

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

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

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

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

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

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

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

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

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

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

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

例によって蛇足すると、

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

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

これらの文は、

「それらの対処をひとくくりにサニタイズと呼んでしまうと」「思考停止」に陥る結果「本来なすべき事柄が正確に理解されないまま放置されるから」「根本的な問題の解決から離れてしまう」と危惧される、という意味で読んでほしいと思いました(ニュアンスは微妙に異なってしまいますが)。

文章がわかりにくくてすみません。というか私の文章って、論理的なつながりがそもそも期待できないくらいマズいですか？本気で不安です。

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

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

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

　ガイドラインには

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

きること）

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

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

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

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

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

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

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

>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])に答えを出してから考えても遅くないと思います。

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

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

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

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