ValidateAntiForgeryTokenは、Web APIまたはネイティブアプリを介してアクセスできるWeb APIとどのように適合していますか？

Question

CSRFから保護されるASP.NET Web APIを使用してAPIを作成する方法を理解していますが、Web以外の環境（ネイティブモバイルアプリケーションなど）からはアクセスできます。

私の最初の考えは、非ウェブ環境では、偽造トークンの検証に成功することができないということです。これは、フォームが投稿されていないためです。これは本当ですか？検証作業を行う方法はありますか？

有効性を確認する方法がない場合、私の2番目の考えは、Web呼び出しのために偽造トークンを検証するAPIを提供することですが、非Web呼び出しは検証しません。しかし、攻撃者のように、この「非ウェブ」APIをCRSF攻撃に簡単に使用できるように思えるでしょうか？

Web以外のAPIで非Web認証メカニズム（OAuth？）のみをサポートする必要があるため、リクエストをブラウザ経由で再生できないという答えですか？それとも簡単な方法がありますか？

これが唯一の方法であれば、すべての安全でない認証メカニズムを簡単に無効にする方法はありますか？これらのシナリオをサポートするためにASP.NET Web APIに多少シンプルな/幸せなパスがあるべきではありませんか？

Answer 1

CSRFは、クッキー、基本認証、NTLMなどの永続的な認証メカニズムを使用している場合にのみ問題になります。Mike Wassonは、Javascriptでwebapiに対してCSRFを使用していますan example - DelegatingHandlersでバージョンを見ました...

CSRFはWebシナリオの唯一の問題であるため、Web以外の要求をチェックする必要はありません。 jquery、ネイティブなXmlHttpRequestクラス、またはヘッダー（X-Requested-With）が付属していて、XMLHttpRequestの値を持つものであれ、ブラウザからのすべてのajaxリクエスト。したがって、ヘッダーを持つリクエストだけにCSRFチェックを制限することができます。それ以外のものはブラウザ外から来たものでなければなりません。

あなたが認証している場合、私は共有秘密またはOAuthメカニズムを見て、DelegatingHandlerサーバー側を検証して、Webアプリケーションでトークンを置くことができます（CSRFトークンと同じように）永続的ではなく、すべての要求に添付する必要があるため、JFXで取得してX認証ヘッダー経由で送信します。CSRFの問題はありません。ドミニク、いつものように、documentsこの種のものはよく。

Answer 2

最新のMVC4アップデートのSPAテンプレートをご覧ください。彼らには、Web API用Anti-CSRFのサンプル実装があります。

Answer 3

WebAPIのCORS実装を見てください。

http://blogs.msdn.com/b/carlosfigueira/archive/2012/07/02/cors-support-in-asp-net-web-api-rc-version.aspx

その後、WEBAPIサーバー上の有効なURIとしてlocalhostのみを許可することができます。これにより、他のサイトがブラウザで攻撃コードを読み込むことができなくなります。