2012-07-23 18 views
7

は以下がどこdjango.middlewareを適用...これはDjangoのCSRF保護の仕組みですか?

、クッキーの初心者なのでCSRFとDjango(1.4を使用して)、私は間違って行くところ私は、これはそれがどのように動作するかで作ることができるものから、私を修正してください。 csrf.CsrfViewMiddlewareはMIDDLEWARE_CLASSESタプルに含まれています。

csrf_tokenタグが含まれ、関連するビューがRequestContextをテンプレートに渡す場合、ページを要求すると、Djangoには英数字の文字列を含む隠しフォームフィールドが含まれます。 Djangoはまた、ブラウザに、名前がcsrftokenに設定されているクッキーを返し、値を同じ英数字の文字列に設定します。

フォーム提出を受信すると、Djangoは隠しフォームフィールドの英数字の文字列値とブラウザから受け取ったcsrftokenのCookieが一致するかどうかをチェックします。一致しない場合は、403の応答が発行されます。

CSRF攻撃は、iframeを含む悪意のあるWebサイトの形になる可能性があります。 iframeにはPOSTフォームとJavaScriptが含まれています。フォームのaction属性が私のDjangoサイトを指しています。フォームは私のサイトで何か面倒なことをするように設計されており、JSはiframeがロードされたときにフォームを送信します。

ブラウザには、フォーム提出のヘッダーにcsrftokenクッキーが含まれます。ただし、フォームには一致する英数字の文字列を含む隠しフィールドが含まれないため、403が返され、攻撃は失敗します。 iframe JSが正しいhidddenフォームフィールドを作成するためにcookieにアクセスしようとすると、ブラウザはそうしないようにします。

これは間違いありませんか?

+1

私は間違ったことはありません。たぶん、他の人はそうするでしょうが、一般的にはあなたはそれを持っています。 – Zashas

答えて

0

私はあなたが正しいと言うでしょう。あなたはhereを自分で作成しています。

は、要約すると:

  • CSRFトークンは、悪意のあるコードがそれを知っていなければならないことを意味し、コードから送信されます。
  • CSRFトークンはクッキーに格納され、ブラウザによって送信されます。
  • 同じ発信元ポリシーのため、攻撃者はCookieにアクセスできません。
  • サーバーは、クッキーからの「安全な」値がコードからの値と同じであることを単純に検証できます。
1

私はあなたが望むものは、公式のDjangoドキュメントに記載されていると思います。上記のリンク https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#how-it-works

私が試したときに壊れたが、バージョン1.7のために、この作品ました: https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/

+1

リンクをありがとう。 「これにより、Webサイトから発信されたフォームだけをPOSTデータに戻すことができます。」しかしそれはそれを保証する_how_を言っていない。 –

+0

私はDjangoコードベースの一部を最近見ていませんが、他の場所から知っていればUrlParseを使ってベースURLを検出し、ベースURLがホストURLと一致しないとエラーを返すか、黙って失敗します。 (foo://のような別のスキームへの応答を返そうとすると、静かに失敗します – fundamol