なんとなく、保存したセッション情報が他の人に読み取られないよ
うにするのに使われているような気がするのですが、それなら
ば、DBのdjango_sessionテーブルの読み出しをきちん
と防御すれば、SECRET_KEYはバレても問題ないという事なの
かな、と思いました。
あ、ユーザーのパスワードもかな?
---
SHIBUYA Katsutoshi
Official address: shi...@microbrains.co.jp
SECRET_KEYは、セキュリティ系のtoken等の生成に使われています。
生成アルゴリズムはDjangoのコードを見ればわかってしまいます。
SECRET_KEY以外は、ある程度の短さや範囲内なので、SECRET_KEY
がわかってしまうと、試すべきパターンがかなり減ってしまいます。
簡単に言えば、セッションキー自体を推測しやすくなると言うことです。
セッションキーがマッチしてしまえば、いくら内側でDBを守っても
どうしようもありません。
#SECRET_KEYがばれると、クラッカーが生成したセッションキーが
#実際に存在するセッションキーとマッチする確率がアルファベットと
#記号の50文字分の組み合わせ分上がる
セッションキー以外にもDjango内部で数カ所使われていますので、
そこに関してもクラッキングされる確率が恐ろしく上がります。
2008/10/08 17:18 SHIBUYA Katsutoshi <shi...@microbrains.co.jp>:
露木さんの指摘されたセッションキーの生成の他に、 SECRET_KEY は
以下の場所で使われています:
* パスワードをリセットするときに送信されるメールに書き込まれる URL の、
認証ビットを生成するのに使われます。 SECRET_KEY が漏れると、
ユーザのパスワードと最終ログイン時刻が既知の場合、パスワードリセット
確認メールを偽装できます。
* フォームウィザード、フォームプレビューの POST 偽装対策に使われています。
SECRET_KEY が漏れると、フォームの隠しフィールドに入っているセキュリティ
ハッシュを偽造して、有効な POST を偽装できます。
* コメントシステム(1.0で書き直されたバージョン)の POST 偽装対策に使わ
れています。SECRET_KEY が漏れると、コメント対象のオブジェクトのモデル
クラスのメタデータ、オブジェクトの主キーが基地の場合、有効な POST
データを偽造できます。
* CsrfMiddleware が自動的に組み込む認証ビットの生成に使われています。
SECRET_KEY が漏れると、何らかの方法で入手したセッションIDを使って、
CsrfMiddleware を通過する POST データを偽造できます。
上記で一番攻撃しやすいのは、最後の CSRF ミドルウェアです。セッション id
はクッキーで伝送されるため、SSL 保護されていない HTTP トラフィックから
容易に盗聴できるからです。
また、一番上のパスワードリセットは攻撃のために集めねばならない情報が
多くて、攻撃を成功させるのは多少難しいかもしれませんが、管理者も含め、
特定のユーザをログインできなくしたり、(サイトの設計によっては)
パスワードを変更できてしまうので、インパクトは大きいですよね。
SECRET_KEY は絶対漏らさないようにしましょう :)
ちなみに、 settings.py は初期化時に読み込まれるスクリプトにすぎないので、
スクリプトの外に SECRET_KEY の内容を置き、 settings.py にローダを書いて
キーを読み込ませられます。そうすれば、保護したい情報を別の場所に置けます。
---
Yasushi Masuda
http://ymasuda.jp/
SHIBUYA Katsutoshi さんは書きました:
なるほど、セッションキーの推測ですか。セッションIDがワンタイム
じゃないんですね。確かに、これならDB防護は意味ないですね。
POST偽装対策についても、よくわかりました。
いずれもワンタイムで十分長いランダムワードを使えば
SECRET_KEYのようなマスターキーを用いなくても対策できるはずな
んですけどね。(もっとも、ワンタイムトークンは安定性の悪い
ネットワークでは使い勝手がかなり悪くなる危険があるの
で、Djangoの方式の方が正解かもしれませんね。)
On 2008/10/10, at 6:35, Yasushi Masuda wrote:
> ちなみに、 settings.py は初期化時に読み込まれるスクリ
> プトにすぎないので、
> スクリプトの外に SECRET_KEY の内容を置き、
> settings.py にローダを書いて
> キーを読み込ませられます。そうすれば、保護したい情報を別の
> 場所に置けます。
しかし、普通のSUExecとmod_pythonを使う限
り、settings.pyも外部に分けたSECRET_KEY記述ファイ
ルも、結局はhttpdの動作ユーザーが読み取り可能でなければ
いけないので、ファイルをわけてもあまり根本的なセキュリティ対
策にはならないのではないでしょうか。
ご指摘の通りです。ローダがファイルからキーを読み出す限りは、
そのファイルにアクセスできる全てのユーザが該当ファイルの
データを読み出せますね。単にファイルとして外出しにするだけ
なら、根本的な対策ではないと思います。
---
Yasushi Masuda
http://ymasuda.jp/
SHIBUYA Katsutoshi さんは書きました: