ASP.NET Core で静的ファイルを認証で保護する

"Microsoft Docs" サイトに記載のやり方は好きになれず...

C# 等による Web アプリ開発フレームワーク "ASP.NET Core" を用いた、サーバー側実装での話。

数週間ほど前から、新しい ASP.NET Core Web アプリ開発の案件が始まった。

この案件では、この Web アプリ上に配置される静的ファイルの一部を認証で保護、すなわち匿名アクセスは拒否する要件があった。

実のところ、ASP.NET Core 上に配置された静的ファイルを認証で保護する方法についてはわかっていなかった。

そこで、インターネット上で "protect static files, authorization, asp.net core" といったキーワードで検索するところから始めた。

相当数の検索結果がヒットしたが、その多くは "stackoverflow.com" に投稿された質問とその回答だ。

それらの回答は、以下のいずれかの解決策を提案しているケースが多かった。

• (A) 自分で ASP.NET Core ミドルウェアのカスタム実装を作り、静的ファイルミドルウェアより前の HTTP 処理パイプラインにそのミドルウェアを差し込み、認証されていない要求をそのミドルウェアで拒否する。
• (B) 保護したい静的ファイルを "wwwroot" フォルダの外部に配置し、代わりに、[Authorized] 属性付きの自作の ASP.NET Core MVC コントローラでその保護したい静的ファイルを応答で返すようにする。

特に上記解決策のうち (B) については、下記 URL の "Microsoft Docs" サイトでも公式に説明が掲載されている。

しかしながら、詳細はここでは割愛するが、今回案件特有の要件や背景事情をはじめ、いくつかの要因から、上記解決策 (A) (B) はちょっと採用したくなかった。

そこでもう暫し検索結果を読み進めた結果、幸いなことに、「これはよさそう!」と思われる解決案を stackoverflow.com 内で発見した。

その解決策とは、

「静的ファイルミドルウェアが提供している、"OnPrepareResponse" というコールバックポイントをフックする」

という方法だ。

ASP.NET Core 静的ファイルミドルウェアが提供しているフックポイント

静的ファイルミドルウェアを HTTP 処理パイプラインに登録するとき、すなわち Statrtup クラスの Configure メソッド内で UseStaticFiles() メソッドを呼び出すときだが、この際、StaticFileOptions 型のオプション指定をその引数に渡すことができる。

この　StaticFileOptions クラスに、静的ファイルを処理する直前に自前の処理を差し込みすることができる、あつらえたプロパティが用意されていたのだ。

そのプロパティの名前は OnPrepareResponse。

この OnPrepareResponse プロパティに自前の関数を設定すると、静的ファイルをブラウザに返す直前に、この設定した関数を呼び出してくれるのだ。

この自前の関数内で、要求が認証済みであるか否かに応じて、ブラウザへの応答を変更できる。

早速に、"stackoverflow.com" の下記回答にあるサンプルコードをコピーしてきて試してみた。

なお、もちろんのこと、認証ミドルウェアが静的ファイルミドルウェアよりも先に HTTP 処理パイプラインに登録されている必要がある。静的ファイルミドルウェアが要求を処理するより前に、認証済みであるか否かを判定済みにしておく必要があるからだ。

ということで自分のサンプルコードは下記のようになった。

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)

{

  ...

  app.UseAuthentication();

  app.UseStaticFiles(new StaticFileOptions

  {

    OnPrepareResponse = ctx =>

    {

      // 現在の要求が認証済みでないなら...

      if (!ctx.Context.User.Identity.IsAuthenticated)

      {

        // "HTTP 401 Unauthorized" を返す.

        ctx.Context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;

      }

      ...

...なのに秘密のファイルが丸見え!

続けて先のサンプルコードをビルド、実行してみた、のだが...

期待に相反し、保護したはずの静的ファイルが、匿名アクセスでも見えてしまった!

たしかに自分が設定したコールバック関数は、認証されていない要求がきたら、 "401 Unauthorized" HTTP ステータスをブラウザに返せてはいるようだ。

しかしながら、静的ファイルミドルウェアがブラウザにコンテンツを返す処理に対し何の処置もしていなかったので、こんなことになったらしい。

応答全体を阻止する

HTTP ステータス 401 を返すことに加えて、静的ファイルミドルウェアによる応答本文をどうにかして破棄する必要がある。

これを実現するために、あともう2行、先のサンプルコードに追加した。

...

// "HTTP 401 Unauthorized" を返し...

ctx.Context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;

// さらに下記の2行を追加して、応答ボディを破棄!

ctx.Context.Response.ContentLength = 0;

ctx.Context.Response.Body = Stream.Null;

..

この追加の2行で、静的ファイルミドルウェアによる応答ボディをすべて破棄することができる。

というのも、応答オブジェクトの Body ストリームを System.Null に差し替えているためだ。

System.Null への書き込みはすべて単純に破棄され、また、読み取りは空を返すので、静的ファイルミドルウェアは応答ボディに対して何の影響も及ぼさなくなる。

こうすることで、めでたく、秘密のファイルを保護することに成功した。

なお、さらなる考慮事項として、ブラウザキャッシュの挙動にも気を付けた方が良さそうだ。

というのも、自分が試した範囲だと、いちど認証を済ませて保護された静的ファイルを開いたことがある場合、その後サインアウトして未認証の状態でも、ブラウザキャッシュから当該静的ファイルを見ることができた場合があったからだ。

自分は "Cache-Control" 応答ヘッダに "no-store" を指定し、キャッシュに保存することを一切禁止とブラウザに知らせることで、この挙動を回避した。

ctx.Context.Response.Headers.Add("Cache-Control", "no-store");

リダイレクトさせたい場合

未認証の状態で保護された静的ファイルの URL が要求されたときに、HTTP 401 応答を返すのではなく、"サインイン" ページなどにリダイレクトさせることも可能だ。

コードは次のようになるだろう。

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)

{

  ...

  app.UseAuthentication();

  app.UseStaticFiles(new StaticFileOptions

  {

    OnPrepareResponse = ctx =>

    {

      if (!ctx.Context.User.Identity.IsAuthenticated)

      {

        // 任意の URL にリダイレクト可能.

        ctx.Context.Response.Redirect("/")

      }

      ...

まとめ

• 静的ファイルミドルウェアを HTTP 処理パイプラインに登録するとき (UseStaticFiles() 呼び出し) のオプション引数の OnPrepareResponse プロパティを活用することで、静的ファイルを認証で保護することができる。
• 但し、UseAuthentication() 呼び出しを、UseStaticFiles(...) 呼び出しよりは前に済ませておくこと。
• また、HTTP 401 応答を返して要求を拒否する場合は、加えて静的ファイルミドルウェアによる応答ボディ書き込みも阻止すること。
• 完璧に保護するためには、キャッシュ制御についても考慮が必要。
• もちろん、HTTP 401 応用を返すのではなく、特定の URL にリダイレクトさせることもできる。

サンプルコード全体は下記 URL の GitHub リポジトリで公開している。

実際に動作するライブデモサイトも下記 URL で稼働中だ。

https://protect-staticfiles-with-auth-on-aspnetcore.azurewebsites.net/

以上!