新生鳩丸掲示板♯

このCIW資格というのは、一体どういう知識を身につけさせたいものなんでしょうね。

>>りゅうさんが買ったら遊びに行きますのでよろしく（謎）。

>　買うように申しつけておきます。:-)

スペランカーは買うのでどなたか本体をお願いします(謎)。

>詳細な記述無しに「○○というサイトは脆弱だ」とだけ書くことが一般的に

>なってしまったら、なんかそれこそ名誉毀損というか業務妨害というか、

>濡れ衣だ～！とサイト運営者が悲痛な叫びをあげることも出てきてしまうかも。

　確かにそうですね。

　実際、そんなような話が過去にあったような気もします。

　そのための釘でもあるのでしょうね。

>企業の場合は、6ヶ月経っても修正が行われる気配がなかったら、IPAが

>その企業が所属する業界団体に通知するようにするとか。（冗談ｗ）

　まともな企業なら、割とふつうに対応してくれるので問題ないのですけれど……。

　最近悩みの種なのが「大量に脆弱性を生み出しており、既に攻撃も受けているのに改める気配が全く感じられない個人」というパターンで、これがいちばんやっかいかもしれないと思っております。

セキュリティ/脆弱性についてちゃんと理解している人の場合や、あるいは、

XSSのように脆弱性の存在が誰にでも明白に判断できる場合は、

「○○というサイトは脆弱だ」と言ってしまうのもアリかも知れません。

でも、世の中には、セキュリティ/脆弱性についての中途半端な理解のもと、

例えば、入力→確認→完了の、確認→完了で、hiddenを使って値を引き継いで

いました！これは脆弱です！というような届出だってあるかも知れません。

例えば、アンケートフォームがhttpsではありませんでした！脆弱です！

という届出もあるかも知れません。

詳細な記述無しに「○○というサイトは脆弱だ」とだけ書くことが一般的に

なってしまったら、なんかそれこそ名誉毀損というか業務妨害というか、

濡れ衣だ～！とサイト運営者が悲痛な叫びをあげることも出てきてしまうかも。

# ま、「受理」になってから、書けば良いのかも知れませんが、、、

　＊＊＊

どうすれば修正してもらえるんですかねぇ。

企業の場合は、6ヶ月経っても修正が行われる気配がなかったら、IPAが

その企業が所属する業界団体に通知するようにするとか。（冗談ｗ）

>>しね

>　最近はこういうのを書くと殺害予告とみなされて警察に通報されたりするのですかね?

>　リモートホストの 122.30.48.144 は OCN ですね。とりあえず OCN に連絡してみますかね。

　あー、Yahoo! でポケモン関係の単語を検索してたどり着いてますね。

　それで目的の情報が得られなかったからキレたのか。

　小学生かなー。

　警察なんかより親に連絡したいところですが、難しいですね。

>りゅうさんが買ったら遊びに行きますのでよろしく（謎）。

　買うように申しつけておきます。:-)

>しね

　最近はこういうのを書くと殺害予告とみなされて警察に通報されたりするのですかね?

　リモートホストの 122.30.48.144 は OCN ですね。とりあえず OCN に連絡してみますかね。

しね

正直なところ、初めてPS3が欲しいと思った。アイレム的にPS3以外の選択肢はないだろうし。りゅうさんが買ったら遊びに行きますのでよろしく（謎）。

>>とは言っても、無条件にオススメしたりはしませんし、私も今のところ実践するつもりはないのですが。

>このやり方が、なぜオススメできない感じなのか、実践しない感じなのか、

>その理由が明らかになるといいと思います。

「無条件にオススメしたりはしない」と言っているのは、「変換処理が重くなるかもしれない」「実装が面倒かもしれない」「結果出力されるデータのサイズが大きくなる」といったデメリットがあるからです。そういったデメリットが気になる場合は採用したくないこともあるでしょう。

　また、これはまだ思考実験の段階なので、他にもデメリットがあるかもしれませんし、メリットも実は小さいのかもしれません。

　実践しないと言っているのは、単に私が基本的に「全部DOM」派だからです。DOM操作だけでXHTMLを作る場合、文字参照への変換は出力時に自動的に行われてしまいますので、このような処理を書く余地がありません。

>しっかり実例もあるようです。

>http://slashdot.jp/~alp/journal/454573

これですか。

http://www.massangeana.com/mas/charsets/cjk-c.htm

> 行の始めが "zW" (7A 57) で始まっていると, そこから行末までを GB だとみなします。実際には改行は無視されます。 GB の後の改行を無視されたくない場合は行末に "#" (23)をつけます。その他, GB 行の途中に 1文字だけ ASCII を使いたいときは, たとえば "?" (3F) なら " ?" (20 3F) のように頭にスペースをつければよいなど, いくつかの工夫があります。

かなり古いエンコーディングのようで、さすがにウェブブラウザは対応していないようですが、iconvがさりげなく対応しているようです。

＞とは言っても、無条件にオススメしたりはしませんし、私も今のところ実践するつもりはないのですが。

このやり方が、なぜオススメできない感じなのか、実践しない感じなのか、

その理由が明らかになるといいと思います。

仕様に基づいたことなのか、たまたま解決する他の問題を気にしなくなることがかえって将来のリスクにつながらないか、

とかそんな感じでしょうか。

> 注釈に「ASCII非互換でものすごく変な文字符号化方式があったりしたら分かりませんが……」とある通り、そのホワイトリストでは想定外の挙動が起こらないことが保障できていません。

