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

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

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

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

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

デフォルトでは、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 などの攻撃に対して脆弱になります。

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

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 ヘッダーの検証ルールが不十分になるため、脆弱なアプリケーションを攻撃の危険にさらすことになります。

この属性が true に設定されている場合、次の検証は実行されません。

- 行末コードには CRLF を使用する。個別の CR または LF は使用できない。
- ヘッダー名にはスペースを入れない。
- 最初のステータス行以外はすべて、ヘッダーの名前と値のペアに誤りがあると解釈される。
- ステータス行にはコードと説明を含める必要がある。

この設定は、さらに、禁止されている文字に関する特定の例外がスローされなくなることも意味します。

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

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

ASP.NET におけるビューの状態とは、ポストバックで Web フォームの状態を保持するためのメカニズムです。反射攻撃を防止するためのメカニズムが存在しないため、ビューの状態に格納されたデータは信頼できません。特に、ビューの状態のメッセージ Authentication チェックが無効になっている場合、ビューの状態を信頼するのは危険です。このチェックを無効にすると、攻撃者はビューの状態に格納されているデータを改ざんできます。また、ビューの状態を信頼しているコードに対する攻撃が可能となります。攻撃者はこの種のエラーを悪用して、Authentication チェックを無効にしたり、商品価格を改ざんしたりする可能性があります。
例 1: 次のコードは、ビュー状態のメッセージ Authentication チェックを無効にしています。

Page.EnableViewStateMac = false;

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:) を実装する必要はありません。実際、このようのメソッドは呼び出されないため、これらに対するセキュリティ チェックは無視されます。

サーバーの信頼認証情報を作成する前に信頼チェーンを評価するのは、NSURLConnection オブジェクト、NSURLSession オブジェクト、または NSURLDownload オブジェクトのデリゲートの役割です。

例 1: 次のコードは、評価されていないサーバー信頼を使用して NSURLCredential を初期化します。

-(void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * credential)) completionHandler {
        ...
        [challenge.sender useCredential:[NSURLCredential credentialForTrust: challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
        ...
}

サーバーの信頼認証情報を作成する前にサーバー信頼を評価するのは、NSURLConnection オブジェクト、NSURLSession オブジェクト、または NSURLDownload オブジェクトのデリゲートの役割です。サーバー信頼を評価するには、SecTrustEvaluate(_:_:) メソッドを呼び出す際に、サーバーの NSURLProtectionSpace オブジェクトの serverTrust メソッドから取得した信頼を使用します。

SecTrustEvaluate(_:_:) メソッドは、次の 2 つの異なる値を返します。

- 返された OSStatus 値は、結果コードを表します。
- 2 番目の引数が示すオブジェクトは、評価の結果タイプを表します。

信頼が無効な場合は、cancel(_:) を使用して認証チャレンジをキャンセルする必要があります。

例 1: 次の例では、サーバー信頼は評価されますが、受信した認証情報はこの評価結果をチェックすることなく使用されます。

SecTrustRef trust = [[challenge protectionSpace] serverTrust];
SecTrustResultType result = kSecTrustResultInvalid;
OSStatus status = SecTrustEvaluate(trust, &result);
completionHandler(NSURLSessionAuthChallengeUseCredential, [challenge proposedCredential]);

NSURLProtectionSpace オブジェクトはサーバーや、一般にレルムと呼ばれる、認証を必要とするサーバー上の領域を表します。
保護領域に対して認証が必要となる URL 接続を確立する場合は、認証を実行する必要がある NSURLConnectionDelegate.connection(_:didReceive:) メソッドをコールする直前に、NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) メソッドが呼び出されます。こうすることにより、NSURLConnectionDelegate は保護領域に対して認証を行う前に、この領域を調べることができます。デリゲートは true を返すことにより、connection(_:didReceive:) に対する以降のコール内で行われる認証形式が処理可能なことを示します。デリゲートがこのメソッドを実装せず、保護領域でクライアント証明書認証またはサーバー信頼認証が使用される場合は、ユーザーのキーチェーンを使用して認証されますが、これが目的の動作ではない可能性があります。

アプリケーションは NSURLConnection または NSURLSession コールバックを実装して、認証リクエストを処理します。予測されるホストから認証リクエストが届くように設定しなかった場合は、アプリケーションによってロードされたすべての URL に認証情報が送信されます。また、この認証情報を安全に送信できることをチェックしなかった場合は、認証情報が盗まれてしまいます。

例 1: 次のアプリケーションは、認証を要求しているすべてのホストにユーザー認証情報を送信します。

- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NS URLAuthenticationChallenge *)challenge completionHandler:(void (^)(NS URLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { 
    NSString *user = [self getUser]; 
    NSString *pass = [self getPassword]; 

    NSURLCredential *cred = [NSURLCredential credentialWithUser:user 
    password:pass persistence:NSURLCredentialPersistenceForSession]; 
    completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
} 

アクセス設定が緩いと、システムが不必要に公開され、組織の攻撃対象領域が広がります。一般に公開されているサービスは、通常、悪意のあるエンティティによるほぼ継続的なスキャンとプロービングの対象になります。

これは、公開されたサービスのゼロデイ エクスプロイトが発見され、公表された場合 (Heartbleed など) に、特に問題になります。攻撃者は、パッチが適用されていない、公開されたシステムを積極的に追跡、検索して、それを悪用できます。

例 1: 次の Ansible タスクは、世界 (0.0.0.0/0) に対して TCP ポート 22 を開く AWS セキュリティ グループを定義します。SSH サーバーは通常、受信接続リクエストに応答します。

- name: Task to open SSH port
  amazon.aws.ec2_group:
    name: demo_security_group
    description: Open the ssh port to the world
    state: present
    vpc_id: 123456
    region: us-west-1
    rules:
    - proto: tcp
        ports: 22
        cidr_ip: 0.0.0.0/0

Lambda プリンシパルのワイルドカード設定は、最小特権の原則に違反し、攻撃者が任意のアカウントから Lambda を呼び出すことを可能にします。

例 1: 次の Ansible タスクの例では、ワイルドカード Lambda プリンシパルを定義します。

- name: Create Lambda policy statement for S3 event notification
  community.aws.lambda_policy:
    action: lambda:InvokeFunction
    function_name: functionName
    principal: *
    statement_id: lambda-s3-demobucket-access-log
    source_arn: arn:aws:s3:us-west-2:123456789012:demobucket
    source_account: 123456789012
    state: present

Amazon Redshift クラスターは、デフォルトでは一般公開されません。

クラスターへのパブリック アクセスを有効にすると、組織の攻撃対象領域が広がります。

例 1: 次の例は、publicly_accessible パラメーターを yes に設定することで Amazon Redshift クラスターへのパブリック アクセスを明示的に有効にする Ansible タスクを示しています。

- name: example1
  community.aws.redshift:
    identifier: mycluster
    command: create
    db_name: mydb
    node_type: ds1.xlarge
    username: "{{ username }}"
    password: "{{ password }}"
    publicly_accessible: yes

S3 バケットへのパブリック アクセスの設定ミスは、データ侵害の主な原因です。

S3 バケットはデフォルトでパブリック アクセスをブロックしますが、許可されたユーザーは、バケット ポリシーまたはアクセス制御リスト (ACL) を更新してパブリック アクセスを許可できます。

暗号化されていないブロック デバイスをマッピングする Amazon EC2 AMI は、データを不正アクセスや盗難の危険にさらします。

例 1: 次の Ansible タスクは、Amazon EC2 AMI を作成し、保存データの暗号化なしでブロック デバイスを AMI に接続します。これは、encrypted パラメーターが false に設定されているためです。

- name: Basic AMI Creation
  amazon.aws.ec2_ami:
    state: present
    instance_id: i-xxxxxx
    name: test_ami
    device_mapping:
      device_name: /dev/sda
      encrypted: false

デフォルトでは、EFS ファイル システムは暗号化されません。そのため、データが不正アクセスや盗難の危険にさらされます。

例 1: 次の Ansible タスクは、保存データの暗号化なしで EFS ファイル システムをセットアップします。これは、encrypt パラメーターが no に設定されているためです。

- name: EFS provisioning
  community.aws.efs:
    state: present
    name: myTestEFS
    encrypt: no
    targets:
      - subnet_id: subnet-12345678
        security_groups: [ "sg-87654321" ]