がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

覆水は盆に返せるのか?

発端はまぁまた色々あるのですが、他でも出てくる切り口で「非常に気になる」話があったので。
前提として
http://takagi-hiromitsu.jp/diary/20120504.html
を読んでおいてもらえたりすると、色々と話がスムーズな気がいたします。


とりあえず直接的な考察のきっかけとしては、
https://twitter.com/#!/TakaFlight/status/198666924425625600
にある
https://www.facebook.com/hhokamura/posts/329492283788026
の内容。
ログインせんでも見られたので「公開情報」だとは思うのですが。「後で改変または削除」の可能性も一応念頭に入れて、念のために全文引用。

あちこちで話題になっているが、またその多くで見られる典型的オプトイン国民の言動が悲しい。
まだ行動を起こす前に、素早く先回りして「問題になるかもしれない」点を一所懸命に探して指摘する。それが得意な人の多いこと、多いこと。
そりゃあ、新しいことをやるわけだからこれまでと比べて問題がゼロってことはあり得ないし、多分やってみたら気付かなかった新しい問題が出てきますよ。逆に、それが新しいことである証明でもあると思う。
だいたい、日本中の図書館をcccで運営するっていうならともかく、九州の中のたった一カ所、人口5万人の市で、ちょっと変わった市長(笑)が新しいことをやってみるっていう程度なんだから。なので、大きな問題がなさそうならば、まあみんなで見守りながら「まずはやってみて」、そして何か問題が出てきたら素早く修正して行く、でいいじゃないですか。(それがオプトアウト的な考え)
こうやっていくからこそ、シリコンバレーではどんどん新しいものがうまれ、新しい産業が育ち、新陳代謝が起こる訳ですよ。
新しいことはなにかメリットがありそうだからやるわけでしょ。で、今回もいろんなプラス効果が期待できることは普通の想像力のある人ならだれしも分ると思う。それがわかっているくせに、でも、まずは新たに起こる可能性のある問題点を口にする。そして、それがメディアで報道されると、もしかしたらこれ怖いかもしれないと(それまで思ってもなかったのに)急に不安がって同調しだす人々がいる。がん保険トップセールスマンみたい。
皆さんももしかしてこんな気分になったら 村上 憲郎 さんのこの記事でも読んで「いかん、いかん、またうっかり日本社会に毒さるところだった」と正気に返ってほしいです〜


http://www.toyokeizai.net/business/column/detail/AC/efe0db5b99f8bd63084478b7ffefacdd/page/1/


ん…端的には「PDCAぶん回せば良いモノと、それではまずいモノがある」というのがおいちゃんの主張ざんす。
「オプトインを辞めてオプトアウトしよう」については少々、オプトアウトの単語に思うところがあるんだけど、その辺は http://d.hatena.ne.jp/gallu/20120328/p1 を参照されたし。

まあみんなで見守りながら「まずはやってみて」、そして何か問題が出てきたら素早く修正して行く、でいいじゃないですか。

に対して、別に「全面的に不同意」というわけではないです。実際問題「やってみないと分からない」部分ってのは実際に多々あって、故に開発においても「イテレーションをこまめに回してPDCAを高速でぶん回して速やかに起動修正できる」事は大切ですし、作成物は「適切なコスト(工数工期)で変更可能」なようにDRYな作りにしたり、ってのはとても大切なので。


ただ、ここでは一点、非常に重要な事が(今回の図書館騒ぎでは)抜けてるんじゃないかなぁ、って思うです。


もう一度、前提条件を見てみましょう。
・大きな問題がなさそうならば
・問題が出てきたら
・素早く修正


ん…もうちょっと細かく。
・大きな問題がなさそうならば
・問題が発生して
・「発生した問題」を適切に認識できて
・素早く修正


ここで、おいちゃんが気になる各所。
まず「大きな問題がなさそうならば」って前提があるのですが、ナニをもって大小をはかるんでしょうか?*1
つぎに。よく皆さん「問題が発生したら」というですが、実際には「問題が発生したことが認識できたら」ってのが正しいです。セキュリティ系のニュースまじめにチェックしてれば、「進入は一週間前だった」とか「調べたら一ヶ月前から進入されていたようだ」とかって発言があるからちっとは想像付きそうなものなんですが。
で、ここで問題になるのが「どうやって問題の発生を認識するに至るか」。外部から親切な人が「なんか問題おきてるぽいですよ〜」って言ってくれるのを待つばかり? それともきちんとした「監視機構」がある? あるんなら、それは「どんな」?
最後に「素早く修正」っていうけど、どうやって?


一つ。ここで「考察の指針になる」お話を。
アキバ署、という漫画がありまして、それの第一話が、大変にわかりやすい「考察のベース」になります。
おいちゃんも大分かたうろ覚えで書きますんで、興味がある方は是非漫画本をご覧ください。…中古しか出回ってなさそうなのが残念なところではありますが。


まぁ端的には「彼氏にハメドリされちゃった」女子高生がいるのですが(撮影自体は、プライベートなモノってことで一応合意)。
彼氏だったかその友人だったかが、故意か事故かは覚えてませんが、P2Pファイル共有系(ようはWxxxy)にファイルをあげちゃうです。
彼女は「他の人から」それを教わり、まぁ彼氏はボコンボコンにされかけるのですが(割とがっつりやられてた記憶が…確か剣道部の女の子だったので)。
問題は「流出したハメドリビデオ」。
警察の(ITに鬼強いという設定の)婦警さんとのやりとり。

高)「……あ あの」
高)「そ そのファイルってケーサツの力とかで」
高)「消せ……るんですか?」
警)「残念……だけど」
高)「……そう」
高)「ですよね」

ラストだけはまぁ「比較的漫画チックな」力技が出てきますが。
「ネットで一度流布したものって、もはや誰にも食い止めることができない」ってのは、基本として認識をしておくとよいです。


もう一つ。
「図書館学」って単語は初めて今回知ったのですが。
いわゆる「司書」さんたちの感覚的に、閲覧履歴は「個人情報の中でも結構デリケートなもの」に属し、「誰が何を借りたか」という情報は「警察でもNG、裁判所介入で初めて出す」くらいにセンシティブなもの、らしいです。
まぁ「借りた本で思想が分かり、そこから思想差別とかにつながる」という話を聞くと、あながち「がちがちすぎない?」と断じれるものでもないのだろう、と思います。
あと、「図書館の自由に関する宣言」というものがあるらしく。
http://www.jla.or.jp/portals/0/html/ziyuu.htm

