ASP.NET で安全なアプリケーションを作成するための10のヒント

セキュリティは、あらゆるアプリケーションにとって最も重要な側面の 1 つであり、特に ASP.NET アプリケーションにおけるセキュリティについて語るとき、それは開発に限定されません。

Katie Mikova Last Updated Feb 25, 2025 10min read

安全なアプリには、構成、フレームワーク、Web サーバー、データベースサーバーなどに複数のセキュリティ層が含まれます。この投稿では、ASP.NET で安全なアプリケーションを作成するためのトップ 9 のヒントを見ていきます。

1. Cross Site Scripting (XSS)

この脆弱性により、攻撃者はデータの入力中に悪意のあるコードを挿入できます。JavaScript コード、VB スクリプト、またはその他のスクリプトコードである可能性があります。デフォルトでは、ASP.NET MVC入力を検証し、スクリプトの場合はサーバーエラーをスローします。スクリプトを入力フォームに入れたとします。

上記のページを送信すると、以下のエラーが表示されます。

既定では、かみそりビューエンジンは XSS 攻撃から保護します。ただし、特定のシナリオ (ブログ、ソーシャルアプリケーションなど) では、入力コントロールで html タグを許可する必要がある場合があります。そのために、ValidateInputフィルターをfalseとして追加するオプションがあります。

[HttpPost]
[ValidateInput(false)]
public async Task < ActionResult > Register(RegisterViewModel model) {
    if (ModelState.IsValid) {
        //  Etc.
    }
}

しかし、ここでは完全な要求を検証しないため、これは非常に危険です。モデルに20個のプロパティがあるとすると、すべてが検証から除外されますが、1つまたはいくつかのコントロールでのみhtmlを許可する必要がある場合があります。

そのシナリオでは、このValidateInputを使用する代わりに、特定の ViewModel のプロパティに属性AllowHTMLを次のように配置する必要があります。

public class RegisterViewModel {
    [Required]
    [AllowHtml]
    [Display(Name = "User Name")]
    public string Name {
        get;
        set;
    }
...
}

これで、名前にのみタグを使用できるようになりました。

2. クロスサイトリソース偽造 (CSRF)

CSRF (ワンクリック攻撃とも呼ばれます) は、ユーザーが認証されている信頼できる Web サイトから不正なコマンドが実行される悪意のある攻撃の一種です。実際のシナリオでは、ユーザーが Windows/Cookie ベースの認証を使用してアプリケーションにログインしたとします。ログアウトせずに、ユーザーは悪意のあるサイトにアクセスし、ボタンをクリックします。外部の Web サイトは、非倫理的な操作を行うために Web サイトを介して要求を開始します。要求は認証されているため、有効な要求と見なされます。

CSRF攻撃を防ぐために、MVCはAntiForgeryTokenメカニズムを提供します。そのためには、

@Html.AntiForgeryToken()

また、トークンを検証するには、アクションに Antiforgerytokenフィルターを次のように配置する必要があります。

[ValidateAntiForgeryToken]
public async Task < ActionResult > Register(RegisterViewModel model) {
    if (ModelState.IsValid) {
        // etc.
    }
    return View(model);
}

応答として 2 つのトークンが作成され、1 つは Cookie として設定され、もう 1 つは非表示フィールドに次のように設定されます。

<form action="/Account/Register" class="form-horizontal" method="post" role="form">
<input name="__RequestVerificationToken" type="hidden" value="Qorw9RPABdHoRC7AojnSnQYYuGZP5iPF63UFVSw_[…]" />

フォームを送信すると、両方のトークン(Cookieと非表示フィールド)がサーバーに送信されます。どちらもサーバーで検証され、どちらか一方が存在しないか改ざんされた場合、要求は許可されません。

3. Handling Errors Properly

エラーは必ず発生し、ユーザーに到達する方法を見つけます。しかし、適切に処理されないと、エラーによって内部情報が外部に漏洩し、アプリケーションにとって脅威となる可能性があります。未処理の例外が発生した場合、次の YSOD が一般的です。

しかし、内部コード、物理ファイル構造、スタックトレース、ASP.NET と .NET Framework のバージョンなど、外部にどれだけの情報が表示されているかを確認してください。

