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 を構成する方法を示しています。

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 の平均数が増大する。

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

useUnsafeHeaderParsing を true に設定すると、HTTP ヘッダーの処理が緩和します。HTTP ヘッダーに対する、過度に許容度が高い検証ルールは、脆弱なアプリケーションをさまざまな攻撃の危険にさらす可能性があります。



具体的には、このプロパティが false に設定されている場合、次の検証ルールは適用されなくなります。

行末コードでは、CRLF を使用します。CR または LF を単独で使用することは許可されていません。

ヘッダー名にはスペースを入れないでください。

ステータス行が複数ある場合、追加のステータス行はすべて、正しくない形式のヘッダーの名前/値ペアとして扱われます。

ステータス行には、ステータス コードに加えて、ステータスの説明が必要です。

ヘッダー名に非 ASCII 文字を含めることはできません。この検証は、このプロパティが true と false のどちらに設定されているかに関係なく実行されます。

プロトコル違反が発生すると、ステータスが ServerProtocolViolation に設定された WebException 例外がスローされます。UseUnsafeHeaderParsing プロパティが true に設定されている場合、検証エラーは無視されます。

このプロパティを true に設定するとセキュリティに影響するため、これは、サーバーとの下位互換性が必要な場合にのみ行ってください。


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

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest  useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...

ASP.NET では、ビュー ステートは、ポストバック間で Web フォームの状態を保持するメカニズムです。ビュー ステートに保存されたデータは、リプレイ攻撃を防ぐメカニズムがないため信頼できません。ビュー ステートを信頼することは、ビュー ステート メッセージ認証チェックが無効になっている場合特に危険です。このチェックを無効にすると、攻撃者はビュー ステートに保存されているデータに任意の変更を加えることができ、ビュー ステートを信頼するコードへの攻撃が可能になります。攻撃者はこの種のエラーを使用して、認証チェックを打破したり、商品の価格を変更したりする可能性があります。

ASP.NET MVC は、フォーム側で AntiForgeryToken を追加し、それをコントローラで検証することにより、Cross-Site Request Forgery に対するアプリケーションの保護レベルを簡単に引き上げることができます。これを使用する場合、通常この Token は非表示フォームとして含まれており、フォームを送信する際に検証することで、要求がユーザーのアプリケーションから送信されたものであり、偽造されていない可能性が高まります。

次のコントローラコードには、Cross-Site Request Forgery に対する組み込み型防御機構は含まれていません。

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}

ASP.NET MVC は、HTML フォームで AntiForgeryToken を追加し、そのトークンをコントローラで検証することにより、Cross-Site Request Forgery からアプリケーションをより確実に保護する利便性を提供します。これを使用する場合、通常この Token は非表示フォームとして含まれており、フォームを送信する際に検証することで、要求がユーザーのアプリケーションから送信されたものであり、偽造されていない可能性が高まります。

通常、アプリケーションに対する悪意のあるスクリプトの費用が増加することになるため、この AntiForgeryToken はプログラマが組み込む必要があります。

例 1: 次の Razor コードは、クロスサイト リクエスト フォージェリに対する組み込みの防御なしで、結果の HTML にフォームを作成します。

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
  // ... form elements
}

Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:

@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
  // ... form elements
}

NSURLConnectionDelegate.connection(_:willSendRequestFor:) 委任メソッドを使用すると、デリゲートは接続認証に関する情報に基づいた決定を一度で下せるようになります。デリゲートがこのメソッドを実装している場合は、NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) または NSURLConnectionDelegate.connection(_:didReceive:) を実装する必要はありません。実際、このようのメソッドは呼び出されないため、これらに対するセキュリティ チェックは無視されます。