正しい順序でミドルウェア パイプラインに追加されていない ASP.NET Core ミドルウェアは、意図したとおりに機能せず、その結果、アプリケーションはさまざまなセキュリティの問題にさらされたままになります。

例 1:UseHttpsRedirection() メソッドは、HTTPS リダイレクション ミドルウェアをミドルウェア パイプラインに追加します。これにより、安全でない HTTP リクエストを安全な HTTPS リクエストにリダイレクトすることが可能になります。ここに示すように、間違った順序で指定されると、リダイレクト前にリストされたミドルウェアを介したリクエスト処理の前に、意味のある HTTPS のリダイレクションは行われません。これにより、HTTP リクエストを、安全な HTTPS 接続にリダイレクトされる前にアプリケーションで処理できるようになります。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

正しい順序でミドルウェア パイプラインに追加されていない ASP.NET Core ミドルウェアは、意図したとおりに機能せず、その結果、アプリケーションはさまざまなセキュリティの問題にさらされたままになります。

例 1:UseHttpLogging() メソッドは、HTTP ロギング ミドルウェアをミドルウェア パイプラインに追加します。これにより、ミドルウェア コンポーネントによるログ記録が可能になります。ここに示すように、間違った順序で指定されると、UseHttpLogging() への呼び出しの前にパイプラインに追加されたミドルウェアはログを記録しません。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

例 2:UseWC3Logging() メソッドは、W3C ロギング ミドルウェアをミドルウェア パイプラインに追加します。これにより、ミドルウェア コンポーネントによるログ記録が可能になります。ここに示すように、間違った順序で指定されると、UseWC3Logging() への呼び出しの前にパイプラインに追加されたミドルウェアはログを記録しません。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

証明書の検証モードを None に設定すると、証明書の検証プロセス全体が無効になり、アプリケーションを中間者 (Man-in-the-Middle) 攻撃の危険にさらすことになります。このモードは、実運用環境では使用しないでください。

cookie は通常、個人情報、認証トークン、ユーザーのアクティビティの履歴など、ユーザーに関する重要な情報を保存するために使用されます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie の内容を保護し、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

ASP.NET アプリケーションは、デバッグ バイナリを生成するように設定できます。これらのバイナリは詳細なデバッグ メッセージを提供するため、実運用環境では使用しないでください。debug 属性 (<compilation> タグの属性) は、コンパイルされたバイナリにデバッグ情報を含めるかどうかを定義します。

デバッグ バイナリを使用すると、アプリケーションが、それ自体に関するできるだけ多くの情報をユーザーに提供します。デバッグ バイナリは、開発環境またはテスト環境で使用することを目的としており、実運用環境にデプロイするとセキュリティ リスクを引き起こす可能性があります。攻撃者はデバッグ出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

イベント検証は、ポストバック要求内のイベント コントロールを検証して、コントロールが最初のページ読み込み時に表示されたときと同じであることを保証する ASP.NET のセキュリティ機能です。この機能が無効になっていると、攻撃者が、改ざんされたイベント コントロールを使用してクロスサイト リクエスト フォージェリ攻撃を実行し、不正アクセスや Cross-Site Scripting 攻撃などを引き起こす可能性があります。

例 1: 次の Web アプリ構成では、イベント検証が無効になっています。

...
<system.web>
    ...
    <pages enableEventValidation="false">
    ...
    </pages>
</system.web>

例 2: 次のサーバー ページ ディレクティブは、イベント検証を無効にしています。

<%@ Page ... EnableEventValidation="false" %>

セッションを開いたままの時間が長いほど、攻撃者がユーザー アカウントを侵害するチャンスは増えます。セッションをアクティブなままにしておくと、攻撃者がユーザーのパスワードを総当たり攻撃で盗んだり、ユーザーのワイヤレス暗号鍵を解読したり、開いているブラウザーからセッションを乗っ取る可能性があります。認証タイムアウトが長くなると、メモリが解放されなくなり、作成されるセッションが多くなりすぎて最終的に Denial of Service 攻撃が発生する可能性があります。

例 1: 次の例は、認証タイムアウトが 1 時間に設定された ASP.NET MVC を示しています。

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

タイムアウト属性が指定されていない場合、認証タイムアウトのデフォルト値は 30 分です。

デフォルトでは、HTTP ヘッダー値を設定する API に改行文字が送信されることは .NET フレームワークによって阻止されます。しかし、HttpRuntimeSection オブジェクトで EnableHeaderChecking プロパティを false に設定すれば、この動作をプログラムによって無効にできます。

例 1: 次のコードは、ヘッダーのチェック機能を無効にしています。

Configuration config = WebConfigurationManager.OpenWebConfiguration("/MyApp");
HttpRuntimeSection hrs = (HttpRuntimeSection) config.GetSection("system.web/httpRuntime");
hrs.EnableHeaderChecking = false;

このチェックが無効に設定されていると、ヘッダーを設定する API に対してユーザー入力を許可しているコードが HTTP Response Splitting などの攻撃に対して脆弱になります。

プログラムは、3 つの方法のいずれかで X.509 証明書を検証するように設定できます。デフォルトでは、証明書は信頼チェーンを介して検証され、信頼されたルート機関に戻ります。この設定は ChainTrust と呼ばれ、証明書が有効であることを最大レベルで保証します。デフォルトでは、すべての証明書は ChainTrust を使用して検証されます。

信頼されたルート機関が発行したものではない証明書を利用するには、PeerTrust または PeerOrChainTrust を設定することで、ピアが発行した証明書を信頼するようにプログラムを設定できます。これらの設定は、証明書によって付与されるセキュリティのレベルを大幅に低下させるため、実運用環境では使用しないでください。

cookie は通常、個人情報、認証トークン、ユーザーのアクティビティの履歴など、ユーザーに関する重要な情報を保存するために使用されます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie の内容を保護し、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

web.config にある configuration/system.web/authentication/forms 要素の cacheRolesInCookie 属性が true に設定されている場合、各ユーザーのロールは cookie にキャッシュされます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

ASP.NET Web サービスは、Web サービスとの通信方法を説明するドキュメントを自動的に生成することにより、Web サービス クライアントの開発を容易にします。

ドキュメント プロトコルが有効になっている Web サービスは、ブラウザーのリクエストを受信すると HTML 形式のページを生成します。

この HTML 形式のページでは、次の情報について説明しています。
1.サポートされている操作
2.各操作が受け入れるパラメーター
3.これらのパラメーターで渡される必要があるデータのタイプ

ドキュメント プロトコルは、XML 形式の Web サービス記述言語 (WSDL) ファイルも生成します。このファイルは、アプリケーションが Web サービスへのリクエストを構造化する方法を理解できるように設計されています。この情報は、開発者、特にパブリック Web サービスのクライアントを作成する開発者にとって非常に役立ちます。しかし、プライベート Web サービスの機能に関する詳細情報を公開すると、悪意のある攻撃者が Web サービスを悪用するリスクが高まります。ドキュメント プロトコルは、Web サービスのすべての関数とパラメーターを必ず記述します。これは、それらの関数のサブセットのみをパブリック アクセス可能にすることが意図されている場合も同じです。

この ASP.NET Core アプリケーションは、安全な接続を介したアクセスのみを許可する、機密性の高いコントローラーまたはコントローラー メソッドを設定しません。

ASP.NET W3Clogger.loggingFields は、プライベート データやシステム情報などの機密データのログ記録を許可するように構成できます。
このデータには、HTTP リクエストや HTTP レスポンスに関連する機密情報 (クライアント/サーバー IP、サーバー ポート、ヘッダー Cookie、サーバーにアクセスした認証済みユーザー名など) が含まれる場合があります。
データ侵害が起こると、攻撃者はこの情報を使用して次のことを行うことができます。
- 機密情報を盗む、または上位の権限を持つユーザーになりすます。
- 内部サーバーを見つけて、制限付きリソースに不正アクセスする。
- 検出したサーバーについて報告されている既知の脆弱性を悪用することに注目して攻撃を企む
例 1: 次のコードは、検証が無効になっているコントローラーのアクション メソッドを示しています。

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;
    ... )

Example 1 は、ClientIpAddress、ServerName、ServerIpAddress、ServerPort、UserName、Cookie などの機密データを含む、HTTP リクエスト内のすべてのフィールドのログを記録するために、フラグ All を使用して W3Clogging を構成する方法を示しています。

