asp.net core 5とvue3でクロスドメインなspaでcookie認証によるCSRF対策について

前提・実現したいこと

現在、asp.net core 5 と vue3を使ってクロスドメインなSPAの開発を個人で行っております。
※vueとasp.netでドメイン(サーバー)が別
そこでユーザー認証をする際、cookie認証を使用しているのですが、CSRFを懸念しております。
※jwtによる認証も検討しましたが、XSSによるセッションハイジャックの可能性を考慮してやめました。

発生している問題

cookieで認証で行う場合、CSRFが懸念されますが、asp.net coreはantiforgerytokenを使うことでhtmlにtokenを埋め込み、サーバーが返したhtmlからのpost通信だと確認することで、CSRF対策としていると思います。

しかし、今回vueとasp.netでサーバーを分けているため、このtokenを埋め込むことができません。

そこでCORSの設定をすることでCSRF対策になるのではと考えております。
しかし、もし送信元のドメインを偽装することが可能であれば、CSRF対策としては不十分であると思います。

この偽装が可能(考慮すべき)かどうかを調べたのですが、私ではどうなのかわかりませんでした。

質問させて頂きたい内容としては、こちらになります。
①asp.net coreにおいてCORS設定をしても、送信元のドメインを偽装してアクセスしてくることは可能でしょうか(考慮すべきか)？
②ほかにベストプラクティスな認証方法はあるでしょうか？

もしお分かりになる方がいらっしゃいましたら教えて頂けないでしょうか。

行動規範の内容に同意します

回答3件

ベストアンサー

※jwtによる認証も検討しましたが、XSSによるセッションハイジャックの可能性を考慮してやめました。

そこでCORSの設定をすることでCSRF対策になるのではと考えております。

JWT 利用が XSS につながるとか、CORS で CSRF 対策するとかがどういうロジックなのか理解できていませんが・・・

①asp.net coreにおいてCORS設定をしても、送信元のドメインを偽装してアクセスしてくることは可能でしょうか(考慮すべきか)？

質問は、CORS ポリシーが適用された特定の origin を偽装してアクセスしてきても、ASP.NET Core 標準の CORS の機能（詳細下記 URL 参照）で偽装を見破ってアクセス拒否することができるか・・・という意味ですか？

ASP.NET Core でのクロスオリジン要求 (CORS) を有効にする
https://docs.microsoft.com/ja-jp/aspnet/core/security/cors?view=aspnetcore-5.0

であれば、私が知る限りですが、答えは No です。

origin に指定されるドメインと要求 IP アドレスを調べるとかの手がありそうですが（思い付きです）、そもそも CORS はセキュリティ目的ではなく、逆にセキュリティを緩和するもので、そのような機能は考えてもなさそうです。

②ほかにベストプラクティスな認証方法はあるでしょうか？

ASP.NET 標準の anti-forgery トークンが使えない以上、JWT + HTTPS がベストだと思います。そのあたりは以下の記事にいろいろ書いてありますので読んでみてください（日本語版もあります。ただし翻訳がアレです）。

Secure a Web API with Individual Accounts and Local Login in ASP.NET Web API 2.2
https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/individual-accounts-in-web-api

関係ありそうなところを抜粋しておきます：

"Unlike some forms of authentication (such as cookie-based authentication), the browser will not automatically include the access token in subsequent requests. The application must do so explicitly. That's a good thing, because it limits CSRF vulnerabilities."

"Note: In particular, the MVC portion of your app might use forms authentication, which stores credentials in a cookie. Cookie-based authentication requires the use of anti-forgery tokens, to prevent CSRF attacks. That's a problem for web APIs, because there is no convenient way for the web API to send the anti-forgery token to the client. (For more background on this issue, see Preventing CSRF Attacks in Web API.) Calling SuppressDefaultHostAuthentication ensures that Web API is not vulnerable to CSRF attacks from credentials stored in cookies."

"Bearer token. A particular type of access token, with the property that anyone can use the token. In other words, a client doesn't need a cryptographic key or other secret to use a bearer token. For that reason, bearer tokens should only be used over a HTTPS, and should have relatively short expiration times."

投稿2021/05/05 02:32

退会済みユーザー

総合スコア0

ant001

2021/05/05 03:22

