新生鳩丸掲示板♯

「/windows/system32/cmd.exe /?」と「/windows/system32/cmd /?」「mkdir /?」は同じ結果が表示され、「mkdir.exe」とだけ打つと「.exe」フォルダができますね。

>リンク先の中の人です。

>基本的に引用しかしていないので詳しいというのはどうも…。

　いやー、すみません。他にまとめサイトのような物が見当たりませんでしたし、本家にリンクするのもどうかなぁと思ったもので……。

　暇を見て記述を修正しておきます。

リンク先の中の人です。

基本的に引用しかしていないので詳しいというのはどうも…。

>次の日記が「2006年12月25日」になっていますが…

　すみません、なんかデータが壊れてました。

　修正しました。

次の日記が「2006年12月25日」になっていますが…

ワルスタリアの作り方はなんですか？あとハグルマンとかいうキンもできれば教えてください！

ミクロファングいいないいなぁ～

ぼくは、けんたという名前にしてたぬキンというキンでした。たしかに、くりきんのできは、悪いと思います。くりきん２だして～～

どんな表紙だろうと思い Amazon に行ってみたら「イメージはありません」画像でした。

このままだと気になって、仕事に手が付かないので（？）後で似たような名前の Maruzen に行こう。うん。そうしよう。

（そして、また余計なものまで買ってサイフが軽くなるという罠）

皆さん、主人公の名前何にしましたか？

主人公の名前でコユウキンは変わるんです

僕はギィっていう名前にして

コユウキンは、「ミクロファング」でした(パッケージにのってる狼みたいなやつ)

前にも見てフーンって感じでしたが、昨日みたらClickOnceということに気づいたのでLoginForm1を逆コンパイルしてみました。

そしたらOK_ClickとCancel_Clickメソッド(Clickイベントハンドラ)しかなくて、中身は両方this.Close();だけだったのですけど(謎)。

POST が CSRF 対策になるか については、なるわけ無いと思うのですが

金床さんの文章「開発者のための正しいCSRF対策」の Version 2.1 以前 に書かれてる「■正しいCSRF対策」のあたりを“誤読”したり“半端に引用”したりすると勘違いする人は出現しそうな予感です。

http://www.jumperz.net/texts/csrf2.1.htm

> 全ての画面遷移にPOSTを用いるアプリケーションには、CSRF攻撃は通用しない。

半端に引用してみました。

※CSRF については ANSI の平田さんが 2001年に書かれた「セッション管理の脆弱性」が、シンプルで分かりやすく、未だに通用する良文章だと思います。

（攻撃側の参考にもなるので URL は略すのですが、ググれば一発という無意味な自己満足）

で、本題から逸れますが…

> GET にすると、処理完了画面を利用者がリロードしただけで、データ更新処理がもう一度走ってしまいます。

更新処理が再度走るかは、作り方次第でどうとでもなるような気がしました。

> 機能要件の面から POST にしろという要請があるはずです。

> ※POST でもリロードできますが、その場合は「データをもう一度送信しますか?」と聞かれるはず。

「データをもう一度送信しますか?」自体が更新処理再走の抑制になるものでもありませんし、再送による再走の対策（シャレのようだ）に POST と GET はあまり関係無いように思えます。

まあ、ログとかリファラに残っちゃうのイヤンとかの理由抜きにしても GET 許容で作ったりした事無いので、大いに関係あるのかもしれませんが。

>例によって某IEの脆弱性にご配慮する話とごっちゃになっているのでは。

　あー、確かに、CSSXSS は GET を拒否すると防げますね。

　CSSXSS の防御法と混同されているということですか……。

>ばけらさんに同意しますが、POSTに限定すべきページでGETも許容されている(意識的にではないと思いますが)ページは珍しくありませんよね。

　そうですね。その点において、「POSTにする」のと「POST以外受け付けないようにする」は意味がかなり違ってくるので、そこも気をつけたいところだと思います。

>mixi内にはあちこち GET で CSRF 可能な箇所がありました。

　なるほど、そうなのですね。それは知りませんでした。

　他にも結構あるのでしょうか……。

>正直、あの時はあまり深く考えずにお勧めしてましたので、（結果はどうであれ）その点は反省。

　いえいえ、とんでもない。面白かったですよ。

「普通は重要なデータ更新を扱う処理を GET にしたり」”してしまうこともある”ので、GETは止めようと言っておこうということです。単にCSRF対策というだけではなくなりますが。また、はせがわさんもおっしゃってますけど、GETによるCSRFもあります。

誤解を受ける可能性があることも含め、ばけらさんに同意します。

例によって某IEの脆弱性にご配慮する話とごっちゃになっているのでは。

ばけらさんに同意しますが、POSTに限定すべきページでGETも許容されている(意識的にではないと思いますが)ページは珍しくありませんよね。

mixi内にはあちこち GET で CSRF 可能な箇所がありました。

例えば、プロフィールの「写真を編集する」にある(写真の)「削除」のURL <http://mixi.jp/delete_photo.pl?number=..&post_key=..> の、post_key パラメータなどはその名残(というか対応)です。

「ことねっと」さんに、超お勧めされたオレオレ証明書を受け入れてみたところ、確認画面からの送信先が http:// となっていて、ステキを通り越して、凄まじさを感じました。

如何に自信を持って勧めたものであっても、配慮が足りないと相手に残念な思いをさせる事があるんですね。

正直、あの時はあまり深く考えずにお勧めしてましたので、（結果はどうであれ）その点は反省。

…と、話をすり替えてるうえに何が言いたいのかよくわからないよ。僕。＞＜