ASP.NET アプリケーションを、フレームワークのデフォルトのページではなく、カスタム エラー ページを使用するように設定する必要があります。デフォルトのエラー ページには発生したエラーに関する詳細情報が表示されるため、実運用環境では使用しないでください。mode 属性 (<customErrors> タグの属性) は、カスタムとデフォルトのどちらのエラー ページを使用するかを定義します。

攻撃者は、デフォルトのエラー ページから得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

デフォルトでは、ASP.NET は、ペイロード (ViewState、FormsAuth cookies、ScriptResource.axd URL など) を復号化する前に暗号シグネチャを内部的に検証し、得た値をアプリケーションに渡してさらに処理します。ただし、この機能を aspnet:UseLegacyEncryption 設定を使用して変更し、ペイロードを復号化する前に暗号シグネチャの検証を無効にすることが可能です。これにより、悪意のあるクライアントが暗号化されたデータを復号化、偽造、または改ざんする可能性があります。

例 1: 次の例では、aspnet:UseLegacyEncryption が true に設定されています。

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

ASP.NET アプリケーションは、ユーザー名とパスワードのペアを、ASP.NET アプリケーションの web.config ファイルにある <credentials> 要素に格納できます。パスワード形式は、平文、MD5、および SHA1 がサポートされます。

平文または弱い暗号化アルゴリズムを使用して保存されたパスワードは、アプリケーションの設定ファイルにアクセスできる人なら誰でもアクセスできます。これには、アプリケーションがホストされているマシンや、アプリケーションがあるソース コード リポジトリなどが含まれます。

例 1: 以下の web.config エントリは、パスワードを誤って平文で保存しています。

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET は、configuration/system.web/authentication/forms/credentials 要素の passwordFormat 属性で指定される、3 つの形式で保存された資格情報パスワードをサポートしています。この属性に使用できる値は次のとおりです。

Clear - パスワードが平文で保存されていることを示します (最も安全性が低い)
MD5 - パスワードの MD5 ハッシュが保存されていることを示します
SHA1 - パスワードの SHA1 ハッシュが保存されていることを示します (最も安全性が高い)

MD5 ハッシュは平文よりも安全ですが、研究者によると、MD5 ハッシュ アルゴリズムに対するブルートフォース攻撃も発見されています。現時点で、SHA1 ハッシュは、引き続きこのような攻撃に対して適切な保護を提供しています。

FormsAuthentication.RedirectFromLoginPage() メソッドにより Authentication チケットが発行されます。この認証チケットを使用すると、ユーザーは一定期間認証された状態となります。このメソッドが 2 番目の引数 false と一緒に呼び出されると、web.config で設定される期間は有効のままとなるテンポラリの Authentication チケットが発行されます。このメソッドが 2 番目の引数 true と一緒に呼び出されると、Persistent Authentication チケットが発行されます。.NET 2.0 では、Persistent Authentication チケットの継続期間は web.config の値が基準となりますが、.NET 1.1 では、Persistent Authentication チケットに 15 年という途方もなく長いデフォルトの継続期間が設定されています。

Persistent Authentication チケットを長期間有効のままにすることを許可すると、次のようにユーザーおよびシステムが脆弱性にさらされることになります。

ログアウトに失敗したユーザーに関するセッション乗っ取り攻撃を受ける期間が長くなる。

攻撃者が推測可能な有効なセッション ID の平均数が増大する。

攻撃者がユーザーセッションの乗っ取りに成功し悪用する期間が長くなる。

ASP.NET アプリケーションの脆弱性の主要な原因は、未検証の入力です。Cross-Site Scripting、Process Control や SQL Injection などのさまざまな脆弱性の原因は入力の未検証です。

そのような攻撃を防止するため、ASP.NET 検証フレームワークを使用してすべてのプログラム入力を確認してからアプリケーションに処理させます。

検証フレームワークの使用例には、次の点を確認する検証が含まれます。

- 電話番号フィールドには、電話番号で有効な文字だけが含まれる。
- ブール値は「T」と「F」のいずれかだけである。
- 自由入力の文字列は適切な長さと形式にする。

web.config にある configuration/system.web/authentication/forms 要素の cacheRolesInCookie 属性が true に設定されている場合、各ユーザーのロールは cookie にキャッシュされます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。