自動ログイン 二重クリックされた場合に自動ログイン失敗する

Question

Cookieを用いた自動ログインを実装していて質問があります。

前提

手動ログイン時にtokenを発行、DBとCookieに設定しておいて、
ログインセッションが切れた状態でユーザのアクセスがあった場合に、
Cookieに焼かれているtokenからDBを参照、あれば自動ログイン(ログインセッション生成)させています。

参考にしているサイト
https://blog.ohgaki.net/wrong-auto-login-the-answer

質問

この実装方法ですと、
ちょうど自動ログイン処理するタイミングで二重クリックされた場合に、
二回目のアクセスで自動ログインが失敗してしまうかと思います。

一回目のアクセス
　Cookie：token1
　DB    ：token1
　→自動ログイン成功、token1をDBから削除、token2を生成しCookieとDBに設定。

二回目のアクセス
　Cookie：token1　※一回目のアクセスで新しいトークンが焼かれる前に二回目のアクセス
　DB    ：token2
　→token1は削除済でDBに存在しないため自動ログイン失敗。

通信環境が悪かったり誤操作だったり、二重クリックされるケースは容易に考えられるため、
救えるものなら救いたいと考えていますが、良い対応方法はありますでしょうか。
それともセキュリティ面からそもそも対応してはいけないものでしょうか。

例えば、二世代まで有効なtokenとしてDBに保持し続けるなどすれば対応は可能かと思いますが、
その場合のリスクは単純に二倍になると考えてよいでしょうか。

Answer 1

参照されているブログ記事は10年以上前の古いものですから、この記事が書かれた時代から現在では、セキュリティについての考え方もかなり変化しています。この記事では、以下の方法が「間違った方法」として紹介されていますが…

• セッションIDに長い有効期限を設定する （セキュリティ上問題かつ多くのサーバリソースが必要となる）

現在では必ずしも問題とは考えられていませんし、セッションを長期間維持するウェブアプリケーションは増えています。自動的にログインすることと、セッションを長時間維持することでは、セキュリティ上のリスクはそれほど変わりません。
違うとすれば、トークン方式であれば、サーバー側でログイン継続を「まとめて」破棄できる点です。たとえば、ログアウトボタンを押した際に、同じユーザのトークンをまとめて破棄することができますが、参考にされている記事では、そのような処理にはなっていません。これでは、トークン方式のメリットは活かされていないと言えます。

さて、二重クリックの問題はたしかにありえますが、そんなに頻繁にあるわけではないことと、セキュリティ上の脅威が増すわけではないこと、クライアント側でJavaScriptによるチェックもできることなどから、許容してもよいのではないでしょうか。
最初のクリック時にトークンは確かに破棄されますが、その際に新たなセッションを生成して、セッションによるログイン維持が始まっているはずです。このセッションIDは二重クリックの二番目のリクエストには付与されないので一旦「自動ログインに失敗しました」的なエラーになります。しかし、実際にはログイン状態にはなっている（セッションが有効化されている）ので、リロードすればログイン状態になります。なので、「二重クリックが疑わしい場合は画面をリロードしてください」というような（イケてないですが）メッセージを表示してリロードを促す案も考えられます。

二世代まで有効なtokenとしてDBに保持し続けるなどすれば対応は可能かと思いますが

この案は必ずしもうまくいかない気がします。二世代ではなく、トークン削除のタイミングを少し遅らせるような実装が考えられますが、そのように複雑な処理はバグを生みやすく、すべてのバグは脆弱性の原因になります。したがって、できるだけ簡明な処理を心がけるべきです。
二世代の意味を取り違えていました。一回目のリクエストでは削除せず、二回目のリクエストで削除するという意味ですね。この場合、一回目のリクエストの時刻を記憶していて、二回目のリクエストとの時間差が1秒未満であれば二回目のリクエストを許容するような案が考えられます。セキュリティ上のリスクはさほどないと思いますが、処理が複雑になるのが難点です。

このため、二重クリックの問題については上記のような緩和策をとったうえで、問題自体は許容するのが賢明ではないと思います。

Comments

[mokame]

詳細なご回答ありがとうございました。
おかげさまで気になっていた部分が全て解消いたしました。

セキュリティについての考え方の変化、トークン方式のメリットなど大変参考になりました。

自動ログイン処理されるのはセッションが切れた状態でのサイトアクセスですので、基本的にはgoogleなどの検索結果やブックマークからのアクセスが多いものと考えています。
(イメージが伝わりやすいかと思いあえて二重クリックと表現させていただきましたが、返って話をややこしくしてしまったかもしれません、申し訳ありません。)
おっしゃる通り頻繁ではないですが、ある程度の発生は免れずユーザを困惑させる可能性がありますので、最終的に許容するとしても検討自体は必要なレベルと感じ質問をさせていただきました。

いただきましたリロードを促す案、トークン削除のタイミングを少し遅らせる案も検討しておりました。
それぞれのメリット、デメリットの説明までいただきありがとうございます、大変参考になりました。

> 複雑な処理はバグを生みやすく、すべてのバグは脆弱性の原因になります。したがって、できるだけ簡明な処理を心がけるべきです。
この考え方が脆弱性対策の肝なのですね、心がけていきたいと思います。ありがとうございます。

リスクを踏まえた上で、サービスとしてどこまで許容できるのか検討して対応方法を決めていきたいと思います。