2

フォーム認証を使用してasp.net Webアプリケーションがあり、ユーザー(資格情報)がアクティブディレクトリに対してチェックされています。 これで、ユーザーが自分のフォルダを持っているファイル共有にあるファイルにアクセスできるようにする必要があります。Asp.net - 認証されたユーザーに基づいてファイル共有の一部のフォルダにアクセス

は、コンセプトの

まず証拠は、このように動作します :

  1. IISでアプリケーションプールは、いくつかのドメインユーザーで実行するように構成されており、このユーザが共有し、すべてのユーザーフォルダをファイルにR/Wアクセス権を与えられた

  2. ユーザーがWebアプリケーションにログインすると、パス "\\ myFileServer \ username"にあるフォルダのコンテンツのみが表示されます。また、ファイルをアップロードするときには、「\\ myFileServer \ username」に保存されます。

これは機能しますが、まったく安全ではないようです。最初の問題は、アプリケーションプールを実行するユーザーがすべてのユーザーのフォルダにアクセスできることです。さらに大きな関心事は、ユーザ名だけがアクセス権を持つフォルダを決定するということです。

私の質問はこれを行う正しい/より良い方法は何ですか?私はユーザーを偽装することについて読んでいましたが、私が正しく理解すればこれはもう助言されません。そして、Webアプリケーションはインターネットからアクセス可能でなければならないので、私はWindows認証を持っていません。

+0

https:で基本認証を使用し、ファイル共有へのアクセスを偽装できます。 –

+0

フォーム認証を使用するもう一つの理由は、ブラウザが認証情報を要求するのではなく、カスタムログインフォームを必要としていることです。だから私たちはフォームの認証をそのままにしています。問題はファイルシステムに安全にアクセスする方法に残っています。 – Primoz

+0

あなたは偽装にもう通知されていないことをどこでお知りになりましたか?これはこの問題に適しているようです。 –

答えて

1

ユーザーアカウントでアプリケーションを実行するのではなく、適切なR/W権限で実行されるアプリケーション固有のアカウントを作成し、開発チームからこれらの権利を与える人を分けることをお勧めします。

アプリケーションの認証内:GET/POST要求を受け取った後、現在のユーザーがデータを読み書きするパスを確認し、ユーザーが読み取り/書き込みを許可されているパスと相互参照しますから。これらが正しくない場合は、401 NOT AUTHORIZEDレスポンスを返します。それ以外の場合は、今のように操作を続けます。

エンドポイントが適切に保護されており、アプリケーションが独自のアカウントで実行されている場合、セットアップ自体には何の害もありません。これにより、開発者はアプリケーションを通じて他のユーザーのファイルに間接的にアクセスすることができます。これらのチェックを厳密に行う必要があるため、追加のコントロールを追加することができます(アプリケーションが本番サーバーから接続し、制御された方法でサーバーの転送のみを許可するなど)。

+0

システム上で最小限の権限を持つ「svcMyWebApp」のような特定のアカウントの下で既にアプリケーションを実行しています。 – Primoz

+0

私はいくつかのユーザーが既にWebアプリケーションにログインした後に何らかの形でそれを悪用し、自分自身を別のユーザーとして表示し、そのユーザーフォルダーにアクセスすることが懸念されます。 Webアプリケーションは共有上のすべてのフォルダにアクセスでき、ユーザー名に基づいて正しいフォルダにユーザーを制限するだけです。 – Primoz

+0

ユーザ名はユーザ自身が変更できるものですか?そのような場合は本当に危険であり、IDのように変更できない各ユーザの一意の識別子があるかどうかを確認することができます –

1

あなたの問題の説明から私はCustom HttpHandlersがあなたにとって正しい選択だと思っています。どのタイプのファイルがあなたのフォルダに存在するかについては言及していませんでした。簡潔にするために、私はそれがPDFファイルを持っていると仮定して答えます。

あなたのアプリケーションには異なるユーザーが存在すると言われていたので、.NETの組み込み認証マネージャーと役割プロバイダーを使用する必要があります。シンプルなセキュリティフレームワークの設定では、Webアプリケーションのweb.config保護されたフォルダの背後にPDFファイルを配置し、静的ドキュメントへのアクセスを表示する必要のあるユーザーのみに制限するカスタムHTTPハンドラを作成しますそれ。

サンプルHTTPハンドラ:

