2013年09月24日

DjangoのドキュメントがSession Fixationに脆弱な件

Djangoフレームワークのドキュメントを信用しない、大抵の開発者には無関係な話。


PythonのウェブフレームワークDjangoは他のフレームワーク同様、cookieによるセッション機能が実装されている。 セッションのハイジャック手法の一つにSession Fixation攻撃があり、対策としては、セッションIDに紐ついた権限の変更(または昇格)時にセッションIDを再生成するのが一般的と思う。

DjangoのSession周りのドキュメントにも、Session Fixation対策が示唆されているのだが、あたかもフレームワーク側で対策済みかのように書かれている。

In order to prevent session fixation attacks, sessions keys that don’t exist are regenerated:

しかし、有効なセッションIDは攻撃者が普通にウェブアプリにアクセスすれば手に入るので、存在しないIDを無視するだけではFixation対策にならない。これではサブドメインやディレクトベースでアカウント管理される共用サ―バーのようにFixationが起こせる条件下では、攻撃者は誘導されてログインしたユーザーの権限を乗っ取ることができてしまう。

実際にDjango 1.5.2で試すと、セッションミドルウェア実装はセッションオブジェクト(dict)を明示的に変更しても、IDが変化しないようだ。安全よりも性能側に振ってあるのだろう。

自前でIDの再生成を実装しているユーザーには全く影響しないが、ドキュメントをチュートリアルとしてそのまま実装すると、Session Fixationに脆弱かつ可搬性の高いコードが出来上がることになる。 ちなみに、Django組み込みのadminアプリはログイン時にIDを再生成しているので問題はない。ただ、セッションIDを明示的に再生成するAPIが見当たらない……

個人的にはセッションの再生成はフレームワーク側でサポートするべきだと思う(セッションストアの更新時にIDも変更するだけ)し、少なくともドキュメントは正しく防御方法を示すべきだ。再生成による性能劣化が問題なら再生成の必要がないことを明示するAPIを用意すればいい。

PHPのStrict Session関連でもそうだが、存在しないIDを無視するという“Fixation対策”は英語圏でも蔓延しているのだろうか?

posted by ko-zu at 20:44| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/375675327
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。