2

私は、csrf攻撃からの保護のためにDjangoのcsrfトークンを使用するDjangoサイトを持っています。フォームの1つは、ログインしていない人を含め、一般の人がアクセスできます。

Csrfトークンは、クロスドメインリクエストに対する保護を提供することになっています。

編集:(私のコメントからの引用）「しかし、承認を必要とせずに許可された投稿リクエストの場合、csrfは些細なスパムフィルターに勝るものはありません（captchaはここでうまくいくでしょう）。認証をまったく必要としないページにCSRFトークン（たとえば30分後に期限切れ）を含めます（ただし、私のサイトはそれを行っているので、最初にこの投稿を作成しました）」

また、この場合、ブラウザのjsコンソールでそのページをフェッチし、特定のxpathを介してcsrfトークンを取得し、そのcsrfを使用して任意のデータを投稿することができます。また、手順は簡単に再現でき、サイトに対して特定の攻撃を設計できます。その場合、Djangoサイトでは、毎回「csrfmiddlewaretoken」以外のcsrfトークンが見つかります（reddit、pinterestなどのサイトが含まれます）。

私が見る限り、少し難しくすることを除けば、csrfトークンはあまり役に立ちませんでした。

私が欠けている側面はありますか？私の実装は間違っていますか？そして、私が正しければ、csrfトークンをhtmlソース（特に認証を必要としないもの）で飛ばすのはばかげていますか？

4

2 に答える 2

3

この質問には、同じことについて本当に良い答えがいくつかあります。また、そこにある最後の回答は、トークンのフォームを（javascriptを介して）スクレイプし、それを使用して（javascriptを介して）POSTリクエストを送信することが技術的に可能であるという事実に対処しています。しかし、被害者はログインする必要があります。

CSRF保護のポイントは、ランダムなユーザーをだますことを明確に防ぐことです。クライアント側のエクスプロイトとは何の関係もありません。また、保護の一部には、クロスサイトオリジンリクエストの拒否が含まれることを考慮する必要があります。リクエストは、ターゲットサイトと同じ発信元から送信される必要があります。

結論として、CSRFには価値があります。その保護の領域ですが、それがすべてではありません。そして、あなたはすべてに対して防御することはできません。

CSRFに関するブログ投稿からの引用：

秘密の隠されたフォームの値。各フォーム（通常はユーザーセッションに関連付けられている）で一意のサーバーフォーム値を送信し、フォームの投稿で同じ値が返されることを確認します。XmlHttpRequest関数の同じドメインのリクエスト制限のおかげで、攻撃者はJavaScriptを介してターゲットユーザーとしてリモートフォームを単純にスクレイプすることはできません。

...そして興味のあるコメント：

私はjavascriptウィザードではありませんが、悪意のあるページの非表示のiframeにリモートページをロードし、javascriptで解析して非表示のトークンを見つけ、ユーザーが（おそらく）送信しようとしているフォームに入力することは可能ですか？正しい値？

  • デビッドグッドウィン2008年9月24日午前2時35分

@David Goodwin：いいえ、同一生成元ポリシーは、悪意のあるページがiframeのコンテンツを読み取るのを防ぎます。

  • 2008年9月24日午前3時3分のリコ
于 2012-06-09T23:02:35.947 に答える
0

フォームが公開されていて認証を必要としない場合、誰か（悪意のあるサイト/プラグイン/人を含む）がフォームに投稿するのを妨げるものは何もありません。その問題は、CSRFではなくスパムと呼ばれます。

これを読んでください：http：//en.wikipedia.org/wiki/Cross-site_request_forgery

CSRFには、認証されたユーザーになりすましてフォームに投稿する悪意のあるサイトが含まれます。

于 2012-06-09T19:33:33.637 に答える