CSRF対策をやったらChromeでだけエラーになる

自前でPHPでやったCSRF対策

入力フォーム画面表示時に、

ランダムなトークンを発行してHTMLのhiddenに埋め込む。
同時に発行したトークンをセッションに保持する。

保存ボタンを押したときのアクションで

セッションのトークンとPOSTされたトークンを比較して、
一致していたらOK。不一致だったらエラーとする

上記の対策を入れたら
Chromeの場合だけエラーになってしまいます。
IEだとエラーにならない。

この事象が以前手元の自分の環境で再現したことがありましたが、再現しなくなったので
問題なさそうんだと判断し、リリースしたのですが、
一部のユーザー（全員でない）で事象が発生するようになってしまいました。
自分の環境では再現しないため、原因を追えません。

どういったことが考えられるでしょうか

行動規範の内容に同意します

回答3件

ベストアンサー

以前似たような現象であったのは、ブラウザの複数のウィンドウで同じフォームを開いた場合に、
セッション名が同じなので、セッション側は新しく開いたフォームの値になっており、
その後で、古い方のフォームをSubmitすると、トークンが合わずエラーになるというのがありました。

なお、サイト内に複数フォームがあって、そのセッション名が同じでも同じような現象がおこりますね。

あとは、自分なら原因切り分けのために、ログを出力してみますかね。
セッションのトークンとPOSTされたトークンが一致しなかったときだけ、ログを出力します。
それぞれのトークンもですが、セッションIDなどの情報もほしいですね。
そうすればサーバサイドに保存されているセッションとかも見れますし。

投稿2016/09/29 07:58

編集2016/09/29 07:59

popobot

総合スコア6586

popobot

2016/09/29 08:02

これChromeでのみ起きる問題ではないですが、そもそもChromeでしか起きないという前提も憶測だと思うので、参考までに

redara

2016/09/29 08:27

エラーになると画面的には入力画面に戻されるのですが、その際にも新規でトークンが発行されます。エラー直後に（再度新規のトークンが発行された状態で）POSTし直しても同様の現象であったので、複数ウィンドウが起因してるのは考えにくいです。（Chromeの場合HTMLソースを表示してもトークンが振り直されるので、ソースを表示した直後にPOSTするとエラーになるのは確認できています。）。またセッション名の衝突についても気を付けているつもりです。

redara

2016/09/29 08:30

本番環境でプログラムを戻してしまっていて、テスト環境では自分の環境でしか試せないのでエラー時のログが取れない状態です

redara

2016/09/29 08:40

質問の反応を見た限りメジャーな事象ではなさそうなので、何かしらの特殊な条件（一部ユーザーの特殊なブラウザの設定や特殊な操作方法）が原因な気がしてきました。何かしらフレームワーク標準のCSRF対策を利用するか、自前での別手段を考えたいと思ってきています。

popobot

2016/09/29 08:42

うまくいかないユーザは一度も成功していないということなんですかね！？あと、一時的にトークンが一致しないくてもエラーにならないようにして、ログを取るという手はあると思います。

redara

2016/09/29 08:45

>一時的にトークンが一致しないくてもエラーにならないようにして、 >ログを取るという手はあると思います。アドバイスありがとうございます。ログだけ取って様子を見てみます。

popobot

2016/09/29 08:46

自分はCakephpのCSRF対策機能使っていますが、そういった現象はあまり起きたことないですね。期限切れなどもあるので全く起きないわけでもないですけどね... http://book.cakephp.org/3.0/ja/controllers/components/csrf.html

popobot

2016/09/29 09:07

ログに出すなら、User-Agentも一緒に出力するといいかもしれませんね

redara

2016/09/30 03:03

User-Agentを出力するようにしてわかったのですが、 Firefox起動した直後に入力画面のURLを直接叩いて入力画面を表示させたときに再現することがわかりました。ただ1回失敗して2回目のPOSTではエラーにならなくなるので、前に出ていた繰り返しエラーになる挙動とは多少異なります。

redara

2016/09/30 03:08

ChromeっぽいUser-Agentでもログを吐いているようですが、こちらの原因は特定できていません

popobot

2016/09/30 03:12

Firefox起動直後に開発ツールを起動してネットワーク欄を表示させたあと、URLを直接叩くと理由がわかるかもですね。ただユーザがやっている操作とは思えないので、別の事象かもですねちなみに、フォームとセッションのトークンどちらもそれっぽいんですか？

popobot

2016/09/30 03:14

あとは、アクセスログからそのユーザエージェントのユーザがどういった操作をしていたかをトレースすると原因に近づくかもしれませんね。

redara

2016/09/30 06:04

Firefoxで再現しながら挙動を見てみたのですが、どうもfavicon.icoへのリクエストが入力画面へリダイレクトしてセッションを書き変えてるっぽいので、リクエストを抑止するかfavicon.icoを正しく設置するかして対応してみたいと思います。調査方法等の指南ありがとうございました。大変たすかりました

popobot

2016/09/30 07:02

あー、favicon.icoでしたか。とりあえず、原因がわかってよかったです！

行動規範の内容に同意します