第3 図書館は利用者の秘密を守る
 読者が何を読むかはその人のプライバシーに属することであり、図書館は、利用者の読書事実を外部に漏らさない。ただし、憲法第35条にもとづく令状を確認した場合は例外とする。
 図書館は、読書記録以外の図書館の利用事実に関しても、利用者のプライバシーを侵さない。
 利用者の読書事実、利用事実は、図書館が業務上知り得た秘密であって、図書館活動に従事するすべての人びとは、この秘密を守らなければならない。

とあります。
まぁここまでがっつり、且つど真ん中に書かれているってことは、それだけ「大切な理念なのだろうなぁ」と思われます。


ここら辺を前提に。



さて、話を戻して。
もう一度、この文章を真摯に検討してみましょう。

そりゃあ、新しいことをやるわけだからこれまでと比べて問題がゼロってことはあり得ないし、多分やってみたら気付かなかった新しい問題が出てきますよ。逆に、それが新しいことである証明でもあると思う。
だいたい、日本中の図書館をcccで運営するっていうならともかく、九州の中のたった一カ所、人口5万人の市で、ちょっと変わった市長(笑)が新しいことをやってみるっていう程度なんだから。なので、大きな問題がなさそうならば、まあみんなで見守りながら「まずはやってみて」、そして何か問題が出てきたら素早く修正して行く、でいいじゃないですか。(それがオプトアウト的な考え)


今回問題になっている「Tカードの利用」は、それによって
http://takagi-hiromitsu.jp/diary/20120504.html

これね、今までね、これ個人情報だって名の下にね、全部廃棄してたんですよ。なんで本をね、借りるのが個人情報なのか、って僕なんか思いますので。じゃあどこまでいくかは別にしてね、で、僕はそれを元にしてリコメンドを出したいんですよ、リコメンドを。例えば、杉山さんがこういう本を借りましたとしたときにね、今度借りたときにピッと4月20日までに返してくださいと出るじゃないですか、今度のお奨めはこの本ですとかって、いうふうにしたいんで。

今のところ補足なんですが、我々ですね、あの、CCCとして、個人の情報の履歴をですね、どこかに出したりってことは一切やっていないです。これは過去もやっておりませんので

たぶん、やるとすればですね、より人気のある商品は何なんだとかですね、こういう、女性の方を含めるとこういう品揃えの方が喜ばれる、みたいな、新価値を高めるための、データのマーケティングでデータベースとして使用するということは、有り得るかなあというふうに思ってますが

Tポイントの利用規約で、利用者の購買履歴っていうのはCCC以外の事業者に提供される規約になっているっていうのが現在の規約ですけども、これをご存知かどうかということと、それについてどうされるのかと、いうことは、まあ、検討中ということですかね。

とあるので。
まず
・履歴が一通り情報として残る
可能性は非常に高く、かつその履歴は
・個人情報ではないと認識していて
さらに
・一定の確率で、CCC以外の事業者に提供される可能性がある
というところが見て取れます。

で、これは市民の皆さんに対しての同意、同意が必要ですこれは。これは出してくれるなとかっていうことについてはそれは、ちゃんと、ね、配慮する必要があるだろうなと思います。

という話は出ているのですが、この辺の「同意」については、 http://takagi-hiromitsu.jp/diary/20111101.html#p01 あたりを一読していただきたく。
今回の図書館(っつか市)が「どうなのか」は不明だけれども、少なくとも「同意が必要といってるから手放しで安心できる」分けではない、っていう程度には不安材料です。


で…この話に

そりゃあ、新しいことをやるわけだからこれまでと比べて問題がゼロってことはあり得ないし、多分やってみたら気付かなかった新しい問題が出てきますよ。逆に、それが新しいことである証明でもあると思う。
だいたい、日本中の図書館をcccで運営するっていうならともかく、九州の中のたった一カ所、人口5万人の市で、ちょっと変わった市長(笑)が新しいことをやってみるっていう程度なんだから。なので、大きな問題がなさそうならば、まあみんなで見守りながら「まずはやってみて」、そして何か問題が出てきたら素早く修正して行く、でいいじゃないですか。(それがオプトアウト的な考え)

を足してみますと…ちょっと内容がおぞましくなります。


とりあえず「図書館で借りた履歴」は蓄積もするし活用もするしCCC以外の事業者にも提供します。
そこでもし、問題が発生したら、適宜修正をしていきます。


…もうちょいとかみ砕きます。


とりあえず「図書館で借りた履歴」は蓄積もするし活用もするしCCC以外の事業者にも提供します。
そこでもし「その履歴によって個人の思想が透けて見え、それによって思想差別が起きるなどの」問題が発生し、且つその問題が「今回のシステムの履歴によって引き起こされている、ということが明らかに証明できるのであれば(…だれが証明するんだろう?)」、適宜修正をしていきます。*2


さらにかみ砕いて。


とりあえず「図書館で借りた履歴」は蓄積もするし活用もするしCCC以外の事業者にも提供します。
そこでもし「その履歴によって個人の思想が透けて見え、それによって思想差別が起きるなどの」問題が発生し、且つその問題が「今回のシステムの履歴によって引き起こされている、ということが明らかに証明できるのであれば(…だれが証明するんだろう?)」、その後のシステムについては修正をしますが、すでに提供したり流出したりしている情報については何がどうとか出来るわけでもないので、何もしませんし出来ません。




で、話はタイトルに戻っていくのですが。
覆水盆に返らず、って単語、知ってますか?
ネットで「下手な情報が流出する」と、本気で「誰にもどうしようもない」状態が発生します。


その辺を踏まえて、もう一度、初手のfacebookの文章を見てみましょう。

まだ行動を起こす前に、素早く先回りして「問題になるかもしれない」点を一所懸命に探して指摘する。それが得意な人の多いこと、多いこと。

そりゃ指摘します。

そりゃあ、新しいことをやるわけだからこれまでと比べて問題がゼロってことはあり得ないし、多分やってみたら気付かなかった新しい問題が出てきますよ。逆に、それが新しいことである証明でもあると思う。
だいたい、日本中の図書館をcccで運営するっていうならともかく、九州の中のたった一カ所、人口5万人の市で、ちょっと変わった市長(笑)が新しいことをやってみるっていう程度なんだから。なので、大きな問題がなさそうならば、まあみんなで見守りながら「まずはやってみて」、そして何か問題が出てきたら素早く修正して行く、でいいじゃないですか。(それがオプトアウト的な考え)

修正? どうやって?
「その後」は修正したとして、「すでに起きてしまった被害」に対して、どのようにリカバリをするおつもりですか?