public class FileProtectionHandler : IHttpHandler 
{ 

    public void ProcessRequest(HttpContext context) 
    { 
     switch (context.Request.HttpMethod) 
     { 
      case "GET": 
      { 
       // Is the user logged-in? 
       if (!context.User.Identity.IsAuthenticated) 
       { 
        FormsAuthentication.RedirectToLoginPage(); 
        return; 
       } 
       string requestedFile = 
       context.Server.MapPath(context.Request.FilePath); 
       // Verify the user has access to the User role. 
       if (context.User.IsInRole("User")) 
       { 
        SendContentTypeAndFile(context, requestedFile); 
       } 
       else 
       { 
        // Deny access, redirect to error page or back to login 
        //page. 
        context.Response.Redirect("~/User/AccessDenied.aspx"); 
       } 
       break; 
     } 
    } 
} 

方法SendContentTypeAndFile

private HttpContext SendContentTypeAndFile(HttpContext context, String strFile) 
{ 
    context.Response.ContentType = GetContentType(strFile); 
    context.Response.TransmitFile(strFile); 
    context.Response.End(); 
    return context; 
} 
private string GetContentType(string filename) 
{ 
    // used to set the encoding for the reponse stream 
    string res = null; 
    FileInfo fileinfo = new FileInfo(filename); 
    if (fileinfo.Exists) 
    { 
     switch (fileinfo.Extension.Remove(0, 1).ToLower()) 
     { 
      case "pdf": 
      { 
       res = "application/pdf"; 
       break; 
      } 
     } 
     return res; 
    } 
    return null; 
} 

最後のステップは、あなたがWebConfigの中で、このHTTPハンドラを設定する必要があるということです そしてあなたがより多くを見ることができます情報here

ここでは完全なです0

+0

これはカスタムバイナリファイルですが、問題ではないと思います。 – Primoz

+0

ファイルはWebサーバーに保存されず、ファイル共有に保存され、各ユーザーにはこのファイル共有に独自のフォルダがあります。 この設定をWeb設定で保護することはできますか?また、ユーザーは時間の経過とともに追加または削除されます。通常、1人または2人のユーザーが週に追加または削除されます。 – Primoz

0

あなたはセキュリティレベルが低い/中程度の場合には良いと思われますが、データの性質が非常に敏感であれば(医療など)、セキュリティに関する最大の懸念事項はユーザーセッションを制御することです。

フォーム認証を使用している場合は、認証されたIDをCookieまたはトークンに格納しています(スティッキセッションを使用している場合はセッションIDを送信していますが、同じ)。この問題は、ユーザーBがユーザーAが働いているマシンにphisicalアクセスしている場合に発生します。ユーザーAが職場を離れて(ちょっとまたは永遠に)、Webアプリケーションでセッションを明示的に閉じていない場合は、少なくともCookie /トークンが期限切れになるまでその身元が残っており、ユーザーBはそれを使用できますASP.NETのアイデンティティシステムはSignOutを実行していないためです。この問題は、ユーザーがサインアウトしたときに、そのようなトークンを無効にする方法を提供する(そして、それらがクライアントマシンから消えるようにする)責任を負うアイデンティティシステムのMicrosoftの悪質な実装すべてにおいて、トークンを使用するとさらに悪化します有効期限が切れるまで有効であるためです。これは対処することができます(高いセキュリティ要件のために完全にはあまり満足できるものではありません)。短いリビングリフレッシュトークンを発行しますが、これは別の話ですが、あなたのケースであるかどうかわかりません。クッキーを使用している場合、ユーザーAがサインアウトするとクッキーは無効化され、リクエスト/レスポンスキュークルから削除されるため、この問題は軽減されます。とにかく、ユーザーがあなたのWebアプリケーションでセッションを閉じるか、または短期間または短期間の切れ目の短いクッキーを設定するようにしてください。

その他のセキュリティ上の懸念は、ASP.NETのAntiforgery Tokenインフラストラクチャの使用を防ぐことができるという点で、CSRFと関連している可能性がありますが、この種の攻撃は、テクニカルユーザーから非常に遠い方法ですあなたのアプリの性質がインターネット上に公開されているか、イントラネット上でのみ公開されている場合など)、そのような特殊な攻撃を心配し、機密性の高いデータがある場合は、フォーム認証よりも複雑なもの(2つの要因、バイオメトリックなど)

関連する問題