PEAK XOOPS - CSRF対策という名のもとに…

XUGJにおいてPukiWiki-Modでマニュアルを書いていたときに、チケットのタイムアウトを喰らいました。しかもこれ、拙作のgticket（もしくはその派生クラス）です。

この時の投稿内容は相当長かったのですが、それをうまく救い出すことができず、本当に悲しみが雪のように積もりました。それがきっかけで、再POST機能を実装したgticket2をリリースすることになるのですが、それは以下のニュースをご覧ください。

http://www.peak.ne.jp/xoops/md/news/article.php?storyid=95

一見すると、PukiWiki-Modにこのgticket2をインストールすれば良いだけ、と思われがちですが、ここの話題はそれではありません。

「CSRF対策」という名の元に行われてきた、数々のユーザの利便性無視こそが問題なのです。

「CSRF対策」が絶対的に必要なのは、「不可逆な処理」に対してです。可逆な処理であれば、たいていの場合、致命的な状況にはなりません。（その遷移状態からチェーンできる攻撃があれば別ですが）

果たして、Wikiの編集操作は不可逆ですか？ 誰かが悪意ある編集をしても、別の誰かがすぐにロールバックできる。それがWikiの売りでしょう？ もし誰かがCSRF攻撃を喰らって、あるエントリを変に書き換えてしまったとしても、簡単に元に戻せるのです。

つまり、Wikiの編集操作にチケットチェックを入れることは無意味です。むしろ、CSRFとは何であるかが判っていない証拠ともなってしまいます。

ただ、ここで面白いのは、それくらいWikiの基本思想が優れているという事実です。「CSRF対策」はどうしてもユーザの利便を損なう形になってしまいますが、Webアプリケーションの設計において、操作の可逆性を担保すれば、それこそが最高のCSRF対策になるのです。

チケットエラーが出た時に特にガッカリするのは、「投稿」「編集」といったアクションです。ですから、これらについて可逆性を用意して、いわゆる「CSRF対策」に頼らないことは、これからのWebプログラマーに必要とされる標準スキルと言えるかもしれません。