SECRET_KEY

1,235 views
Skip to first unread message

SHIBUYA Katsutoshi

unread,
Oct 8, 2008, 4:18:11 AM10/8/08
to djan...@googlegroups.com
Djangoマスターの皆様、お教えください。
settings.py内のSECRET_KEYというのは、どのように使われ、
これが漏れるとどのようなセキュリティホールが生じるのでしょうか?

なんとなく、保存したセッション情報が他の人に読み取られないよ
うにするのに使われているような気がするのですが、それなら
ば、DBのdjango_sessionテーブルの読み出しをきちん
と防御すれば、SECRET_KEYはバレても問題ないという事なの
かな、と思いました。
あ、ユーザーのパスワードもかな?

---
SHIBUYA Katsutoshi
Official address: shi...@microbrains.co.jp

tsuyuki makoto

unread,
Oct 9, 2008, 11:28:17 AM10/9/08
to djan...@googlegroups.com
こんばんは。
露木です。

SECRET_KEYは、セキュリティ系のtoken等の生成に使われています。
生成アルゴリズムはDjangoのコードを見ればわかってしまいます。
SECRET_KEY以外は、ある程度の短さや範囲内なので、SECRET_KEY
がわかってしまうと、試すべきパターンがかなり減ってしまいます。

簡単に言えば、セッションキー自体を推測しやすくなると言うことです。
セッションキーがマッチしてしまえば、いくら内側でDBを守っても
どうしようもありません。
#SECRET_KEYがばれると、クラッカーが生成したセッションキーが
#実際に存在するセッションキーとマッチする確率がアルファベットと
#記号の50文字分の組み合わせ分上がる

セッションキー以外にもDjango内部で数カ所使われていますので、
そこに関してもクラッキングされる確率が恐ろしく上がります。

2008/10/08 17:18 SHIBUYA Katsutoshi <shi...@microbrains.co.jp>:

Yasushi Masuda

unread,
Oct 9, 2008, 5:35:09 PM10/9/08
to djan...@googlegroups.com
こんにちは。

露木さんの指摘されたセッションキーの生成の他に、 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 さんは書きました:

SHIBUYA Katsutoshi

unread,
Oct 9, 2008, 9:33:59 PM10/9/08
to djan...@googlegroups.com
渋谷です。
露木さん、マスダさん、ありがとうございます。

なるほど、セッションキーの推測ですか。セッション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

unread,
Oct 13, 2008, 7:29:52 AM10/13/08
to djan...@googlegroups.com
Shibuya さん

ご指摘の通りです。ローダがファイルからキーを読み出す限りは、
そのファイルにアクセスできる全てのユーザが該当ファイルの
データを読み出せますね。単にファイルとして外出しにするだけ
なら、根本的な対策ではないと思います。

---
Yasushi Masuda
http://ymasuda.jp/

SHIBUYA Katsutoshi さんは書きました:

Reply all
Reply to author
Forward
0 new messages