簡単な解決策の1つは、customErrorsモードを次のように設定することです。

<customErrors mode="On"></customErrors>

これにより、各エラーが発生した場合に ASP.NET 既定のエラーページが表示されます。より良い方法で処理するには、カスタムエラーモードRemoteOnlyを使用し、エラーが発生した場合に表示される共通エラーページを用意します。

<customErrors mode="RemoteOnly" redirectMode="ResponseRewrite" defaultRedirect="~/Error.aspx" />

ここでは、エラーが発生した場合に備えて、独自のエラーページを表示しています。

4. SQLインジェクション

SQLインジェクションはよく知られたセキュリティの脆弱性ですが、多くのアプリケーションではまだ適切に処理されていません。SQL インジェクションにより、ハッカーは既存のデータを改ざんしたり、トランザクションを変更したり、データやデータベースを削除したりすることができ、ビジネスに大きな損失をもたらす可能性があります。

この手法を使用して、ハッカーは入力を介していくつかの悪意のある SQL コマンドを挿入します。これらのコマンドには、サーバー上で実行されている SQL ステートメントを変更する権限があります。たとえば、アプリケーションでユーザーを認証すると、クラスに次のようにクエリを記述しました。

"select * from Users where UserName='"+txtUserName.Text+"'and Password='"+txtPwd.Text+"' ";

次に、ユーザーはユーザー名に次の値を入力します。

これで、クエリはサーバー上で次のように生成されます。

select * from Users where UserName='’ or 1=1 --' and Password='"+txtPwd.Text+"' ";

これにより、常にアイテムが返され、ユーザーがアプリケーションに入ることができるようになります。

これを処理する最善の方法は、値にパラメーターを渡すか、少なくともパラメーターを次のように使用するSQLストアドプロシージャを使用することです。

"select * from Users where UserName= @username and Password=@password”

5. Click-Jacking

クリックジャッキングも、通常は無視される大きな脆弱性です。この場合、攻撃者は不透明なレイヤーを使用して、ユーザーがトップレベルのページをクリックすることを意図している間に、ユーザーをだまして別のページ上のボタンまたはリンク (銀行 Web サイトの送金ボタンなど) をクリックさせます。

この問題を回避するには、iframe 内の異なるドメインの Web サイトを開くことを許可しないでください。これを実現するには、応答ヘッダー X-FRAME-OPTIONS をdenyまたはsameoriginとして追加する必要があります。ASP.NET では、Global.asaxで次のように設定できます。

void Application_BeginRequest(object sender, EventArgs e)
{
    HttpContext.Current.Response.AddHeader("X-FRAME-OPTIONS ", "DENY");
}

アプリケーションによって送信されるすべての応答にヘッダーが追加されます。

IISを使用して同じヘッダーを追加することもできます。IIS で、目的の Web サイトに移動し、[HTTP ヘッダー] タブに移動し、説明されているようにヘッダー X-FRAME-OPTIONS を含むカスタムヘッダーを追加します。IIS を有効にするには、IIS を再起動する必要があります。

6. アプリケーション構造/ディレクトリリストを非表示にする

アプリケーションのフォルダ構造をエンドユーザーと共有しますか? いいえ！右。例を見てみましょう。私はIISにWebフォーム ASP.NET デフォルトアプリケーションを展開したので、URLにアクセスすると、次のように表示されます。

IISにデプロイされた ASP.NET Webフォームのデフォルトアプリケーションなので、URLにアクセスすると

[アカウント] で使用可能なすべてのファイルとフォルダーが表示されます。この情報は、公開されている場合、アプリケーションにとって潜在的な脅威となる可能性があります。

ディレクトリの参照は、IIS で無効にする必要があります。無効にすると、次のように表示されます。

403 (禁止) を返しますが、このフォルダーが利用可能であることをユーザーに通知するため、依然としていくつかの脆弱性が残ります。利用できないディレクトリにアクセスしようとすると、404が返されます。

このために、独自のカスタム http ハンドラーを作成し、誰かがフォルダーにアクセスしようとするたびに常に 404 を返すように構成できます。

7. Encrypt Sensitive Information in Web.config

多くの場合、重要な情報 (最も一般的には接続文字列) を Web.config に配置します。