>>JWT 利用が XSS につながるとか、CORS で CSRF 対策するとかがどういうロジックなのか ①JWTですとXSSの虚弱性があった場合にトークンを抽出されるリスクがあるが、cookie認証ならhttpOnly属性をつけることでそのリスクがないと考えていた ②なのでcookie認証を使いたい ③しかしcookieの性質上そのままではCSRFの虚弱性があるのでCORSポリシーを適用することで補えないかという考えでした。ですが、ockeghem様から、httpOnly属性をつけてもXSSの虚弱性があるとcookieを抜き取られてしまうことが指摘されており、これだと、XSSのリスクを考えてCookieにする意味はないと思いました。 >>質問は、CORS ポリシーが適用された特定の origin を偽装してアクセスしてきても、ASP.NET Core 標準の CORS の機能（詳細下記 URL 参照）で偽装を見破ってアクセス拒否することができるか・・・という意味ですか？言葉が足りずに申し訳ありません。おっしゃる通りです。 >>JWT + HTTPS がベストだと思いますありがとうございます。提示してくださったリンクも含めてしっかりと調べて検討してみます。

ockeghem

2021/05/05 04:50

「httpOnly属性をつけてもXSSの虚弱性があるとcookieを抜き取られてしまうことが指摘されており」<ここは違います。Cookieは抜き取られませんが、サイトで保持している個人情報の盗み出しや、なりすまし操作はできるので、結局大差ないという意味です。

行動規範の内容に同意します

ASP.NETには詳しくないので、ウェブ開発の一般論として回答します。
まず、以下は誤解を含むように思います。

jwtによる認証も検討しましたが、XSSによるセッションハイジャックの可能性を考慮してやめました。

おそらくhttponly属性を付与したCookieはXSSにより盗まれるが、JWTはXSSにより盗まれる可能性が高いことを指しているのだと思います。しかし、Cookieそのものが盗まれなくても、結局の所XSSのリスクはあまり変わりません。このあたりは以下の動画が参考になると思います。

クロスサイトスクリプティング(XSS)対策としてCookieのHttpOnly属性でどこまで安全になるのか - YouTube

①asp.net coreにおいてCORS設定をしても、送信元のドメインを偽装してアクセスしてくることは可能でしょうか(考慮すべきか)？

CSRFの文脈では、攻撃リクエストは被害者のブラウザから送信されます。この状態で「偽装」できるものは非常に限られます。たとえば、OriginヘッダやRefererヘッダを偽装することはできません。なので、Originヘッダを確認するという対策は考えられます。

②ほかにベストプラクティスな認証方法はあるでしょうか？

更新系のリクエストはPOSTリクエストでJSONとして送信するようにすれば、Content-Typeがapplication/jsonになるので、プリフライトリクエストが送信されます。この前提で、以下の両方を実施すれば、それだけでCSRF対策になります。

プリフライトリクエストのチェック時にOriginを確認するか、Access-Control-Allow-Originレスポンスヘッダをサイトのオリジン固定にする
API側でPOSTリクエストを受け付ける際にContent-Typeがapplication/jsonであることを確認する

また、ウェブAPIのCSRF対策については以下の本に詳しく書いてあります。

体系的に学ぶ安全なWebアプリケーションの作り方第2版

投稿2021/05/05 02:11

ockeghem

総合スコア11705

ant001

2021/05/05 04:13 編集

ありがとうございます、提示して頂いた動画を拝見しました。おっしゃる通り、httpOnly属性を付けることで、XSSの虚弱性があった場合でも、cookieならトークンを盗まれるリスクは無いと考えていました。しかし、XSSに虚弱性があればcookieでもトークンを盗むことはできるのですね... 個人サイトなどではcookieならjsからトークンを取られることはない旨が書かれている記事も多く、httponly属性について調べても確かにxssの虚弱性に対応するもの様だったので鵜呑みにしてしまっていました。やはり一度体系的にセキュリティについては学ぶ必要がありそうですね... フロントとサーバーがクロスドメインでcookie認証を使う場合はockeghem様がご提示してくださった内容が一番いい気がしています。 content-typeをapplication/jsonと確認することでプリフライトリクエストが行われているか確認することができますね。そして被害者のブラウザからOriginを偽装できないのであれば、たしかにこの方法でCSRF対策としては十分だと思いました。ありがとうございます。