5

django の Web サイトhttps://docs.djangoproject.com/en/dev/ref/contrib/csrf/には次のように記載されています。

The CSRF protection is based on the following things:

1. A CSRF cookie that is set to a random value (a session independent nonce, as it is called), which other sites will not have access to.
2. ...

次に、JavaScript によって Cookie から csrf トークンを取得できることも示しています。

var csrftoken = $.cookie('csrftoken');

この 2 つのステートメントは矛盾していませんか? Cross Origin 攻撃があるとします。攻撃者は Cookie から CSRF トークンを取得し、ヘッダーに CSRF トークンを含む POST リクエストを作成できますか? 誰かがこれを説明できますか？

アップデート

同じオリジンのJavaScriptのみがCookieにアクセスできることに気づきました。フォローアップの質問は次のとおりです。

POST リクエストがリクエストの一部として Cookie を自動的に追加し、django の csrf cookie 値が csrf トークンと同じである場合、悪意のあるクロスソース リクエストはとにかく正しい CSRF トークンを持ちますか? (クッキーで)

4

2 に答える 2

2

この投稿があなたの更新された質問に答えると思います：

同一生成元ポリシーのため、攻撃者は実際には Cookie にアクセスできません。ただし、前述のように、ブラウザは POST リクエストに Cookie を追加します。このため、コードからも CSRF トークンをポストする必要があります (例: 非表示フィールド)。この場合、攻撃者は、被害者が悪意のあるフォームを作成した時点で被害者の Cookie に保存されている CSRF トークンの値を知っている必要があります。彼女は Cookie にアクセスできないため、悪意のあるコードでトークンを複製できず、攻撃は失敗します。

ここで、Cookie 以外にトークンを保存する方法を想像するかもしれません。ポイントは、攻撃者がそれを取得できてはならないということです。また、サーバーにはそれを確認する方法が必要です。サーバー側でセッションと一緒にトークンを保存し、クライアント側で「安全な」方法でトークンを保存することを想像できます（「安全」とは、攻撃者がアクセスできないことを意味します）。

以下は OWASP からの引用です。

一般に、開発者は現在のセッションでこのトークンを 1 回生成するだけで済みます。このトークンの最初の生成後、値はセッションに保存され、セッションが期限切れになるまで後続の各リクエストで使用されます。エンドユーザーによってリクエストが発行されると、サーバー側コンポーネントは、セッションで見つかったトークンと比較して、リクエスト内のトークンの存在と有効性を検証する必要があります。リクエスト内でトークンが見つからない場合、または提供された値がセッション内の値と一致しない場合は、リクエストを中止し、トークンをリセットして、進行中の潜在的な CSRF 攻撃としてイベントをログに記録する必要があります。

最後に、セキュリティには次の 2 つのものが必要です。

  • CSRF トークンはコードから送信する必要があります。つまり、悪意のあるコードがそれを認識している必要があります。
  • CSRF トークンは、比較のために「安全な」場所に保存する必要があります (これには Cookie が便利です)。

私は専門家ではありませんが、これが問題の私の理解です。それが役に立てば幸い。

于 2014-05-23T05:24:47.817 に答える
2

CSRF（Cross Site Request Forgery）という名前から、攻撃者が「クロスサイト」（他のサイト）からリクエストを実行する必要があることはすでに推測できます。

「CSRF 攻撃を理解するための鍵は、Web サイトは通常、要求が許可されたユーザーからのものであることを確認しないことを認識することです。代わりに、要求が許可されたユーザーのブラウザーからのものであることのみを確認します。」-ここに引用

したがって、CSRF 攻撃を防げないサイトの場合、攻撃者はどこからでも悪意のあるリクエストを送信できます: ブラウザ、電子メール、端末... Web サイトはリクエストの発信元をチェックしないため、許可されたユーザーがリクエスト。

この場合、すべての Django フォームに、「CSRF トークン」と呼ばれる隠し入力があります。この値は、フォームがレンダリングされた時点でランダムかつ一意に生成され、リクエストが行われた後に比較されます。そのため、リクエストは許可されたユーザーのブラウザからのみ送信できます。(私が知っている) 攻撃者がこのトークンを取得して、Django バックエンドが受け入れることができる悪意のある要求を実行する方法はありません。

十分にクリア？

于 2013-07-30T22:29:20.033 に答える