水無月ばけらのえび日記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 許容で作ったりした事無いので、大いに関係あるのかもしれませんが。

ランダムトークンがリファラから洩れないように、POST使用を推奨しているのではないでしょうか。ワンタイムトークンなら、関係の無い話ですが。