1

ユーザーのアカウントにプライベート コンテンツがあるとします。他のソーシャル Web サイトと同様に、ユーザーが自分のアカウントを閲覧すると、ユーザーは自分に関する多くの情報を見ることができます。それらのリクエストはすべてトークン化されていますか? パターンを作成し、すべてのリクエストをトークン化し、処理する前にチェックするのは良い考えですか? 任意の提案？
プライベート アカウント システムに基づくすべてのアプリは、すべての要求をトークン化しますか?

追伸: 考えられる攻撃は次のとおりです。ユーザーがソーシャル Web サイトにログインし ("x")、ログインしたままにし、別の Web サイトに移動します ("y")。Web サイト y には、ユーザーの最新の投稿を含む x サイトの最初のページ コンテンツを取得するボタンがあります。ユーザーがログインしているため、データは次のように表示されます...

リクエストごとに csrf トークン メカニズムをどのようにセットアップしますか? 有効なリクエストの場合、リクエストを最終処理ページにリダイレクトする中間プロセスを設定しますか? または...他のアイデアはありますか？私はここで間違っていますか？私は物事を間違って見ていますか？

ここで私は同じ質問をし、正しい最終的な答えを得ました: https://stackoverflow.com/a/10006276/1284817。ここで検証された回答は、それについて読むのにも適しています。

4

1 に答える 1

0

CSRF トークンは通常、ユーザーに代わって変更を行うもの (POST リクエストなど) にのみ添付されます。攻撃者がプライベート データを閲覧できないようにすることは、はるかに簡単であり、実際、すべての一般的なブラウザーに組み込まれています。

プライベート データを (変更するのではなく)表示する攻撃者を保護するには、通常、ブラウザーの同一オリジン ポリシーに依存し、リクエストがクロスオリジン リソース共有をサポートしないようにします。

あなたが提案する攻撃の具体例では、攻撃者は example.org/private をリクエストし、ブラウザーは私のブラウザーで次のような例外をスローします。

XMLHttpRequest cannot load http://example.org/private. Origin http://attacker.com is not allowed by Access-Control-Allow-Origin.
于 2012-04-04T06:43:39.090 に答える