こうやっていくからこそ、シリコンバレーではどんどん新しいものがうまれ、新しい産業が育ち、新陳代謝が起こる訳ですよ。
新しいことはなにかメリットがありそうだからやるわけでしょ。で、今回もいろんなプラス効果が期待できることは普通の想像力のある人ならだれしも分ると思う。それがわかっているくせに、でも、まずは新たに起こる可能性のある問題点を口にする。そして、それがメディアで報道されると、もしかしたらこれ怖いかもしれないと(それまで思ってもなかったのに)急に不安がって同調しだす人々がいる。がん保険トップセールスマンみたい。

この辺は、もう少し「丁寧に」書かないといけない。
新しいことはなにか「それをやる業者や行政に」メリットがありそうだからやるわけでしょ。で、今回もいろんなプラス効果が「業者や行政に」期待できることは普通の想像力のある人ならだれしも分ると思う。それがわかっているくせに、でも、まずは新たに起こる可能性のある問題点を口にする。「それによって実害があるのは一般ユーザや一般市民であって、業者と行政ではない」。


「プラス効果があるんだからやりましょう、多少のデメリットは、天秤に乗せればメリットの方が大きいのです」は、とても便利な詭弁です。
冷静に「誰がメリットをどの程度享受して、誰がデメリットをどの程度被るのか」を考えると、ぼろぼろになります。


うん別に、今回の改革案が「全部駄目」だとは思わないのですよ。「うちの近所だったら」って仮定で考えたときに、いくつかは「あぁいいかも」と思えるモノもあったはあったので。
ただ、貸し出しの履歴については、初手から「いやな気分」ではあったのですが、ツイッター見て考察して調べて、って過程を経ているうちに、どんどんどんどん「いやな予想」しか出来なくなったので。

比較的メタなところだと「個人情報とか、流れたらそこから修正すればいいじゃない」という話を別クラスタでも時々見ていて、ちと一度は書きたいネタだったので。


PDCAをぶん回していいのは「ミスがちゃんとリカバリできる」時。
リカバリ出来ない状況と作業は「事前にできるだけの考察とセーフティラインとセーフティネットを張り巡らしてから」やりましょう。システム的には「インフラ作業」がこれ。


っつかね。
「たためない風呂敷を広げるな」。

*1:ぶっちゃけ全ての「都合が悪い話」は「小さな問題」で片付けるんぢゃないの? B-p

*2:ちなみにぶっちゃけた所の「邪推込みでの」私見。「思想差別で困ってる」って話を持ち上げると、まずは「うちが原因じゃない」と言いだし、つぎに「うちだけが原因じゃない」と言いだし、なんとか証明できるとつぎは「差別されるような思想を持っているお前が悪いのと、差別をするやつが悪いのであってうちは悪くない」って言い出して、逃げ切ると思う。少なくとも、潔く男らしく「ごめんなさい」って頭を下げることはゼッタイしないと思う。

ポチ袋なり、風呂敷なり

モノを差し上げるにしてもお金を差し上げるにしても。
そのまんま渡すメンタリティーは、多分、日本にはあまりないと思ってます。


心付を渡すならポチ袋に入れるでしょうし、お歳暮お中元は、きちんと風呂敷につつんでもつものです。
風呂敷にしても、包み方は色々。必要に応じてのせる熨斗なんてぇのもあるでしょう。


お渡しする相手(出力先)にあわせて、包み方(引数/option)も包むもの(関数/メソッド/その他)も変えて。
そんな気持ちで「出力するデータ」を包んだら(エスケープしたら)、プログラムの品がよくなるんじゃないかなぁ?


とか思ってみたので、めも。

相変わらず哲学が壊されているなぁ、と

大変に不勉強な話ではあるのですが。
https://twitter.com/#!/bulkneets/status/172248250999508993

例えばCakePHPという著名なPHPのWebアプリケーションフレームワークは、デフォルトでコピペのP3Pコンパクトポリシーを出力します。このポリシーがCakePHPで作られた運営サイトのポリシーと合致しているか誰が検証するのでしょう
https://github.com/cakephp/cakephp/blob/master/lib/Cake/Model/Datasource/CakeSession.php#L615

こちらのつぶやきで、P3Pについてはじめて知りました。


追記
http://d.hatena.ne.jp/mala/20120220/1329751480

P3Pが最早機能しないことは周知の事実で、ブラウザ関係者であれば尚更です。

あぁやっぱりそうなんだ orz
追記終了


ほんのりまったりと見てみると
http://bakera.jp/ebi/topic/3594
経由
http://d.hatena.ne.jp/satoru_net/20090506/1241545178

下記のkey&valueを出力しておけばOKらしい。

("P3P", 'CP="CAO PSA OUR"')

こーするだけで、あらふしぎ。IECookieを保存して意図した挙動をしてくれるじゃん。

なんて話もあるらしい。


興味深いので調べてみた。
おそらく
http://www.nmda.or.jp/enc/w3c/cr-p3p-20001215j.html
が比較的に適切であろう、と思う。
いやまぁさらに本来的には
http://www.w3.org/TR/2000/CR-P3P-20001215/
が最も適切なんだけど、この分量の英語を読む自信はない orz*1


おいちゃんの基本なので。
まずはこの仕様書、或いはもうちょっと正しくは「Platform for Privacy Preferences(P3P)」の「本来目的とするところ」について、確認をしてみる。
http://www.nmda.or.jp/enc/w3c/cr-p3p-20001215j.html#goals_and_capabs

1.1.1 P3P1.0の最終目的と可能性
-中略-
P3P1.0の最終目的は、次の二つである。最初の一つは、Webサイトがデータ収集を如何に行うかを標準化され、マシンが読むことができ、かつ、簡単な方法で、提示することを可能とすることである。二つ目は、Web利用者がアクセスするWebサイトが、どんなデータを収集し、どの様にデータが使われるかWeb利用者が知ることができ、どのデータやどんな利用をWeb利用者が"オプトイン"または"オプトアウト"することが可能か知ることができるようにすることである。

分かりやすい。
つまり「私(Webサイト)は[こんなデータ]を[こんな風に利用]します」という、Webサイトからユーザへのエクスキューズなんだ。


…それって、固定的に埋め込んでいいものなのかしらん?
興味深いので、@bulkneets さんが書いていた、cakePHPの記述を紐解いてみる。
見ている限り、protected static function _startSession() というインタフェースなので、なんとはなし「(セッションを使っている場合は)常に出力されている」ように見える。面倒だからソースの細かい読み込みとかしてないけど。


http://www.nmda.or.jp/enc/w3c/cr-p3p-20001215j.html#goals_and_capabs

