wasbook reading #4

仕事が忙しくて、一週空いてしまった。
「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」読書会の第4回。
今回読んだのは以下の範囲。どんどん仕事が忙しくなってきて、なかなか時間が取れなくなってきたけど、なんとか続けたい。まだまだ先は長いけど。

  • 4章 Webアプリケーションの機能別に見るセキュリティバグ
    • 「重要な処理」の際に混入する脆弱性
    • セッション管理の不備

4章 Webアプリケーションの機能別に見るセキュリティバグ

「重要な処理」の際に混入する脆弱性

主にCSRFのお話。
最近だとCSRF対策を簡単に組み込めるフレームワークがある(RailsとかTomcat7の機能とか)けど、自力でやろうとするとけっこう辛い。
XSSの仕組みや攻撃方法をちゃんと理解できていれば、CSRFの仕組みもすぐに分かると思う。逆にXSSの理解が曖昧だと、CSRFの仕組みがよくわからなくなってしまうと思う。まあつまり、昔の僕のことだけど。
そういう意味でもXSSの仕組みをちゃんと理解しておくと、XSSとはどのように違うのかといった方向から考えることができると思う。
CSRFは設計段階から対策を盛り込む必要があって、これがなかなか大変だ。すべての画面で対策を行うと今度は操作性が下がるし、あとから実施するのは結構大変だから。でもいろいろ調べてみると、最近のフレームワークなどであれば、ある程度簡単に対応できそうなものもあるっぽい。上述のRailsとかTomcat7のフィルタ(技術者が知っておきたいTomcat 7の新機能20連発 (3/3) - @IT)とか。Seasar関連のプロダクトはどうなんだろう。どんな感じなのか、実際に試してみたい。いつかどこかで…。
対策が簡単であれば、あとからCSRF対策を行うことも簡単になる。最初から考えておくことの重要さは変わらないけど、あとからでも対策できれば尚良い。
CSRF対策の説明で、ワンタイムトークンの使用は推奨されないとある。この部分については 高木浩光@自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由, hiddenパラメタは漏れやすいのか? も合わせて読むとよさそう。

セッション管理の不備

セッションハイジャックの話が中心。
普通のユーザがセッションハイジャックされても被害はある程度限定されるが、管理者権限のあるユーザがセッションハイジャックされると大変だよねと話題になった。確かにそれはすごくまずい。
暗号論的擬似乱数生成器が出てきた。これがよくわからない。一応以下のWikipediaには眼を通した。

暗号論的擬似乱数生成器は、現実的な時間内に乱数値を予測できないことが理論的に保証されているとある。
きっと非暗号論的擬似乱数生成器は、現実的な時間内に乱数値を予測できてしまうだと思う。それはわかる。
非暗号論的乱数生成器でセッションIDを発行してしまうと、どうしてセッションIDが推測されてしまうのかがわからなかった。きっといくつか前提条件はあると思うのだけど、どういう条件でセッションIDが推測されてしまうのかもわからなかった。
とりあえずJavaの場合は java.security.SecureRandom を使えばよさそう。ふむ。apache commons math の javadoc を読むと、普通のrandomを使っているみたい。すげー遅いんだよ SecureRandomは、っ書いてある(RandomDataImpl (Commons Math 3.0-SNAPSHOT API))。
あと、僕は絶対にやろうと思わないけど、セッションIDを自分で作っちゃだめ、絶対。Javaなら普通にSessionに情報入れると思うけど、変なIDを自作する人がいるかもしれない。いないと信じたいけど。
セッションIDの固定化でセッションアダプションについて説明が書いてあったが、この問題は全く知らなかった。Javaではこういう問題(機能?)がないから。外部で指定されたセッションIDをそのまま利用するって、いったいどんなメリットがあってこの機能があるのだろう。ASP.NETでもあるみたいだから、なにか合理的な理由もあるのだろうか。

今回のまとめ

CSRFはやっぱり「はまちちゃん事件」が代名詞だと思う。やっぱり実例を知っていると、攻撃の内容も理解しやすいと思う。でも対策はちょっと面倒、というか対策は分かるけど、対策を取るのが面倒だ。これがもっと楽になるといいな。なんとか関数でページを指定するとCSRF対策になりますよ、とか。
セッションハイジャックについては、これもSNS関連になってしまうけど、サンシャイン牧場の課金問題が最近だと有名だと思う。気を付けなくては。
本論とは関係ないけど、WASBOOKを読んでいると J2EE という単語がちょこちょこ出てくる。これはJavaプログラマとしてはちょっと哀しい。J2EEは結構古い呼び方なので、今後の改版や増刷で JavaEE になるといいな。


wasbookに関するものは、こちらのタグで。



電子書籍版はこちら。