接続文字列の任意の部分を暗号化するには、コマンドプロンプトでフレームワークフォルダー(たとえば C:\Windows\Microsoft.NET\Framework\v4.0.30319)に移動し、次のコマンドを実行する必要があります。

aspnet_regiis -pef "connectionStrings" path

ここでのpathは、Web.config が存在するフォルダーのパスです。コマンドを実行すると、次のように表示されます。

同様に、<appsettings>などの他のセクションを暗号化できます。

8. Secure Cookies

Cookieは、Webサーバーとブラウザの間を移動するユーザーのマシン上のブラウザによって保存される小さなテキストです。クッキーは、特定のウェブサイトのユーザー関連情報を保存するために使用されます。ASP.NET では、セッションIDは、Cookieが保存に使用される最も一般的な情報の1つです。

この情報はユーザーのマシンにプレーンテキストで保存されるため、攻撃者にとって格好の標的になる可能性があります。Cookie にデータを保存しないようにするには、有効期限の設定やデータの暗号化など、いくつかの手順を実行する必要があります。これら 2 つのステップとは別に、さらに 2 つのことを行う必要があります。

SSLのみでCookieを許可する
Cookie をHTTPOnlyとして設定します。これにより、クライアント側のスクリプトで Cookie を読み取ることができなくなり、セッションまたはフォーム認証トークンがブラウザーで読み取れなくなります。

Web.config の設定は次のように行うことができます。

<httpCookies domain="String" httpOnlyCookies="true "requireSSL="true " />

9. Encrypting View State

ビューステートは、ASP.NET Web フォームのページポストバック間の状態を維持するために使用される最も一般的な手法の 1 つです。ビューステートは、id__VIEWSTATEのページ上の非表示変数に保存されます。ビューソースでそれを見ると、一連の数字と文字が含まれていることがわかります。暗号化されておらず、base64形式であることを確認してください。誰でも解読して情報を読み取ることができます。

暗号化して改ざん防止にするには、2つのオプションがあります。ViewStateEncryptionModeプロパティがあり、これは aspx ファイルのページレベルで設定することも、アプリケーション内のすべてのページに適用されるWeb.configで設定することもできます。応答に入れる前にビューステートを暗号化します。同様に、別のプロパティEnableViewStateMac は、ページまたは Web.config で true として設定できます。ビューステートコンテンツのハッシュを作成し、非表示フィールドに追加します。次の投稿では、再びハッシュが作成され、検証されます。一致しない場合、ポストバックは拒否され、エラーがスローされます。

10. 応答ヘッダーから機密情報を削除する

ASP.NET アプリケーションのページの応答ヘッダーを次に示します。

ここでは、IISバージョン、構築されたサイト、および ASP.NET バージョンのように必要のない、エンドユーザーにあまりにも多くの情報を開示していることがわかります。攻撃者がそれらのいずれかの抜け穴を知っている場合、その脆弱性を悪用する可能性があります。この情報はデフォルトで追加されるため、特に必要でない限り、削除する必要があります。

バージョンヘッダーを削除するには、Web.config ASP.NET 以下を追加するだけです。

<system.web>
  <httpRuntime enableVersionHeader="false" />
</system.web>

MVCバージョンを削除するには、Global.asax AppliCation_Startイベントに移動し、次のコードを追加する必要があります。

MvcHandler.DisableMvcResponseHeader = true;

X-Power-By は IIS によって追加され、次の構成を追加することで削除できます

  <system.webServer>
        <httpProtocol>
            <customHeaders>
                <remove name="X-Powered-By" />
            </customHeaders>
        </httpProtocol>
  </system.webServer>

結論

この投稿では、セキュリティはあらゆる Web アプリケーションにとって重要であり、適切に処理しないとビジネスに重大な損害を与える可能性があることについて説明しました。ASP.NET Web アプリケーションの最も一般的な 9 つの脆弱性について説明し、これらのほとんどは構成の変更または軽微なコード変更を行うことで修正できることがわかりました。

Infragistics ASP.NET コントロールを使用して、あらゆるブラウザ用のフル機能のビジネスアプリを構築します。今すぐ無料トライアルをダウンロードしてください。

操作方法