web-dev-qa-db-ja.com

MVC3のAntiForgeryTokenまたは同様のトークン検証によるJSONハイジャックの回避に関する問題

私は提案された反JSON乗っ取りソリューションを実装するのをためらっています

  1. JSONハイジャックを軽減するための推奨ソリューションには、データを取得するためのREST以外の完全なJSON POSTが含まれます

  2. 代替ソリューション（オブジェクトラッピング）により、ソースコードにアクセスできないサードパーティのコントロールで問題が発生します。

  3. セキュリティトークンを作成する方法、またはセキュリティトークンをWebページ内に安全に配信する方法について、代替ソリューション（以下にリスト）を実装するコミュニティが精査した実装が見つかりません。また、自分の実装を実装するのに十分なエキスパートであるとは主張しません。

  4. リファラーヘッダーは信頼できない

背景

このブログ は、JSONハイジャックに関するCSRFの問題について説明し、JSON POSTを使用してデータを取得することを推奨しています。 HTTPを使用するPOSTデータを取得するのはRESTフルではないため、セッションごとにRESTアクションを有効にするRESTfullソリューションを探しています。またはページごと。

別の緩和手法は、JSONデータをオブジェクトにラップすることです ここで説明 。別の手法が見つかるまで、問題が遅れる可能性があります。

代替実装

私にとって、JSONのjQuery HTTP GETを使用して ASP.NET MVCのAntiForgeryToken を拡張するのは自然なことです。

たとえば、上記のHaackedリンクによると、機密データを取得した場合、次のコードは脆弱です。

$.getJSON('[url]', { [parameters] }, function(json) {
    // callback function code
});

推奨されるPOST回避策を使用してデータを取得することはRESTfullではないことに同意します。私の考えは、URLで検証トークンを送信することです。そうすることで、CSRFスタイルの攻撃者は、完全なURL。キャッシュされているか、キャッシュされていない場合、データを取得できません。

以下は、JSON GETクエリを実行する方法の2つの例です。どの実装が最も効果的であるかはわかりませんが、最初の実装はこのデータをキャッシュする誤ったプロキシからより安全であり、攻撃者に対して脆弱であると推測する場合があります。

http：// localhost：54607/Home/AdminBalances/ENCODEDTOKEN-TOKEN-HERE

または

http：// localhost：54607/Home/AdminBalances？ENCODEDTOKEN-TOKEN-HERE

... MVC3のAntiForgeryTokenまたはそのバリアント（ swtを参照 ）の可能性もあります。このトークンは、上記で選択したURL形式のインライン値として設定されます。

自分のソリューションをロールバックできないようにするサンプルの質問

  1. JSON GET（スラッシュ、疑問符など）を検証するためにどのURL形式（上記）を使用しますか？プロキシは http：// localhost：54607/Home/AdminBalances に応答します http ：// localhost：54607/Home/AdminBalances？ENCODEDTOKEN-TOKEN-HERE data？

  2. そのエンコードされたトークンをどのようにWebページに配信しますか？インライン、またはページ変数として？

  3. トークンをどのように構成しますか？ AntiforgeryTokenに組み込まれていますか、それとも他の方法ですか？

  4. AntiForgeryTokenはCookieを使用します。この場合、バッキングCookieを使用する必要がありますか？ HTTPのみ？ SSLとHTTPのみの組み合わせについてはどうですか？

  5. キャッシュヘッダーをどのように設定しますか？ Google Web Acceleratorに特別なもの（たとえば）

  6. JSONリクエストをSSLにするだけの意味は何ですか？

  7. 安全のために、返されたJSON配列をオブジェクトにラップする必要がありますか？

  8. このソリューションは、Microsoftが提案する テンプレートおよびデータバインディング 機能とどのように相互運用しますか？

上記の質問は、私が前に偽造して自分でこれをしない理由です。言うまでもなく、まだ考えていない質問がまだまだありますが、それでもリスクがあります。

appsecjavascriptcsrfasp.net-mvc
5
goodguys_activate

このテクニックは Jeremiah Grossman によって開拓されました。返されたjsonには、<script>タグを介してページに含めることができるjavascriptも含まれているため、これは唯一の問題でした。 same-Originポリシーはjavascript が結果をフェッチすることを禁止しているため、ほとんどのjson応答をこの方法で悪用することはできません。この問題にパッチを適用するには Googleは解析不能なカフトを使用しました 。

2
rook

この論文 は、さまざまな合理的な防御策を要約しています。

予測できないトークンをURLに含めることは、実際に脅威から防御するための合理的な方法です。 （これについては、ペーパーのセクション3を参照してください。）サーバーに配信するための1つの合理的な方法は、パラメーターとして使用することです。トークンは、セッションCookieのコピー、またはサーバーに既知であり、攻撃者が予測できない秘密の値である可能性があります。これを実装する手法は、おそらくCSRFを防御する手法と非常に似ています。

HTTPとHTTPSは直交する問題だと思います。ここには関連性はありません。

2
D.W.