高木浩光氏が、クロスサイト・リクエストフォージェリ(CSRF)対策が遅れる理由について次のように書いている。 >センスある開発技術者の立場からすれば、「あんな対策も必要、こんな対策も必要」と言われることは、プログラミング美学に反すると感じられることもある。~ >XSSやSQLなどのインジェクション系の脆弱性は、脆弱性であるという以前に、本来正しいコーディングをしていればそういう穴にはならないのだから、美学に反するものではない。バッファーオーバーフローもそうだ。センスある開発技術者にとっては「対策」不要というのが美学だ。~ >その点、CSRF対策が必要というのは、どうにも気持ち悪いものとなる。画面の遷移をすべてチェックするというのであればまだわかるが、一部の画面に姑息な手段で対策を仕掛けないといけないとなると、なんだか美しくないように感じられる。([[クロスサイトリクエストフォージェリ(CSRF)対策がいまいち進まなかったのはなぜか:http://takagi-hiromitsu.jp/diary/20050703.html]] / 高木浩光@自宅の日記) なるほど!これは確かに!逆に言えば美学に訴えればCSRF以外の対策はもっと進むのかも。 先日立ち上げた[[セキュアプログラミングwiki:http://bitarts.net/secure/]]でも、「この攻撃に対抗するためにこういう対策をせよ」というよりも「とにかく常にこういうポリシーでコーディングしなさい」ということを具体的に示して行きたいと思っています。XSSやSQLインジェクションなどでは、それができると考えているけど、確かにCSRF対策は現状どうしても泥臭い穴埋めになってしまう。 CSRF対策については、遷移をガッチリ定義するようなアプリケーションフレームワークがあれば良いように思う。僕の知る限りそういうフレームワークは無い(Strutsは?と言われるかもしれないが、あれは遷移を強制するようなものじゃないよね)。Webアプリケーションのセキュリティ対策のうち、フレームワークの設計次第でカバーできるものは少なくないと思う。「セキュリティに強いアプリケーションフレームワーク」が今後重要になってくると思う。

コメント

2005/7/ 7 23:38 from 大槻昌弥

つい10年ぐらい前は、ヒープやバッファが後何バイトのこっているから何バイトデータを取得しても平気なんていうことを考えてプログラムを書いていたら、豪く遅い領域管理処理になってしまうということで、到底受け入れられそうに無いようにおもえてた。

どちらかといえば、初期のヒープやバッファに収まらないような問題を起こす大きなデータを渡すほうが間違っているというのが常識であったようにおもえる。

そして問題が起きそうな事象はソースファイルのコメントに"AS IS"という言葉を書き加えておけば許される時代だった。

大抵の機械がスタンドアロンで動いていて、運用上に不都合な点が見つからない限り、ユーザは電源スイッチが入らなくなるまで使い倒すのが普通だったので、"AS IS"の呪縛は発動しないものであった。

10年一昔前ともいって世の中の要求が変わったということと、厳格なメモリ管理を可能にできるパフォーマンスを備える機械が現実世界に現れはじめているということで、"AS IS"とい呪文に甘んじていつまでも野放図にしておくのは如何なものかというオブジェクションにも気を配る時代になったのであろう。

ようは"AS IS"で許される問題が、いつのまにか暗黙で"TO DO"に読み替えられるようになったということなのだろう。