header ('P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"');


NOI
for
ACCESS要素:情報の様々な種類にアクセスする機能をサイトが提供するかどうか
個人特定可能データは使われていない


ADM
for
PURPOSE 要素:データ収集目的またはデータ利用目的を含む
ウェブサイトとシステムの管理: 情報は、ウェブサイトとそのコンピュータシステムの 技術サポートのために利用されるかもしれない。 この中には、コンピュータアカウント情報の処理や、サイトの保守管理、およびサイトやエージェントによるウェブサイト活動の確認の過程で利用される情報の処理が含まれる。


DEV
for
PURPOSE 要素
調査と開発: 情報は、サイトやサービス、商品、マーケットを改善したり、評価したり、検討したりするために利用されるかもしれない。 この中には、特定個人に合わせてコンテンツを 変更するために個人情報を利用することや、特定個人を評価したり、ターゲットとしたり、 プロファイルしたり、 また特定個人と連絡をとったりするために個人情報を利用することは含まれない。


PSAi
不明。載ってなかった。
もしPSAであると仮定した場合
for (これ、pseudo-analysisのtypo、かも、しれない。或いはその逆か)
PURPOSE 要素
ペンネーム分析: 情報は、(名前、住所、電話番号、電子メール、IPアドレスなどの)記録するための個人が特定可能な情報を使うことなく、 個人かコンピュータ毎の個々の記録とペンネームの記録を繋ぐために使われるかもしれない。 このプロファイルは調査や分析、報告を目的とした、習慣や興味、個人の特徴といったものの決定のために使われるかもしれないが、 個人が特定可能な情報としては使われないだろう。 たとえば、市場で売買する会社や人がウェブサイトの異なる部分へアクセスする人の興味を理解したいと考えるかもしれない。


追記
@malaさんから、以下の事を教えていただきましたので、追記と謝意を。

P3Pの小文字のiとoは、それぞれその機能をopt-inで提供、opt-outで提供の意味です。

追記終了


COM
for
CATEGORIES:利用者とユーザエージェントに、意図されたデータ利用に関してヒントを提供するデータ要素の属性
コンピュータ情報: 個人がネットワークにアクセスするときに使用しているコンピュータシステムに関する情報。 IPアドレスやドメインネーム、ブラウザの種類、オペレーティングシステムなど。


NAV
for
CATEGORIES
ナビゲーションとクリックストリームのデータ: 閲覧することによって受動的に生じるデータ。訪問したページやページごとの滞在時間など。


OUR
for
RECIPIENT 要素:データを提供するかもしれないサービス提供者および当組織の業務委託先を超えた、法人組織または事業部門
当組織および/または当組織の業務委託先として業務を行っている法人または当社が業務委託先として業務をしている法人: この場合、 業務委託先(agent)とは、表明された目的の達成のためだけにサービス提供者に代わってデータ を処理する第三者として定義される。 (例えば、サービス提供者とその印刷事務所。ただし、 印刷事務所は住所ラベルを印刷し、それ以上は情報に関わりを持たない。)


OTRo
不明。載ってなかった(上述参照。oはopt-outの略だそうです)。
もしOTRであると仮定した場合
for
RECIPIENT 要素
当組織とは異なるプラクティスに従う法人組織: サービス提供者の制約を受け、サービス提供者に対して責任を負うが、サービス提供者のプラクティスにおいては特定されない方法で データを利用するかもしれない法人組織。 (例えば、サービス提供者が収集したデータを、 その他の目的で利用するかもしれないパートナー企業に提供する場合。 しかし、利用者の利益とサービス提供者の利益への侵害と考えられるような方法でデータが利用されないことを保証することが、サービス提供者の利益となるような場合。)


STP
for
RETENTION 要素:そのステートメントで参照されたデータに当てはまる保有ポリシー
言明された目的のための保有:情報は言明された目的をかなえるために保有される。 これは、 情報ができるだけ早期に破棄されることを要求するものである。 サイトは、データ消去のタイム テーブルを設定した保有ポリシーを持たなければならない。 保有ポリシーは、サイトの人間が読むことのできるプライバシーポリシーに含まれるか、またはそこからリンクが 張られていなければならない。


IND
for
RETENTION 要素
無期限: 情報は、無期限に保有される。これは、保有ポリシーがない場合に起こるかもしれない。受領者が公のフォーラムである場合は、これが適切な保有ポリシーである。


DEM
for
CATEGORIES
人口統計学的・社会経済学的データ: 個人の特徴に関する情報。性別や年齢、収入など。


