このブログのCSRF対策を考え直した

 このブログはASP.NET Core MVCで作ってある。そんでもっていまはKubernetesでPodが二つになるようにスケールしている。開発時からからCSRF対策を入れてある、ASP.NET Core MVCのデフォで入れられるものを。コントローラのメソッドにトークン確認のための属性をつけて、ビューでトークンを仕込むメソッドを置くだけだった。
 Kubernetesで動かす前はコンテナホスティングサービスで複数台スケールさせずに動かしていた。その頃は問題なく記事の投稿ができていた。
 後にKubernetesでスケールさせたとき、記事の投稿でエラーが出るようになった。しばらく考えたのちに、CSRFトークンをサーバでメモリ上に持っていて照合に使っていないかと疑い、Podを一台に減らして投稿を試したところ成功した。どうやらメモリ上にもCSRFトークンを持ち、照合していたんだろう。フォームの隠し要素とクッキーにも入っていたが三点チェックなのか?

 ともあれ、このままではサーバのスケールができない仕組み。スケールさせる必要はないんだけど、自分で作ったからにはスケールさせられるようにしておきたい。
 トークンチェックのメソッドを変更するかーと思った。だが最近、CSRFの対策って増えてたなと思い出した。クッキーのSameSite属性とかLocalStorageとか。

 LocalStorageは個人的にはフロントエンドをやってる人がよく使おうとする印象がある。ここにセッショントークンを入れておけばJSを使わないと呼び出せないのでCSRFは起こせない。
 クッキーを使っているならSameSite属性を使う手も出てきている。このブログのような個人のものなら、外部ドメインからのアクセスに対してセッショントークンを使わせる必要はまったくない。なのでSameSite属性の値として、Strictをつけておけばいいだろう。この方法を取れば、改修はセッショントークンにSameSite属性をStrictでつけること、既存のCSRF対策を外すことの二点で済む。

 そういうわけで、CSRF対策を、セッショントークンのクッキーにSameSite属性をつける方法に変更した。

https://github.com/hMatoba/tetsujin/commit/bcf1334633fbf4c17df7b4dd8a359c3c6a5721e2
comment: 0