ほとんどの Web アプリケーションは、セッション ID を使用してユーザーを一意に識別します。これは通常 cookie に保存され、サーバーと Web ブラウザー間で透過的に送信されます。


属性の値が true または UseUri に設定されている場合、ブラウザーまたはデバイスが cookie をサポートしているかどうかに関係なく、アプリケーションは cookie を使用しません。属性の値が AutoDetect または UseDeviceProfile に設定されている場合、要求元のブラウザーまたはデバイスの構成によっては cookie が使用されません。

セッション ID を cookie に保存しないアプリケーションは、HTTP リクエスト パラメーターとして、または URL の一部としてセッション ID を送信することがあります。URL で指定されたセッション ID を受け入れると、攻撃者はセッション ID 固定化攻撃を実行しやすくなります。

URL にセッション ID を含めると、アプリケーションに対するセッション ハイジャック攻撃の成功率も高くなります。セッション ハイジャック攻撃は、攻撃者が被害者のアクティブなセッションまたはセッション ID を制御すると発生します。Web サーバー、アプリケーション サーバー、および Web プロキシが要求された URL を保存するのは一般的な動作です。セッション ID が URL に含まれている場合、それらはログにも記録されます。セッション ID が表示および保存される場所が増えると、攻撃者に侵害される可能性も高くなります。

ASP.NET アプリケーションは、トレースデバッグ情報を出力するように設定できます。Trace Output には、現在のページに対して行われたリクエスト、ヘッダー情報、ページで使用されたメソッドおよびコントロール、そしてアクティブセッションの状態が含まれます。攻撃者はトレース出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

トレース情報は、<page> ディレクティブの Trace 属性を true に設定することによってページ レベルで有効にするか、web.config ファイルに trace 要素を追加し、enabled 属性を true にすることによってアプリケーション レベルで有効にします。

useUnsafeHeaderParsing プロパティを true に設定することで、安全でない HTTP ヘッダー処理が行われます。この設定により、HTTP ヘッダーの検証ルールが不十分になるため、脆弱なアプリケーションを攻撃の危険にさらすことになります。

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

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

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

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

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

偽装された資格情報を使用すると、ASP.NET アプリケーションを、実行しているクライアントの特権、またはその設定で付与された任意の特権のいずれかで実行できます。

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

Page.EnableViewStateMac = false;

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 ハッシュは、引き続きこのような攻撃に対して適切な保護を提供しています。

書き込み、更新、または削除によりデータを変更する ASP.NET MVC コントローラー アクションは、以下のいずれかの HTTP 動詞のみを受け入れるように制限することでメリットが得られる可能性があります。Post、Put、Patch、または Delete。誤ってリンクをクリックしても、アクションの実行が起きないため、これによりクロスサイト リクエスト forgery の難易度が増加します。

次のコントローラアクションはデフォルトでどの動詞も許可するため、Cross-Site Request Forgery 攻撃の影響を受けやすいと考えられます。

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

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
}

必要な ([Required] 属性でマークされた) プロパティとオプションの ([Required] 属性でマークされていない) プロパティを持つモデルクラスは、攻撃者が想定以上のデータを含む要求を送信した場合に問題を引き起こす可能性があります。

ASP.NET MVC フレームワークは、リクエストパラメータをモデルのプロパティにバインドしようとします。

モデルバインドを行うパラメーターを明示的に通知せず、必要度が混在している場合、内部用のモデルプロパティがあるけれども、攻撃者による制御が可能であることを示す場合があります。

次のコードで定義されるモデルクラス例には、[Required] を含むプロパティと [Required] を含まないプロパティがあります。

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

オプションのパラメーターによってアプリケーションの挙動が変わる場合は、攻撃者はオプションのパラメーターをリクエストで送信することにより実際にその挙動を変えることができます。

必須の ([Required] 属性でマークされた) non-nullable プロパティを持つモデルクラスを使用すると、攻撃者から想定より少ないデータを含んでいるリクエストが送信された場合に問題を引き起こす可能性があります。

ASP.NET MVC フレームワークは、リクエストパラメータをモデルのプロパティにバインドしようとします。

モデルに必須の non-nullable パラメーターが含まれており、攻撃者がその必須パラメーターをリクエストで送信しない場合、つまり攻撃者が under-posting 攻撃を利用する場合、プロパティにはデフォルト値 (通常はゼロ) が与えられ、[Required] 検証属性を満たします。この場合、アプリケーションが不測の挙動を起こします。

次のコードで定義されるモデルクラス例には、non-nullable の必須 enum が含まれています。

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

モデルクラスに必須のプロパティが含まれており、そのタイプが親モデルクラスのオプションメンバーの場合、攻撃者が想定より少ない量のデータを含んでいるリクエストを送信すると under-posting 攻撃の影響を受ける可能性があります。

ASP.NET MVC フレームワークは、サブモデルを含むモデルのプロパティにリクエストパラメータをバインドしようとします。

サブモデルがオプションの場合、つまり親モデルに [Required] 属性なしのプロパティが含まれる場合、攻撃者がそのサブモデルを送信しないと、親プロパティには null 値が与えられ、子モデルの必須フィールドはモデル検証によってアサートされません。これは under-posting 攻撃の 1 つの形態です。

以下のモデルクラス定義を考慮してください。

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

攻撃者が ParentModel.Child プロパティの値を送信しない場合、ChildModel.RequiredProperty プロパティにはアサートされない [Required] が与えられます。この場合、問題となる不測の結果が生じる可能性があります。

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);
} 

カスタマーマネージド キーは、保存データの暗号化には使用されません。

デフォルトでは、暗号化が有効になっている場合、AWS は AWS が管理するキーを使用して保存データを暗号化します。カスタマーマネージド キーを使用すると、組織は、選択した暗号鍵を使用してデータを暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、カスタマーマネージド キーは通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄

aws/service-name 形式のキーは、AWS 管理のキー用に予約されていることに注意してください。

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

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

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

これは、公開されたサービスのゼロデイ エクスプロイトが発見され、公表された場合 (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