ん…なんだろ。
少なくとも「フレームワーク側で、特に設定項目もなく自動的に射出していい」内容には、あんまり見えないんだけどなぁ…。
もし、万が一MagicWeaponで扱うとしたら。最低でも「きちんと設定ファイルなりメソッドなりで指定していただいて」になるかなぁ、と。まぁ「基本的に、この業種でこゆことしてたら(こゆことしてなかったら)この辺ぢゃね?」的なヒントくらいは、マニュアルかなにかで指し示すかもしれないけど。
でもまぁ…ぶっちゃけ「多分サポートしない」なぁ(苦笑


非常に興味深いものではあったので、メモ。
…「意味も分からずに、サードパーティーCookieの回避策用呪文」として定着、とかしなきゃいいんだけど。

*1:いやまぁしたら「少量なら読めるのか?」と聞かれると、きっちりと言葉に詰まるのだけど orz

DoS回避用の max_input_vars が出てきました

攻撃付近については
http://www.ipa.go.jp/security/ciadr/vul/20120106-web.html

PHP, Tomcat などを利用して開発されたウェブアプリケーションにおけるサービス運用妨害 (DoS) の脆弱性(CVE-2011-4885等)


ウェブアプリケーション等で使用されている言語 (PHP, Ruby 等) やウェブアプリケーションフレームワーク (Apache Tomcat 等) のハッシュテーブルの実装方法に問題があり、サービス運用妨害 (DoS) の脆弱性が存在します。この脆弱性が悪用されると、運用中のウェブサービスを提供できなくなるなどの被害にあう可能性があります。

あたりを。後は適宜「ググレカス*1」。


とりあえずパッチを覗いて、なんとなく欲しい情報を見つけてみました。

max_input_vars


PHP_INI_SYSTEM
PHP_INI_PERDIR

…むぅ、やっぱり orz
可能なら「PHP_INI_ALL」がうれしかった気がするのですが…まぁまぁ、やむをえないところでしょう多分。
$_GETとかを「使うタイミングで遅延評価」してるわけでもないでしょうし。…おそらく。


デフォルトはどうも1000みたい。…100くらいでいいような気がするんだけどなぁ? 実際、2個以上のパラメタを、おいちゃんは警戒するし。5個以上なら基本「嫌悪対象」だし。


で、上述に違反すると、どうも

Input variables exceeded [max_input_varsの数値]. To increase the limit change max_input_vars in php.ini.

ってメッセージが出るぽい。


後は…

max_input_vars, php_core_globals, core_globals

ってのが、気になったっちゃぁ気になった。
core_globalsだから、おそらく「ユーザが使う普通のglobals」ではないと思うんだけど(&、おいちゃんの監督下でGlobalなんてつかったら、基本"折檻"レベルのペナルティですが)。
多分これは「HTTPヘッダ使って同様のアタックがくることを防ぐ」感じ、なんだろうなぁ、と。…設定別々だといいのに(苦笑


まぁ、何はともあれ、おそらく結構重要と思われるネタなので。
珍しく、流行を先取りしてみようか、とw

*1:微妙に古いかしらん?

静的プリペアドステートメントが「原理的に安全」な理由 後編っていうか本編

後半です。
…「完了編」まで引き伸ばさないように頑張っていきたい所存でございます (`◇´)ゞ
前回のは http://d.hatena.ne.jp/gallu/20111128/p1 をご覧ください。


さて。
まずは「ふつ〜にエスケープされた場合」に、SQL-Injectionが「発生しない」真っ当なケースを見てみましょう。
先ほどのSQLは、エスケープによって
UPDATE test SET a=10 WHERE id='\';GRANT ALL ON *.* TO cracker;--';
となりました。
入力された
';GRANT ALL ON *.* TO cracker;--

\';GRANT ALL ON *.* TO cracker;--
になった感じですね*1


では、同じくパースをしてみましょう。


→ U
→ P
→ D
→ A
→ T
→ E
→ (0x20):半角スペース
status:上書き


→ t
→ e
→ s
→ t
→ (0x20):半角スペース
status:上書き、テーブルはtest


→ S
→ E
→ T
→ (0x20):半角スペース
データーが 来るぞ〜〜!!


→ a
→ =
status:上書き、テーブルはtest、aに( )を上書く


→ 1
→ 0
→ (0x20):半角スペース
status:上書き、テーブルはtest、aに10を上書く


→ W
→ H
→ E
→ R
→ E
→ (0x20):半角スペース
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(  )という条件に合致


→ i
→ d
→ =
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致


→ '
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致
現在「文字が入ってくる」モード


→ \
はぁ「エスケープ文字」ですかはいはいンぢゃ次の文字は気をつけて処理するよ〜
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致
現在「文字が入ってくる」モード+「次の一文字はエスケープ文字だよ」モード



→ '
ん…普通だと「文字が入ってくるモード 閉じ」なんだけど、今は「次の一文字はエスケープ文字だよ」モードなので、この子は「\'」になるから、一文字の「シングルクォーテーション」として取り扱うよ〜
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが'?????)という条件に合致
現在「文字が入ってくる」モード


→ ;
→ G
→ R
→ A
→ N
→ T
→ (0x20):半角スペース
→ A
→ L
→ L
→ (0x20):半角スペース
→ O
→ N
→ (0x20):半角スペース
→ *
→ .
→ *
→ (0x20):半角スペース
→ T
→ O
→ (0x20):半角スペース
→ c
→ r
→ a
→ c
→ k
→ e
→ r
→ (0x20):半角スペース
→ ;
→ -
→ -
→ '
うわまた長ぇなぁをい。
んと…「文字列の終端を意味するシングルクォート」の直前までの文字を足してくと…「';GRANT ALL ON *.* TO cracker;--」ってのが検索したい文字列なんだ。ほいさ了解。
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが';GRANT ALL ON *.* TO cracker;--)という条件に合致


→ ;
ほい。SQL文終わりね。んぢゃ実行するよ〜」
「status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが';GRANT ALL ON *.* TO cracker;--)という条件に合致」を実行
statusを一端クリア。


→ \0
あ、終わった。


というわけで。
エスケープ処理によってめでたく、クラッカーが意図している「GRANT ALL ON *.* TO cracker;」は実行されずに終わりました。
めでたいですね。


ただ。この「エスケープ処理」も、うまいこと動かないケース(というかエスケープ漏れが発生するケース)ってのがあります。
では、そんな例を。
UPDATE test SET a=10 WHERE id='aa表';
ふつ〜に見えるSQLですので、そのまんまGo。エスケープしても特に変化はありません(罠1)。
っちゅわけで、パースいきます。


→ U
→ P
→ D
→ A
→ T
→ E
→ (0x20):半角スペース
status:上書き


→ t
→ e
→ s
→ t
→ (0x20):半角スペース
status:上書き、テーブルはtest


→ S
→ E
→ T
→ (0x20):半角スペース


→ a
→ =
status:上書き、テーブルはtest、aに( )を上書く


→ 1
→ 0
→ (0x20):半角スペース
status:上書き、テーブルはtest、aに10を上書く


→ W
→ H
→ E
→ R
→ E
→ (0x20):半角スペース
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(  )という条件に合致


→ i
→ d
→ =
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致


→ '
ん? あぁ文字が入ってくるのね。了解。
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致
現在「文字が入ってくる」モード


→ a
→ a
ちょっと一端ここで止めます。説明が細かいんで。ここまでは無問題でよいよね?
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idがaa?????という文字である)という条件に合致


「表」という漢字は、これがsjisの場合「0x95」と「0x5C」という2つの文字なので、ちと丁寧にパース処理を眺めてみます。


→ 0x95
文字として「0x95」が入ってきました。区別しやすいようにc(0x95)って書きます
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idがaac(0x95)?????という文字である)という条件に合致
現在「文字が入ってくる」モード


→ 0x5C
文字として「0x5C」が入ってきました。実は0x5Cって、\のことなんですね。
\なので「エスケープ文字」ですから、エスケープモードに移行します。
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idがaac(0x95)?????という文字である)という条件に合致
現在「文字が入ってくる」モード+「次の一文字はエスケープ文字だよ」モード


→ '
ん…普通だと「文字が入ってくるモード 閉じ」なんだけど、今は「次の一文字はエスケープ文字だよ」モードなので、この子は「\'」になるから、一文字の「シングルクォーテーション」として取り扱うよ〜
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idがaac(0x95)'?????という文字である)という条件に合致
現在「文字が入ってくる」モード


→ ;
今は「文字が入ってくる」モードなので、;は普通の文字として扱うよ
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idがaac(0x95)';?????という文字である)という条件に合致
現在「文字が入ってくる」モード


→ \0
…あれ? 終わったの?
statusが空っぽじゃないから実行をしてみるよ?
「status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idがaac(0x95)';?????という文字である)という条件に合致」
ん…「対象レコード」の条件式が中途半端なままだから、処理できないからエラーにするよ〜


こんな風に。
色々条件にもよりはするのですが、「エスケープをしていたはずなのにしくじる」ケースなんてのもあります。
今回は「SQLがエラーになる」パターンにしましたが、これが容易に「クラックパターンに応用できる」のは、もうそろそろ書かなくても見えてくるころかなぁ、と思います。


結局のところ。
「完璧にエスケープが出来てりゃ」いいのですが、どうしても「現状想定できていない漏れ」の可能性が、否定できないので。
…いやまぁ別に「ボクは森羅万象過去現在未来のすべてを全知全能で知ってる」とかいう人は是非頑張っていただきたいのですが、おいちゃんはそんな器用な超常能力の手持ちがないので。
おいちゃんは、もちろん「今現在普通に既知」のものについては正しくエスケープが出来るとは思うのですが「未来の未知の脆弱性」にまで対応できている自信は、まったくないです。


まぁ一つに「随所に関所、で修正箇所を一箇所にまとめる」+「セキュリティ系のニュースのアンテナを鋭くしておく」ってのがあるのですが。
一方で「静的プリペアドステートメントによって、原理的に安全さを教授する」っていう方向性があるわけです。
(…やっと本題だよ)。


んぢゃ。とりあえずさっきこけていたSQLを使って、静的プリペアドステートメントの流れを見ていきましょう。
ちなみに「静的プレースホルダ」「バインド機構」とかなんか色々用語が見当たりますが、JIS/ISO の規格で「準備された文(Prepared Statement)」ってあるらしいので、とりあえずカタカナで「プリペアドステートメント」でいこうかなぁ、と。…長いんだけど(苦笑


まず。「静的プリペアドステートメント」では
SQLステートメント(プリペアドステートメント)
・バインドする配列
の2つを用意します*2


SQLステートメントはこんな感じ。
UPDATE test SET a=10 WHERE id=?;
クエスチョンマークんところに「バインドされたパラメタ」がはいります。


一方で「バインドする配列」には、今回は
aa表
を入れておきます。


では、この状態で同じようにパース処理を眺めてみましょう。


→ U
→ P
→ D
→ A
→ T
→ E
→ (0x20):半角スペース
status:上書き


→ t
→ e
→ s
→ t
→ (0x20):半角スペース
status:上書き、テーブルはtest


→ S
→ E
→ T
→ (0x20):半角スペース


→ a
→ =
status:上書き、テーブルはtest、aに( )を上書く


→ 1
→ 0
→ (0x20):半角スペース
status:上書き、テーブルはtest、aに10を上書く


→ W
→ H
→ E
→ R
→ E
→ (0x20):半角スペース
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(  )という条件に合致


→ i
→ d
→ =
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致


→ ?
ほい。バインドされたパラメタを使うのね。
バインド君、パラメタ一つ、持ってきて〜
 バ(*。・ω・)っ → aa表
ほいほいaa表って文字ね。了解。
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idがaa表)という条件に合致


→ ;
→ \0
終了系のパターンなので省略。


こんな感じ。
で…早々にで恐縮ではありますが、まとめ。


結局のところ。「本来はデータとして扱いたい」はずの文字列が「指示用の文字(SELECTとかGRANTとか;とか 0x20 とか)」と誤認されるのが、最大の問題になります。
クラックは「データのふりしてあの子 わりとやるもんだね と」指示用の文字を埋め込み、かつ、DBのパーサが誤認をするようなデータをぶち込んでくるわけです。
で、エスケープは「そういった誤認が発生しないように、特殊文字を"普通の文字として扱う"フォーマットに変換する」わけなのですが。
静的プリペアドステートメントは「そもそもとして、制御用の文字とデータとを、インタフェース的に分離してしまう」という、ある意味非常に、荒っぽいとすら言える決断をしたことで「そもそも入り口が違うから誤認のしようがない」状態を作り出したわけです。


このあたりが「静的プリペアドステートメントが「原理的に安全」な理由」なわけです。
…伝わったですかしらん?

*1:ここで「\'ぢゃなくて ''が正しくね?」と思ったかたは、とりあえず「あとの布石だから空気ヨメ!!」って発言を前提に、意見をオミットさせていただきます

*2:…用語がいまひとつ怪しいので、気付いた方は是非突っ込んでください

静的プリペアドステートメントが「原理的に安全」な理由

ものっそ大雑把に説明をしていきます。
「わかりやすさ」中心なので、「現在(ここほんの40〜50年くらい)の素晴らしい技術(アルゴリズム考え方アーキテクチャその他)」には大分と背を向けている可能性がありますのでご注意ください B-p
真面目にSQLのパースあたりとかを知りたかったら、是非具体的なソースコードを読んでみてくださいませ。


さて。
ざっくりと解説をするために、SQL文を非常に「簡単に」してみます。あちこち漏れてますが、その辺は適宜脳内補完をお願いいたします。
とりあえず、SQLには「以下の機能がある」と仮定します。


・読み書きどっち?
SELECTなのかINSERTなのかUPDATEなのか
・対象テーブル
どのテーブルに対する操作要求なのか
・対象カラムとか値とか
SELECTならナニを読みたいのか?
insertとupdateならどこにナニを書きたいのか?
・レコードに対する制限各種
whereとかその他。面倒なんでwhereのみってことで。


おいちゃんは「コンピュータの動きをそのまま真似て理解する」のが、古くからの伝統だと信じてますので。
ちょうど手元にあります一つのSQLを「素直に」パースしてみませう。
パースってのは、ようは「一本の文字列」を「使いやすいように切ったり張ったりする」ようなもんです。
で…記述文字数減らしたいんで。


→ a


って書いてあったら「aって文字が入ってきた」んだと思ってください。
では、早速


→ S
あぁ。selectですかねぇ?


→ E
うん、そんな感じっぽい。


→ L
あたりでしょう。

→ C
…C? ここはEでしょ? これじゃパース出来ないのでエラー終了ですよ!!


と。いきなりエラーパターンでした。
ちなみに入ってきたのは、こんな感じ。
SELCT * FROM test;
はいすみませんおいちゃんがよくやるtypoの一つです orz


では。真っ当な「SELECT * FROM test ;」を、ちと手間ですが、真面目にパースしてみませう。
文字列の終端は多分\0だとおもいますんで、そうしておきます。


→ S
→ E
→ L
→ E
→ C
→ T
→ (0x20):半角スペース
このタイミングで「あぁselectなんだなぁ」って思います。
status:読み


→ *
→ (0x20):半角スペース
ここで「あぁ、全カラムよこせですか。はいはい」って思うわけですね。
status:読み、全カラム


→ F
→ R
→ O
→ M
→ (0x20):半角スペース
次にテーブル名が来るようです。


→ t
→ e
→ s
→ t
→ (0x20):半角スペース
はぁ。「test」ってテーブル名ですか。安直ですねぇ。
status:読み、全カラム、テーブルはtest


→ ;
あ。SQLおわた。えと…「status:読み、全カラム、テーブルはtest」はいはい。
んぢゃってんで、testって名前のテーブルの全カラムを、順不同でreturnいたしやしょう。
「status:読み、全カラム、テーブルはtest」を実行。
statusはこのタイミングで一端空っぽになります。


→ \0
あ。文字列も終わりなんだ。
statusが空っぽなので、処理終了〜 ノ


こんな風に中では動いていきます(実行計画とかそーゆーあたりは今回まったく意識してませんので一瞬だけ頭からはずしといてください)。
同じように、update文を簡単に書いていきましょう。
UPDATE test SET a=10 WHERE id='t1' ;


→ U
→ P
→ D
→ A
→ T
→ E
→ (0x20):半角スペース
ほいさ。今回は「上書き」なのねん。
status:上書き


→ t
→ e
→ s
→ t
→ (0x20):半角スペース
またしても「test」ってテーブル名ですか。安直ですねぇ。
status:上書き、テーブルはtest


→ S
→ E
→ T
→ (0x20):半角スペース
ほいほい。この先にデータがくるのね。


→ a
→ =
はぁ。カラム名はaですか、また雑な…
status:上書き、テーブルはtest、aに( )を上書く


→ 1
→ 0
→ (0x20):半角スペース
書き込む値は10ですか。ほいほい。
status:上書き、テーブルはtest、aに10を上書く


→ W
→ H
→ E
→ R
→ E
→ (0x20):半角スペース
ん? WHERE? ほいほい。対象レコードに条件を指定したいのね。よろしくってよ?(いきなりキャラ変えない
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(  )という条件に合致


→ i
→ d
→ =
検索用の対象カラムはidって名前なんだ。ほいほい。
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致


→ '
ん? あぁ文字が入ってくるのね。了解。
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致
現在「文字が入ってくる」モード


→ t
→ 1
→ '
t1が入ってきて「文字が入ってくるモード」終了。
ってことは「idがt1って値のレコード」を対象にしたいんだね。
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idがt1という文字である)という条件に合致


→ ;
→ \0
おわた系のパターンなので省略。


すげー大雑把に、こんなことやってます。
ちなみに、文字をシングルクォートで囲むのはまぁ「それが必要だから」。
簡単に、0x20で説明。


部分的に切り出して
id='t1'
の形式を見てみませう。
今度は「idがホワイトスペースを含む文字列 "t 1"であるレコードを探したい」場合。
まずは正しい形式である「 id='t 1' 」をパース。


→ i
→ d
→ =
検索用の対象カラムはidって名前なんだ。ほいほい。


→ '
ん? あぁ文字が入ってくるのね。了解。
status:対象レコードは(idが  )という条件に合致
現在「文字が入ってくる」モード


→ t
→ (0x20):半角スペース
※半角スペースあるけど、今は「文字が入ってくるモード」だから、この半角スペースは「文字として」扱うよ〜
この時点で、以下の感じ
status:対象レコードは(idがt ???)という条件に合致
???には、きっとこれから「何か」が入ってくるはず〜


→ 1
→ '
t 1が入ってきて「文字が入ってくるモード」終了。
ってことは「idがt 1って値のレコード」を対象にしたいんだね。


ってな感じで恙無く終了。
で、もしシングルクォートがないと


→ i
→ d
→ =
検索用の対象カラムはidって名前なんだ。ほいほい。


→ t
→ (0x20):半角スペース
tが入ってきて「一区切り」を意味する半角スペースが入ってきたから、探したいのは「idがtのときなんだね」…あれ?


って誤認しちゃう。
だから、シングルクォートが必要なんだよ、ってのは、余談というか前置き。
実はあとですげぇ重要になるから、さりげなくチェック。


んでは。
先に、悪名高いいわゆる一つの「SQL-Injection」を、見ていきましょう。
とりあえず、状況。


UPDATE test SET a=10 WHERE id='{GETパラメタのデータ}' ;
って感じで、本当はパラメタに「t1」とかが入ってきて
UPDATE test SET a=10 WHERE id='t1' ;
とかを想定していたんだけど、なんか悪くてずるくて黒い人がパラメタに「変な値」を入れてきちゃった、的な状況。
「変な値」とかを知る由もなく、素直にパース作業に移ってみましょう。
ところどころはしょりますんで、その辺ご注意を。


→ U
→ P
→ D
→ A
→ T
→ E
→ (0x20):半角スペース
status:上書き


→ t
→ e
→ s
→ t
→ (0x20):半角スペース
status:上書き、テーブルはtest


→ S
→ E
→ T
→ (0x20):半角スペース
データーが 来るぞ〜〜!!


→ a
→ =
status:上書き、テーブルはtest、aに( )を上書く


→ 1
→ 0
→ (0x20):半角スペース
status:上書き、テーブルはtest、aに10を上書く


→ W
→ H
→ E
→ R
→ E
→ (0x20):半角スペース
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(  )という条件に合致


→ i
→ d
→ =
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致


→ '
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが  )という条件に合致
現在「文字が入ってくる」モード


→ '
あれ? 文字が入ってくるまえに「文字が入ってくるモード」が閉じられちゃったよ?
status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが空っぽ)という条件に合致
「文字が入ってくる」モード解除


→ ;
SQLおわり。
「status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが空っぽ)という条件に合致」を実行
statusを一端クリア。


→ G
→ R
→ A
→ N
→ T
→ (0x20):半角スペース
GRANTね。ほいほい「DBの権限を設定/変更/削除」するのね。
status:RDM権限設定


→ A
→ L
→ L
→ (0x20):半角スペース
allですか全権限付与ですか。豪勢ですねぇお大臣ですねぇ。
status:RDM権限設定、あらゆる権限を付与


→ O
→ N
→ (0x20):半角スペース
この先に対象テーブルと対象database名が来るのね。ほいほい


→ *
→ .
→ *
→ (0x20):半角スペース
*.*ってこたぁ「あらゆるdatabaseのあらゆるテーブルに対して」の権限ですか。どっかの皇帝みたいだねぇ
status:RDM権限設定、あらゆる権限を付与、すべてのdatabaseのすべてのテーブルが対象


→ T
→ O
→ (0x20):半角スペース
この先に「誰がこの権限もらえるのか」を書くのね


→ c
→ r
→ a
→ c
→ k
→ e
→ r
→ (0x20):半角スペース
ユーザ名はcrackerさん、っと…イヤな名前だねぇまったく。
status:RDM権限設定、あらゆる権限を付与、すべてのdatabaseのすべてのテーブルが対象、ユーザ名はcracker


→ ;
SQLおわり。
「status:RDM権限設定、あらゆる権限を付与、すべてのdatabaseのすべてのテーブルが対象、ユーザ名はcracker」を実行…本当にいいのかしらん?


→ -
→ -
あら。--がきたよ。改行コードが来るまでの間、以降コメントだねぇ。
現在「コメント」モード


→ '
→ ;
→ \0
おやコメントモードのまま終わっちゃったよ。
んじゃ、statusも空っぽだし、何もしないで終わるよ〜。


さて、やったことを振り返ってみましょう。
・「status:上書き、テーブルはtest、aに10を上書く、対象レコードは(idが空っぽ)という条件に合致」を実行
・「status:RDM権限設定、あらゆる権限を付与、すべてのdatabaseのすべてのテーブルが対象、ユーザ名はcracker」を実行
の2つです。前者はともかく、後者のほうは「なにしとんじゃ (#゚Д゚)ゴルァ!!」な感じですね(GRANT文、微妙に「どこに行ってもエラーになるように」微妙に書式を変えているつもりですが…通ったらごめんなさい)。


このSQL-Injectionですが、入力されたのは「';GRANT ALL ON *.* TO cracker;--」って文字列を想定しています。
そうすると
UPDATE test SET a=10 WHERE id='';GRANT ALL ON *.* TO cracker;--';
っていうSQLになりまして…まぁ、上述のような「大惨事」が発生します。


…ごめん体力が尽きたから、後編に続く orz


追記
後編 → http://d.hatena.ne.jp/gallu/20111129/p2

XSSはソースコードのリトマス試験紙

いやまぁ何カ所かで偶然「ほぼ同じ話」をしていたので、ちと自分の脳内整理を兼ねて。
一言で結論を書くと「ようは割れ窓理論」って話です。


とりあえず、お題は「XSSは非常にまずい」と。
その辺の「おいちゃん的思考」を、だらりんこんと書いていきたいと思います。
…って、細かく書くとすげぇ長くなったので(文章支離滅裂になったので全部消したw)、割と端的に。


かみ砕いて。
セキュリティホールがある」ってのはまぁそもそもとして「知識不足の可能性」を疑うべきではあるのですが、まぁそのあたりは適宜「学んでいただく」として。
そこから先、少なくとも「実務」の場合、「costその他との天秤」が待っているですだよ。


えと…具体的に。
「そこそこしゃれになっていない」セキュリティホールがあると仮定します。
もしそれが「10分程度で修正可能」であれば、これをやらないケースというのは、あんまりないと思います(あんまり、の理由は後述)。
一方でそれが「2人月ほどかかる」となった場合、特に「おじぇじぇを握っている層」が難色を示す可能性が高いのは、まぁ社会人であれば容易に想像が付こうか、と。


ちなみに「10分程度で修正可能なのに修正をしないケース」というのが、これがまた実際にありまして。
これはおおよそ「問題を全く理解していない(知識不足)」にくわえて「ゴミのようなプライド(「修正しろ」と人に言われたので、技術レベル的に"出来てるつもり〜"な技術者のプライドが傷付いた)」というのが、おおよその構成要素かと思われます。


閑話休題


で、XSSなのですが。
じゃぁまぁ「発覚した」として、実際問題「どれくらいの作業量」で修正ができるのでしょうか?
ここで「井坂さん」と「路地さん」、「葉桜さん」にお話を伺ってみましょう(…夜中だからテンションが怪しいw)。


井坂さん:
そんなはずないのですが…ありゃ、エスケープ処理にミスがありますね。
エスケープしている箇所を書き直す程度ですので、テストをしたとしても…(1時間あれば終わりそうだから)半日くらいで終わると思いますよ?


路地さん:
そうなんですか?
えと…テンプレートに値をセットするのは、だいたい同じ箇所でやっているので…例外部分を洗い出すとして…多分、多めに見積もって一週間くらいだと思うのですが…


葉桜さん
イヤ正直無理ですよぶっちゃけ。
値のセットはソースコード中に散乱、部分的に「プログラムでエスケープ」してたり部分的に「テンプレート側でエスケープ」してたり、ばらんばらんなんで。
やってもいいですが…2〜3ヶ月は確実にかかりますよ?


…んで。
正直、「井坂さん」のところだと「XSSが見つかった → 直せ〜 → 直った〜」で片付いちゃうと思うんですよ。いやまぁ「気付いたら連絡してあげよう」とは思うのですが。
「路地さん」のところだと…軽く微妙かなぁ、と。ただまぁ一週間程度の工数であれば、なんだかんだ「ひねり出す」ところも多いかなぁ、と。
「葉桜さん」ところのレベルになると「XSSが見つかった? とりあえず個人情報は漏れないっぽい? ンじゃほっとけ」になること請け合い。…なにせ実例を何件も知ってますから orz


さらに、んで。
もちろん例外はあろうかと思うのですが。
上述、端的に言うと「随所に関所( http://d.hatena.ne.jp/gallu/20080225/p1 )」が出来ているかどうか、なんですが。
もうちょっと深読みをすると、現場のソースコードや、その前提になる設計が「びりほな設計/ソース」なのか「見るも無惨な設計もどき/駄ソース」なのか、ってのが、透けて見えてくるですよ。


そんなこんなを総合するとですね。
XSSは、いやその「セキュリティホール自体」、じゅ〜〜〜〜ぶんにまずいとは思うのですが。
別の角度として「XSSがたれ流れていて、かつ修正がままならないようなサイトのプログラムは、その中身、推して知るべし」ってなることが多いんですね。


なのでまぁ「XSSソースコードリトマス試験紙」と、そんな風においちゃんは思うわけですよ。
いやまぁ「おいちゃんが関わっていない」ものがどんな状態であっても、別段、目くじらを立てるようなもんじゃないとは思うんですがね B-p