モバイルアプリでのみ使用されるAPIにCSRF防止ロジックは必要ですか？
私は、Xamarinで開発されたモバイルアプリのみをクライアントとするASP.NET Core Web APIプロジェクトを開発しています。アプリケーションのWebフロントエンドはありません。
ユーザーがモバイルアプリからのみログインしてAPIを使用できる場合、CSRF攻撃を実行できますか？
[〜＃〜]編集[〜＃〜]
APIは、匿名アクセスを許可するように構成されたエンドポイントを呼び出すことにより、ユーザー名とパスワードによる認証を実行します。認証プロセスが成功すると、今後の呼び出しを許可するために使用されるJWTが返されます。
CSRFは、ブラウザーにCookie内のログイントークンがあるWebサイトへの要求をブラウザーに実行させることによって機能します。たとえば、WebサイトAに「ユーザーの削除」機能があり、攻撃者からのWebサイトBがWebサイトAのその機能へのリクエストをトリガーする可能性があります。ブラウザにWebサイトAのセッショントークンを持つCookieがある場合、それを追加しますWebサイトBから発信されたリクエストにもかかわらず、WebサイトAはユーザーが認証および承認されていると認識し、アクションを実行します。
アプリを使用すると、ブロードキャストイベントを使用して別のアプリでアクションをトリガーできる場合がありますが、それはより意図的です。ブロードキャストイベントをリッスンし、それに基づいて行動する場合、機能は明らかに他のアプリに公開され、利用できるようになっています。これは、管理パネルの「ユーザーの削除」機能がページ自体のみを目的としており、他のWebサイトを利用するためのものではないWebアプリケーションとは異なりますが、ブラウザーの動作が異なるため、保護が必要です。
悪意のあるアクターは単にアプリに悪意のあるリクエストを実行させることはできないため、抗CSRFトークンは必要ないと思います。
CSRF攻撃は、次の3つのhttpリクエストコンテンツタイプのリクエストでのみ実行できます：application/x-www-form-urlencoded、multipart/form-dataおよびtext/plain。エンドポイントが要求のコンテンツタイプをチェックして、それがこれら3つのうちの1つでないことを確認すると、そのエンドポイントはCSRFから保護されます。したがって、リクエストのコンテンツタイプをapplication/json、コードでそれをチェックします（jsonパーサーを使用してhttpリクエストの本文を解析するだけでなく、実際にhttpリクエストのコンテンツタイプヘッダーを検証します）。これで安全です。あなたが制御していないクライアントで既存のデプロイ済みAPIの場合、おそらくこれを行うことができないでしょう。
別の優れた保護策として、Cookie認証を許可する必要がある場合は、SameSite: Strictクロスオリジンリクエストを許可する必要がない場合は、Cookie。
保護したいエンドポイントが認証なしでは何もせず、Cookieでなくhttp基本認証ではなくトークンを使用した認証のみを受け入れる場合、ブラウザはAJAXコードからのリクエストを実行します悪意のあるサイトでは、認証されたリクエストを実行できず、それはCSRFに対する完全な防御でもあります。これはあなたのケースのようです。