7

現在、RESTful API を介してサーバーと対話する、完全に AJAX ベースのアプリを開発しています。API に対する XSRF 攻撃から保護するための潜在的なスキームを検討しました。

  1. ユーザーは認証を受けてセッション Cookie を受け取ります。これも各要求で二重に送信されます。

  2. Javascript で OAuth コンシューマーを実装し、ユーザーがログインしたときにトークンを取得し、そのトークンですべてのリクエストに署名します。

私は OAuth アプローチに傾倒しています。これは主に、API へのサードパーティ アクセスを提供したいためであり、2 つの認証スキームを実装する必要はありません。

この状況で OAuth コンシューマーが機能しない理由はありますか?

4

3 に答える 3

4

ほとんどの AJAX ライブラリは、追加のヘッダー「X-Requested-With: XMLHttpRequest」を設定します。これは、基本的な XSRF 攻撃で偽造するのが困難です (ただし、XSS と組み合わせると可能です)。すべてのリクエストが AJAX であることが予想される場合、このヘッダーが存在することを確認することは、優れた多層防御戦略です。

于 2010-09-09T19:30:01.227 に答える
1

2 段階の要求を使用します。最初の要求ではサーバーに予測不可能なトークンを要求し、2 番目の要求ではトークンを使用した実際のアクションを要求します。

攻撃者はトークンを予測できず、それを読み取ることができないため (同じオリジン ポリシー)、2 番目のクエリで有効なトークンを与えることができません。

ただし、トークンをリークしないように注意してください (グローバル変数の値に影響を与える場合などを使用して json をキャプチャする方法を学びます)。

http://www.google.com/search?q=xsrf+defence

于 2010-09-10T07:59:47.860 に答える
0

XSRFを防ぐ最も簡単な方法は、すべてのRESTfulリクエストのリファラーをチェックして、リクエストが同じドメインからのものであることを確認することです。セッションCookieは状態を維持するために重要ですが、偽造されたリクエストで送信されるため、XSRFに対して防御することはできません。モトローラは、メモリ要件が制限された組み込みネットワークハードウェアでリファラーベースのXSRF保護システムを使用するのが一般的であり、ほとんどのハードウェアでこの方法を使用しています。これは最も安全なXSRF保護ではなく、トークンベースの保護の方が優れていますが、XSSでは両方のシステムをバイパスできます。トークンベースのXSRF保護の最大の問題は、すべてのリクエストに戻って修正するのに多くの時間がかかり、おそらくいくつかのリクエストを見逃してしまうことです。

同一生成元ポリシーを読み、サイトでxssをスキャンしてください。2010A3のOWASPトップ10-壊れた認証とセッション管理も読む必要があります。

于 2010-05-06T09:17:49.457 に答える