新生鳩丸掲示板♯

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

クロスサイトリクエストフォージェリ（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/

> ちなみにUFJカード (www.ufjcard.com) のサイトには nProtect の脆弱性に関する記述は特にないようですが、危険性を告知したりしなくて良いのですかね。

ここでオレオレ【誰】UFJカードだけど【以下略】とかフィッシングメールを送ればイチコロ【謎】ですね【謎】。

nProtectの利用者はUFJカードとの関係が不明な別途定める発行者のActiveXコントロールをインストールすることに慣らされているわけですし。

いやー、ウイルスバスターでよかった(ピュア)。

>よたついでですが、私の同僚は、一太郎のプリンタのアイコンを見て、ずっと墓石のイメージをしていたらしい.

　これですか

突然で申し訳ありません。

よたついでですが、私の同僚は、一太郎のプリンタのアイコンを見て、ずっと墓石のイメージをしていたらしい.

>　と言われても、Firefox の問題なのでは。

最近うちのサイトにもFirefoxで頻繁に訪れる方がいて、サーバーは"application/xhtml+xmlをリクエストされた場合だけapplication/xhtml+xmlで返す"設定ですので、私も他人事ではないような気がします。

>　サーバ側で何かできることがありますか?

サーバー側というかHTMLで、onunloadイベントハンドラにCookieを生成する関数を仕込んでおいて、移動したときに値が以前と変わっていれば保存するようにしてみるとか。

JavaScript有効でないと利きませんが、以前からそんな仕組みがほしいと思っていたので、ゴールデンウィーク中にでも実装してみようかと。

>は～い♪

ちょっとくだけすぎました。くだけるのは私の頭だけでよいのです。反省しました。えむけいさん、いろいろありがとうございました。

>なにがどうなのかよくわかりませんが、とりあえずFirefoxの.xpiの場合、Refererが送られなければダウンロードするリソースのURIをもとに情報バーを出すかどうか判定して、Refererが送られればリンク元のページのURIを元に判定します。はっきり言ってホゥルだと思うのですが。

うぅぅうぅ。

>「Webサイトによるソフトウェアのインストールを許可する」の許可リストもhttpsに限定するオプションがありません。

うぅぅうぅ。

>すり替えはできないけどステータスバーやアドレスバーから証明書が確認できない系ですか。そもそも信頼できないサイトのリンクは踏まないことが鉄則ですから前提自体にあまり意味がないと思います。

SSL利用可能なサーバサイド運営側としてはhttpsなページからダウンロードさせるのが真っ当だとあらためて思いました。なので、庶民は信頼できるさきさまのサイトのhttps://なアドレスをもつオブジェクトへのリンクを作るときにはあらかじめよく考えておきましょうということになります。

>もしFirefox以外の話がしたいのであれば新たにスレ立て【謎】を希望します。

は～い♪

>ダウンロードさせる（させたい）オブジェクトそのものにデジタル署名がしていなくて、オブジェクトのURIがhttpsスキームのURL になっていて、それをhttpスキームで開いたページのanchor要素で記述してあったらどうなるのでしょう。なおSSLサーバ証明書はまっとうなものを用意してあるものとし、framesetなど変なのは使っていないサイトであるとします。

なにがどうなのかよくわかりませんが、とりあえずFirefoxの.xpiの場合、Refererが送られなければダウンロードするリソースのURIをもとに情報バーを出すかどうか判定して、Refererが送られればリンク元のページのURIを元に判定します。はっきり言ってホゥルだと思うのですが。

「Webサイトによるソフトウェアのインストールを許可する」の許可リストもhttpsに限定するオプションがありません。

>拡張やプラグインで開く場合、ローカルにあるブラウザとは無関係なアプリケーションで開く場合。OSが開くことになっている場合、など多種ありそうですが、利用者がローカルに保存しにいくケースとナニゲにブラウザの一時ファイルフォルダ（何？）にあるうちに開く場合とがありますし。さて、SSLサーバ証明書には意味が出てきますでしょうか？

すり替えはできないけどステータスバーやアドレスバーから証明書が確認できない系ですか。そもそも信頼できないサイトのリンクは踏まないことが鉄則ですから前提自体にあまり意味がないと思います。

>RFCながめていてもよくわからなかったので何卒ご意見を賜りたく。

>※PDFを自己解答書庫にしてダウンロードさせているサイトがあったこともあり、ちょっと自分の勉強不足を痛感しました。サーバ側で指定するmedia type まで考えると何が一番正しい姿だったのかちょっと不明な気分です。ダウンロードさせるのはなんでもかんでも

>Content-type: application/octet-stream で Content-Disposition: attachment って何か腑に落ちないですし。あうあう。

>ひとつのポストでごった煮に質問を混ぜるのを本当の意味でのマルチポストと言うのではないかとも、たった今思いました。

もしFirefox以外の話がしたいのであれば新たにスレ立て【謎】を希望します。

解凍のtypoです…