しっかり実例もあるようです。

http://slashdot.jp/~alp/journal/454573

>そうするとホワイトリストの出番がなくなってしまいますので。:-)

確かに ... :-) もしかして、地雷を踏んでしまったかな!? m(_ _)m

> ところでqvalueを認識する実装がqvalueの大小を無視して採用順序を逆転させたらRFC違反になるでしょうか。

結局、エンティティの決定方法は「12 Content Negotiation」にも定義されていないので、どんな決定方法を取ってもRFCに則していないことにはならないと思います。たとえば「サーバのお薦め」みたいなサーバ都合の評価軸も持つアルゴリズムにしている場合、正当な理由でqvalueの大小が無視されるという状況を発生させることができそうな気がします。とはいえ「サーバのお薦め」ってなんだか分かりませんが、よりヒットしているキャッシュの方とか?

>>>> 意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、

> とか言ってた人【誰】につられたので【クマー】そっちに言ってあげてください【謎】。

それはqvalueのみを条件に使う場合というコンテキストでのみ成り立つ文なので、お察しください(謎)。

> それはりゅうさんが勝手に察しているだけです。受信側も同じように察すると保証できるでしょうか【謎】。できないはずです【謎】。なぜならMIMEタイプを決定するのはりゅうさん【誰】が作成したソフトウェアではないからです【謎】。したがって【謎】記述順に優先して採用されることを期待してMIMEタイプを書くということに意味はないということになります【謎】。

自明であるはずのAcceptフィールドの優先順位すら明確に察せない私は、まだまだ察しスキルが足りないということなのでしょう(謎)。

>別途定める決定方法の採用が可能であれば、RFCのあの部分の内容は、特定のタイプに対応するqvalueの決定方法というだけの事になるので、qvalueのみで採用するタイプを決定しなければならない訳ではないということになるかと思います。

qvalueは同じ値になることもあるのでqvalueのみで決定しなければならない訳ではないことは明らかだと思います。ところでqvalueを認識する実装がqvalueの大小を無視して採用順序を逆転させたらRFC違反になるでしょうか。

>ちなみにRFCから察する限り、優先順位は一次元配列内の位置として表されるので、同じ優先順位のものが存在することはないはずです。

それは

>>> 意図的に低いqvalueを指定していない限り */* と同位になってしまって決定できないので、

とか言ってた人【誰】につられたので【クマー】そっちに言ってあげてください【謎】。

>「Media ranges can be overridden by more specific media ranges or specific media types.」とあるので、詳細度によってオーバーライドされるべき元々の何かがあるはずです。オーバーライドされた結果起るのが優先順位の変化ということは、何らかの方法で元の優先順位が定義されるはずですが、恐るべきことにそれは明示されていません。それに使える情報は記述順くらいしか無いので、察する限りまあそういうことではないかと。

それはりゅうさんが勝手に察しているだけです。受信側も同じように察すると保証できるでしょうか【謎】。できないはずです【謎】。なぜならMIMEタイプを決定するのはりゅうさん【誰】が作成したソフトウェアではないからです【謎】。したがって【謎】記述順に優先して採用されることを期待してMIMEタイプを書くということに意味はないということになります【謎】。

仕様も変更されていて、現在の登録情報の確認・変更・配信停止のリンクには「act」「k」に加え「h」パラメータ（今度はハッシュですか）が追加され、何かをパラメータ化したみたいです。

登録変更などのリクエストをした時と同じブラウザからじゃないとアクセスできないようにしたってのがこれみたいです。まさかUser-Agentのハッシュなんてマヌケじゃないだろうとは思うけど、詳しく調べてないのでわかりません。あと、永久に有効だったのが期限付きになってます。うかつにも小刻みに調べなかったので実際のところは不明ですが、4日前のリンクはもう無効でした。

というわけで、システムの欠陥は認識してるようだけど、あくまで貼った奴が悪いと。

せっかくなので私も真剣に考えてみました。以下本文。

ホワイトリストによるフィルタリングというのは、ソフトウェアが扱う値を動作保障されている範囲に限定することによって、想定外の挙動が起こることを防ぐというものです。したがってホワイトリストに含まれるものは、なんらかの方法によって動作保障がなされているものである必要があります。そうでないものはすべて「グレー」で、ホワイトリストに含めるべきものではありません。

注釈に「ASCII非互換でものすごく変な文字符号化方式があったりしたら分かりませんが……」とある通り、そのホワイトリストでは想定外の挙動が起こらないことが保障できていません。したがって [0-9a-zA-Z] は「グレー」で、「白」ではない以上ホワイトリストに含めることは適切ではありません。ということでホワイトリストには何も含まれなくなり、すべての文字をエスケープすることになるわけですが、それで想定外の挙動は起こらないと保証できるでしょうか。できないはずです。なぜなら問題を起こすのは自分が作成したソフトウェアではないからです。

ウェブアプリケーションが出力したデータで問題を起こすのは、データを受け取った側のソフトウェアで、ほとんどの場合それは他人が作成したものです。他人が作成したソフトウェアの動作を保障することはできないため、出力のホワイトリストというものを作成するということができません。作ったとしてもそれは出力側が勝手に考えた「白」っぽいリストというだけであって、受け手側のホワイトリストである保障はありません。したがって出力をホワイトリストで処理するということに意味は無いということになります。