新生鳩丸掲示板♯

>　よく考えたら、group だと解釈すると、今度はコメントの外に ":" が必須になるのではないでしょうか。

";"もですけど。

>というか最初からそういうつもりで書いた

　あうあう、読解力不足でした。

　すみません。

　まあ最終的には意図が汲めたということでひとつ。

>　そういう意味ではセッション ID とは異なる別のランダム値をあらためて用意する必要は無いので、車輪の再発明は必要ないともいえます。

というか最初からそういうつもりで書いた(高木さん【誰】が言っているように、セッションIDをそのままinput type="hidden"に含めればいいから別途定めるランダム値を生成する必要はないと言いたかった)のですが、圧倒的に舌足らずでした。ありがとうございます【謎】。

>group = display-name ":" [mailbox-list / CFWS] ";"

>　なので無くてよかったのですね。こちらは見逃していました。

　よく考えたら、group だと解釈すると、今度はコメントの外に ":" が必須になるのではないでしょうか。

>えっと、address = mailbox / group ですから、グループ1つ(= 有効なアドレスなし)もありなのではないですか?

　ああ、なるほど。ご指摘ありがとうございます。

　group は

group = display-name ":" [mailbox-list / CFWS] ";"

　なので無くてよかったのですね。こちらは見逃していました。

　ちょっと細かく書きなおしてみました。

　わかりやすくなったでしょうか?

えっと、address = mailbox / group ですから、グループ1つ(= 有効なアドレスなし)もありなのではないですか?

まあ、昨今の風潮を考えれば From: にアドレス不記載はすごく怪しいですが

>　通常は Cookie の値としてセッション ID が使われますが、その場合はターゲットのブラウザが自動的に Cookie: を再送してしまうので、攻撃者がこれを予測する必要はそもそもありません。

>　そうではなくて、input type="hidden" にランダムな値が入っているような場合は、攻撃者は罠にこの値も含めなくてはなりませんから、攻撃が困難になります。

　さらに補足すると、Cookie として使用している値と同じものを hidden 値に含めておき、そちらもチェックするという対策でも大丈夫なはずです (もちろん攻撃者が Cookie を盗めないという前提です。Cookie を盗めたら CSRF 以前の問題なので)。

　そういう意味ではセッション ID とは異なる別のランダム値をあらためて用意する必要は無いので、車輪の再発明は必要ないともいえます。

>> この方法の問題は、Referer を送出しないブラウザで管理画面が利用できなくなってしまうということです。

>逆に言うとそこまでチェックしないと対策にならないわけですね。

　そういうことです。空の Referer を受け付けてしまうと対策にならないということです。

>> たとえば、ユーザが管理画面にログインするたびにランダムな値を生成して、

>セッションIDはまさにそのような性質を持った値である(はずだ)から車輪を再発明する必要はないということですね。

　ああ、この辺は語弊がありますね。

　通常は Cookie の値としてセッション ID が使われますが、その場合はターゲットのブラウザが自動的に Cookie: を再送してしまうので、攻撃者がこれを予測する必要はそもそもありません。

　そうではなくて、input type="hidden" にランダムな値が入っているような場合は、攻撃者は罠にこの値も含めなくてはなりませんから、攻撃が困難になります。

　この辺の説明は難しいですね。

当然ご覧になっていると思いますが、

クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法

http://takagi-hiromitsu.jp/diary/20050427.html#p01

という記事が出ていたので、用語の解説と見比べてみました。

> この方法の問題は、Referer を送出しないブラウザで管理画面が利用できなくなってしまうということです。

逆に言うとそこまでチェックしないと対策にならないわけですね。

> もう一つの方法は、攻撃者が知り得ない値をリクエストに含めておくというものです。

> たとえば、ユーザが管理画面にログインするたびにランダムな値を生成して、

セッションIDはまさにそのような性質を持った値である(はずだ)から車輪を再発明する必要はないということですね。

いつの間にかUTF-8には対応していましたが今度は相対参照の解釈で残念な思いをするようになってました。

>http://bakera.jp/download/gbk.zip

>にリダイレクトされてNot Foundになります。

　あ、なるほど。それはそれは。

　修正しました。

>>>「※未承諾広告」

>>「未承諾広告※」だと思います。

>>http://www.meti.go.jp/kohosys/press/0002876/

>　おおっと。

>　修正しておきます。

片方しか直ってないような。

>　ちゃんと置いてあるのですが、301 だとダウンロードされないのでしょうか。

http://altba.com/bakera/downloads/gbk.zip

にアクセスすると、なぜか

http://bakera.jp/downloads/gbk.zip

ではなく

http://bakera.jp/download/gbk.zip

にリダイレクトされてNot Foundになります。

>http://bakera.jp/hatomaru.aspx/ebi/2003/12

>このへん【何処】のテスト系のURLがまとめて古いままです。

>謎の鳩丸URNを使っていないということですか【謎】。

　hatomaru.aspx の外のリソースは絶対 URL で参照するようになっているので、altba.com へのリンクが残っていたりしたようです。

　修正したつもり。

>あと、gbk.zipがNot Foundで残念な思いをしました【謎】。

　ちゃんと置いてあるのですが、301 だとダウンロードされないのでしょうか。とりあえずリンク直しました。

　ちなみに

http://bakera.jp/downloads/gbk.zip

　は

https://bakera.jp/downloads/gbk.zip

　でも入手可能です。後者は例によってオレオレ証明書なので、特に信頼性が高いということも無いのですが。

http://bakera.jp/hatomaru.aspx/ebi/2003/12

このへん【何処】のテスト系のURLがまとめて古いままです。

謎の鳩丸URNを使っていないということですか【謎】。

あと、gbk.zipがNot Foundで残念な思いをしました【謎】。

SSLでHTTP 1.1ホストヘッダーをサポートするようになっているそうですよね、確か。

>>「※未承諾広告」

>「未承諾広告※」だと思います。

>http://www.meti.go.jp/kohosys/press/0002876/

　おおっと。

　修正しておきます。

>>　できれば花粉シーズン終了後が希望ですが。

>よくわからないのでばけらさんのほうで日時は指定してください。

　これは 30日に決まったらしいので、そのときフィンガープリント値を配布しようかと思っていますが。

>「※未承諾広告」

「未承諾広告※」だと思います。

http://www.meti.go.jp/kohosys/press/0002876/